The pattern is consistent enough to be predictable. A migration programme gets funded, the easy workloads move, the hard ones get deferred to a second phase, and the second phase never gets its own budget because the first one already declared success. What is left is a hybrid estate nobody designed, half in a data centre, half in a cloud tenancy, and the integration between them held together by whatever was quickest at the time.
The cost problem is a symptom rather than the disease. Cloud spend grows because nothing in the estate makes an owner feel the consequence of a decision: the instance sized for a launch that happened two years ago is still running at that size, the non-production environment nobody turns off costs the same as production, and the storage tier is whatever the default was. None of that is visible until somebody maps spend to the team that caused it, at which point the conversation stops being about the platform and starts being about accountability.
The residency question is the one that turns into a genuine problem rather than an expensive habit. A workload holding regulated data sits in whichever region the migration wave happened to target, and the constraint was never written into the platform, it exists in a policy document and in the memory of whoever wrote it. That is fine until an audit, a customer questionnaire or a public-sector bid asks where the data physically is, and the honest answer takes three weeks to assemble.
The part that makes all of this harder to fix than it should be: the dependency map does not exist. Not because nobody tried, but because the estate has changed since the last attempt and the document was never a living thing. Which means every remediation proposal is a guess about blast radius, and guesses about blast radius are how migrations stall in the middle of a wave.
