Public cloud end user spending is forecast to grow 21.3% in 2026, and Gartner attributes a large share of that to migration and modernization work that never really ended. Roughly 87% of enterprises now run multi-cloud strategies, according to Flexera’s 2026 State of the Cloud Report, and Gartner expects sovereign cloud IaaS spending to reach $80 billion in 2026, shifting about 20% of current workloads from global hyperscalers to local providers.
Read those numbers together and a different picture emerges than the one most migration business cases assume. Workloads are not moving once. They are moving repeatedly, in both directions, for reasons that have less to do with technology than with cost pressure, acquisitions, and regulation. Meanwhile a survey compiled across five sources this year found that 54% of organizations name unclear application dependencies as their leading migration challenge.
Migration stopped being a project and became an operation
The standard enterprise migration plan still reads like a construction schedule. There is a start date, a wave plan, a cutover weekend, and a closeout. That model made sense when the destination was permanent.
It is not permanent anymore. Companies move workloads to chase committed spend discounts, to satisfy a data residency requirement that changed after an acquisition, or to consolidate two estates after a merger. Each of those moves gets treated as a fresh project, staffed by a fresh team, using tooling assembled from scratch.
The waste is enormous, and it hides inside consulting line items rather than appearing as a defect count.
“If you are rebuilding your migration tooling every time you migrate, you do not have a migration capability. You have a series of expensive one-time efforts that happen to share a name.” (Proposed quote, pending client approval)
What a framework has to absorb that a runbook cannot
The three major hyperscalers agree on the shape of most primitives and disagree on nearly every detail underneath. Identity models differ. Network constructs differ. Storage consistency guarantees, quota behavior, throttling responses, and error semantics all differ in ways that only surface at volume.
A runbook papers over this by asking an engineer to make judgment calls at each step. A framework has to encode the judgment.
That means an abstraction over the target platform that is honest about what does not translate. The temptation is to build a lowest common denominator layer and pretend the clouds are interchangeable. They are not, and systems built on that pretense break on the first workload with a hard performance requirement. The better design keeps a common control plane for orchestration, state, and rollback while allowing provider specific execution paths underneath, so the differences live in one visible place instead of scattered through scripts.
“The abstraction should hide the repetitive work, not the real differences. Every time we tried to hide a genuine platform difference, it came back later as an outage.” (Proposed quote, pending client approval)
Dependency discovery is the bottleneck everyone underestimates
That 54% figure on unclear application dependencies matches what most engineering leaders see in practice. Teams can inventory servers. What they cannot easily produce is a truthful map of which service calls which, on what schedule, with what tolerance for latency.
Configuration databases are usually stale. Architecture diagrams describe the system as designed rather than as running. The only reliable source is observed traffic, and gathering it takes weeks that migration schedules rarely include.
This is where automation pays back the most and gets funded the least. A discovery pipeline that continuously ingests flow logs, traces, and deployment metadata into a dependency graph turns wave planning from an argument into a query. It also produces the artifact needed for rollback planning, because the same graph tells you what breaks if a component moves and its callers do not.
Skipping discovery does not remove the work. It defers it to the cutover window, when the cost of being wrong is highest.
“Nobody gets applauded for spending six weeks on discovery. They get applauded for the cutover that finished early, which is the same thing arriving in a different form.” (Proposed quote, pending client approval)
Where GenAI is earning its place in the migration loop
Gartner predicts that 90% of enterprise software engineers will use AI code assistants by 2028, up from under 14% in early 2024, and expects roughly a 30% productivity gain across software development through that period. Those figures get quoted as if the gain arrives automatically. It does not.
In migration engineering specifically, the useful applications are narrower and less glamorous than the marketing suggests. Translating infrastructure as code between provider dialects is a good fit, because the input is structured and the output is reviewable. Summarizing an unfamiliar legacy service from its code and configuration before a team touches it saves real time. Drafting the first pass of a remediation plan from a failed validation run gives engineers something to argue with instead of a blank page.
The pattern in all three is that a human reviews a bounded artifact. Where teams get into trouble is handing the model unbounded authority over production state, or using AI assisted review as a substitute for review rather than a first filter on it.
Sprint planning is another quiet win. Historical delivery data plus the dependency graph produces a more honest sequencing proposal than a room full of people estimating under social pressure, though the proposal still needs a human to reject it when it is wrong.
“AI has been genuinely useful for the parts of migration work that are tedious and verifiable. It has been useless, and occasionally dangerous, for the parts that require knowing what your customer actually cares about.” (Proposed quote, pending client approval)
The measure that matters comes after cutover
Migration programs report on workloads moved. It is the wrong metric, because it captures the moment of highest visibility and lowest information.
The measures worth tracking sit on the far side of the event. How many incidents occurred in the 30 days after cutover, and how many traced back to a migration decision. How long the parallel run had to stay up. How much of the estate remained in a half migrated state six months later, still paying for two environments. Whether the next migration went faster because of what this one produced.
That last one is the real test of an automation investment. A framework that made the second migration cheaper than the first has earned its budget. A framework that has to be rewritten has not.
The enterprises handling this well have stopped treating migration as something that happens to their platform and started treating it as something their platform does.
“Every migration should leave behind an asset. If the only thing left is a slide deck saying we finished, the money went somewhere it should not have.”
