A Migration Date Is Not a Plan

Joaquin "Jack" Fagundo, writing from Parkland, FL, on the five questions every leader should answer before setting a cloud migration date.

Somebody always wants a date. A migration date creates urgency, and urgency is useful. What it doesn't create is readiness, and plenty of cloud programs discover the difference a few weeks before cutover.

Before I'd commit production workloads to a move, I want five questions answered, and I want the answers written down. None of them are technical trick questions. That's the point. A move can be perfectly achievable from an engineering standpoint and still leave the financial, security or operational questions wide open. AWS's migration readiness guidance makes a similar case, looking at business, people, governance, platform, security and operations together instead of treating a migration as a sequence of server moves.

Why are we doing this?

"Move to the cloud" is an activity, not a reason. The real reason is usually more specific: a facility agreement that's expiring, a resilience requirement the current setup can't meet, a capacity ceiling, or infrastructure that simply no longer fits the business. Name it. Then say how you'll know it worked: which service should improve, who is accountable for that improvement, and what evidence will show it happened.

Watch for business cases that quietly assume work outside the migration. Moving an application and redesigning how it's delivered are two different commitments. If the case depends on both, fund and staff both.

Do we understand the service, or just the servers?

An infrastructure inventory is where discovery starts, not where it ends. A business service also leans on applications, data flows, identity systems, integrations, scheduled jobs and the people who support it. Google Cloud's planning guidance puts dependency mapping ahead of organizing migration waves, and I agree with that order. Sequence the move around the relationships that matter, not around a convenient list of machines.

Check what the discovery tools find with the application and business owners who actually live with these systems. Decide what has to move together. Write down the dependencies you're unsure of. A deadline should never turn an open question into an accepted assumption without anyone noticing.

Who owns it the day after?

The project team runs the move. Someone else runs the result, and that someone needs a name before cutover, not after. I want owners for availability, access administration, security exceptions, monitoring, cost and incident escalation, with clear lines between internal teams, the cloud provider and any managed service partner.

Then test it against ordinary bad days. A cost alert fires at 9 p.m., so who responds? Someone needs emergency access, so who approves it? An incident spans the application, the network and the platform, so who coordinates? And who formally accepts the service into support? Ownership is real when those answers work outside the org chart.

Ownership is real when the answers work outside the org chart.

Does the money include the move itself?

Steady state estimates tend to leave out the cost of getting there. Parallel operations, migration tooling, data movement, specialist help, training and contracts that keep billing after the workloads leave all belong in the case. Separate assumptions from terms you've actually confirmed. Decide, too, who can act when consumption doesn't match the forecast. The budget owner needs usable spending data, and engineers need clear authority to shut down waste.

I'd rather see three scenarios than one optimistic number. Show which assumptions move the business case the most, and what evidence would make leadership rethink the approach.

What lets us cut over, and what sends us back?

Agree on acceptance before the pressure of the migration window arrives. Business owners and technical teams should settle which checks prove the service works, who has the authority to make the call, how open exceptions get recorded, and what conditions stop or reverse the move. Google Cloud's execution guidance covers playbooks and controls for exactly this, including validation and rollback.

Then make rollback real. Know its prerequisites, how long it takes, what happens to the data and who owns it. A plan to go back is only worth something if it still works when things are already going badly.

Set the date around the evidence

Readiness doesn't mean every uncertainty is gone. It means the important ones are visible, owned and being worked. A good readiness review fits on a page or two: the outcome, the dependencies, who operates the service, the financial assumptions and the cutover criteria, with an owner and a date beside every real gap.

The strongest migration commitment I know is a schedule backed by evidence, and a team that knows what to do when the evidence changes.

---

About the author

Joaquin "Jack" Fagundo writes about data centers, cloud and the business of AI from Parkland, FL. He has spent 20+ years leading enterprise infrastructure and advises companies through JFagundo Consulting Services. Read more about Jack or find him on LinkedIn.