only after the move is complete and assuming it's as successful as you think it would be. What usually happens is the migration takes on a life of its own and is a multi-year if not multi-decade project. It sucks up so much money and effort that a business could be using to actually build their business vs migration to a different database. Meanwhile, the account execs of the old system know you're moving off of it so say good bye to any kind of contract discounts or special treatment during emergencies.
There's entire graveyards of failed enterprise system migrations. The most likely outcome is eventually a compromise has to be made and now you have two systems to maintain and license, the legacy one, and the new one. With the promise of eventually getting off the old one but it never happens.
I'm on a project with a client that has 24 ERPs across their enterprise around the globe from acquisitions. Half of them are ERPs that were meant to replace another one but the transition was never completed. A big part of this project is integrating all of their sales pipelines, analytics, and history into, yet another, enterprise system.
Even if you do move mountains and make it happen, suddenly any outages after the transition become your fault. “This never happened on the old system.”
- Is it possible for a 3 person team to manage 1000 distinct Kubernetes clusters?
- No way in hell!
- What if we hypothetically pay you $2M salary each?
- Well, let me think about it, we could figure this out...
That's a joke. but unironically you could manage 1000 Kubernetes clusters with automation. why not?
It took like 5 or 6 years and that $10M represents the cost of only 10 months of operations on Z.
So in such situation, I'd be tempted to actively oppose this initiative.
There was a recent big company that posted on Twitter about "shutting down our last Oracle server" and that was the last thing in a multi-year process or something like that.
Coordination is sometimes harder than the technology itself.