Story|4 minute read
Keeping cloud migration momentum after the first cutover
The quiet work between waves—observability, ownership, and release habits that stop programs from stalling.
The first migration wave usually goes well. It has executive attention, a dedicated team, and—crucially—the applications that were easiest to move. Then the programme reaches wave three, the reporting turns amber, and nobody can point to a single thing that went wrong.
This pattern is common enough to be predictable, and the causes are consistent.
Why the middle waves stall
- The easy applications are gone. What remains has unclear ownership, undocumented dependencies, or a vendor contract nobody wants to reopen.
- The people who learned how have moved on. Migration knowledge lived in a few heads, and those heads were reassigned once wave one shipped.
- The platform has no owner. Landing zones, pipelines, and guardrails were built as programme deliverables, not as a product with a team behind it.
- Costs arrived before benefits. Running both estates in parallel is expensive, and the savings case assumed a decommissioning that has not happened yet.
Treat the platform as a product
The single highest-leverage change is giving the internal platform a permanent owner, a roadmap, and users it is accountable to. A migration programme ends. A platform team does not.
That team's job is to make the correct path the easy path: a documented paved road for the common application shapes, with pipelines, observability, and security controls already wired in. When teams have to assemble that themselves each time, migration velocity is capped by the slowest team.
Measure lead time, not applications moved
Counting migrated applications rewards moving the easy ones and hides the fact that the hard ones are untouched. It also says nothing about whether anything improved.
Better signals are the time it takes a team to go from migration decision to running in production, the change failure rate after cutover, and the percentage of the estate that has actually been decommissioned. That last one is the number that turns a migration into a saving.
Budget for the boring wave
Somewhere in every programme is a set of applications with no clean answer—too costly to rewrite, too fragile to lift, too important to switch off. Deciding what to do with them is a business decision, not a technical one, and it needs to be made explicitly rather than deferred wave after wave.
Programmes that name that decision early keep moving. Programmes that leave it until last tend to stop just short of the benefits case they were approved on.
Working on something like this?
Tell us the outcome you are after and we will map the engagement.