Five questions worth answering before a cloud migration

Cloud migrations rarely fail outright. They disappoint: the same systems, running somewhere else, costing more. That outcome is usually decided before anything moves, in how the decision was framed.

1. Which workload, specifically?

"Migrate to the cloud" is a category of decisions rather than a decision. Each workload has its own cost profile, dependency graph and failure behaviour. Some should move as they are, some should be reshaped first, and some have no business case for moving at all.

2. What will it cost when it is running?

Model the bill before the migration, not after. Egress, cross-zone traffic and always-on managed services are where estimates usually go wrong, and they are all knowable in advance if someone takes an afternoon to look.

3. Who operates it on the far side?

A migration changes the operating model as much as the infrastructure. If the same team is expected to run the result, they need the platform skills before the cutover, not after. That is a hiring and training question, and it has a lead time.

4. What does rollback look like?

For each workload, how do you go back if the first week is bad? Sometimes the answer is that you cannot, which is fine as long as it is a known, accepted risk rather than something discovered on the Monday.

5. What are you actually buying?

Elasticity, managed services, geographic reach and a faster path to new capabilities are all real benefits. "Cost saving" on its own usually is not, at least not from a lift and shift. Being honest about which benefit you are buying makes it much easier to tell afterwards whether you got it.