Cloud migration gets talked about like a single event, a weekend where everything moves over, but a properly run migration is a sequence of deliberate stages, and skipping stages is where most of the horror stories about surprise bills and downtime come from. Here is what the process should actually look like.
Stage one: assessment
Before anything moves, a proper assessment catalogues what you are actually running today: every application, its dependencies on other systems, how much data it holds, and how it is currently used. This sounds tedious but it is the stage that prevents nasty surprises later, because you cannot plan a migration for a system nobody remembered to list.
Stage two: choosing a strategy per application
Not every application should move the same way, and a good consultant will tell you that instead of pushing one approach for everything. The common strategies, often called the "6 Rs":
- Rehost (lift and shift): move the application as-is onto cloud infrastructure, fastest but does not take advantage of cloud-native features
- Replatform: make small optimisations during the move, like switching to a managed database, without a full rebuild
- Refactor: rebuild the application to be cloud-native, slower and more expensive but unlocks the most benefit long term
- Repurchase: replace the application with a cloud-native SaaS alternative instead of migrating it at all
- Retire: some applications, once you actually look, turn out to be barely used and not worth migrating at all
- Retain: some systems genuinely need to stay where they are, for now or permanently
A rushed migration defaults everything to rehost because it is fastest, then wonders why the cloud bill is not actually lower than the old infrastructure was.
Stage three: cost estimation that is actually honest
Cloud costs scale with usage in ways that on-premise costs do not, and a migration plan needs a realistic estimate of what the new environment will actually cost to run, not just what it costs to move. This is the stage most commonly rushed or skipped, and it is exactly why so many businesses end up with a cloud bill that shocks them three months after migration.
Stage four: the actual migration
Done in phases, not all at once, testing each moved application in its new environment before decommissioning the old one and moving the next. A phased approach means a problem in one migrated application does not take down everything else at the same time, and it gives your team a chance to learn and adjust the process as they go rather than discovering issues at the worst possible moment.
Stage five: what happens after cutover
Migration is not the finish line. Cost optimisation, security configuration, and monitoring setup all need attention after the move, and this is the stage that gets neglected most often once the pressure of the migration itself is over. A cloud environment left unoptimised after migration routinely costs 30 to 40 percent more than it needs to.
If you are planning a cloud migration and want a realistic assessment of cost, risk and the right strategy per application before committing to a timeline, our cloud team runs exactly that assessment as the first step, not an afterthought.