Migration programs are measured by the cutover. There's a date, a war room, a rollback plan, and a moment when someone announces that traffic is flowing to the new environment. Then the program celebrates, the budget closes, and the contractors roll off.
What almost nobody plans is the ninety days that follow, which is where the actual risk lives. The workload is running somewhere new, on infrastructure with different failure modes, monitored by tooling that was configured for the old estate, operated by people whose mental model is still the datacenter. Everything works until the first thing doesn't.
This is not an argument against migrating. It's an argument that "migrated" and "operable" are two different milestones, and only one of them usually gets funded.
The failure mode is structural
Programs are built to reach a date. Steady-state operations have no date — they're a condition, and conditions don't fit in a Gantt chart. So the operating model becomes the item that slips: it's the least tangible workstream, it has the fewest dependencies blocking other work, and it can always be done "after go-live."
The result is that the program disbands at precisely the moment the estate is least understood. The people who know why a resource was configured a particular way are the ones whose engagement ended at cutover. The team inheriting it has documentation written to justify the design, not to operate it.
What actually breaks
The specifics vary, but the categories are remarkably consistent across engagements.
- Runbooks describe a place that no longer exists. "SSH to the host and restart the service" doesn't apply to a managed service, and the escalation contact is a team that no longer owns the layer. The runbook isn't wrong in an obvious way — it's wrong in the way that costs you twenty minutes at 3am while someone works out that the instruction is meaningless now.
- Monitoring watches the wrong layer. Host CPU and disk mattered when you owned the host. On managed services the signals that predict failure are different — queue depth, throttling, connection limits, quota exhaustion — and none of them were in the old dashboards. Teams frequently emerge from migration with more telemetry and less situational awareness.
- Ownership boundaries dissolved. In the datacenter, the split between infrastructure and application was physical and obvious. In cloud it's a configuration choice, and if nobody made it deliberately you get incidents where both teams reasonably believe the other one owns the fix.
- Backup and recovery quietly changed meaning. Snapshots are not backups, replication is not recovery, and the retention policy that was enforced by a tape rotation in the old world is now a default someone accepted in a console. This one is invisible until you need it, which is the worst property a problem can have.
- Migration-era access became permanent. The broad permissions granted so the cutover team could move fast are still in place six months later, along with service accounts nobody can attribute. Every migration produces this, and almost no migration budget includes cleaning it up.
- Costs drift without an owner. Environments left running, over-provisioned instances sized from peak on-prem specs, storage tiers never revisited. We wrote about the structural version of this in The Cloud Migration Mistake That Multiplies Your Bill; the day-two version is smaller, steadier, and equally unattended.
A migration isn't finished when the workload runs in the cloud. It's finished when someone can be woken at 3am, follow a document that matches reality, and fix it without calling a consultant who left in March.
Design steady state before you cut over
The fix costs very little if it happens during the migration, and considerably more afterward. Five things belong inside the program, with the same milestones and the same scrutiny as the technical workstreams.
- Name an owner per workload, before the move. Not a team inbox — a named accountable owner for the application and for the platform beneath it, with the boundary between them written down. Most post-migration incident delays are ownership questions, not technical ones.
- Rewrite runbooks against the new failure modes. During the migration sprint, while the people who built it are still present. The test is simple: could someone who wasn't on the project follow this document and resolve the incident? If it references a hostname, a console someone can't access, or a person's name, it fails.
- Define what "healthy" means, then alert on that. A handful of service-level indicators the business would recognize — latency, error rate, queue age, job completion — rather than a wall of infrastructure metrics. Port the alerts deliberately; don't let the old ones migrate by default and fire on things that no longer signal anything.
- Rehearse a failure before go-live. A game day on the new environment: kill an instance, fail over the database, revoke a dependency, restore a backup to a working state. Restore especially — an untested backup is a belief, not a control. Every rehearsal we've run has found at least one gap that would otherwise have been found in production.
- Set the day-one access model. Decide what standing permissions look like after cutover, with elevated access time-boxed and logged, and schedule the removal of migration-era grants as a dated task with an owner — not an intention.
The ninety-day checkpoint
Put a review on the calendar for ninety days after cutover, before the program closes, and fund the people to attend it. It's a short session with a fixed agenda: every incident since go-live and what the runbook was missing, alerts that fired without meaning anything, the actual cost curve against the projection, access still in place from the migration, and one restore test performed live. Whatever comes out of it becomes a backlog with owners and dates.
This is unglamorous and it is the single highest-return meeting in a migration program, because it catches the drift while the context still exists in people's heads.
A short worked example
A services firm moved a customer-facing application and its database to a managed platform. Cutover was uneventful. Week six, a routine maintenance event on the managed database triggered a failover that took roughly four minutes — well within the platform's documented behavior, and something the application's connection pool had never been configured to survive. The application dropped sessions for twelve minutes.
The incident itself was minor. What it exposed wasn't: the alert that fired was a legacy host-level check that said nothing useful, the runbook pointed at a decommissioned server, and the two people who understood the connection configuration had rolled off the project. Time to resolution was dominated by orientation, not repair.
The remediation was three weeks of work that would have been three days inside the program — connection retry configured properly, a health signal defined at the application level, runbooks rewritten by the team that now owned them, and a failover rehearsal added to the release process. The second maintenance event, two months later, was invisible to customers.
The honest takeaway
If your migration plan ends at cutover, it isn't a migration plan — it's half of one. The other half is who owns each workload, what healthy looks like, what happens when it isn't, and whether anyone has ever proven the restore works.
Build that half while the program still has people and budget. It's the difference between a migration that quietly succeeds and one that spends its first year making the case that cloud was a mistake.