A cloud migration can reduce cost and increase flexibility — or it can turn a working system into a fragile, expensive copy of itself. The outcome depends on strategy, not on the cloud provider.
Moving workloads "as is" to the cloud is called lift-and-shift, and it is where most migrations start and many fail.
The five strategies
AWS calls them the six R's; the core ideas are these:
- Rehost (lift and shift): move as-is. Fastest, least benefit.
- Replatform: change a few things (e.g., managed database) without rewriting.
- Refactor: re-architect for cloud-native benefits. Slowest, most value.
- Repurchase: replace with a SaaS product.
- Retire: delete what nobody needs anymore.
The biggest migration mistake is rehosting everything, then discovering you moved the cost and the complexity without the cloud benefits. Optimize for a few workloads first.
How to run it without failing
Follow a repeatable sequence: discover dependencies, pick the easy wins first, build a clear exit test, and keep rollback ready.
- Inventory everything, including forgotten workloads.
- Prioritize workloads by value and risk, not by size.
- Define success metrics before you move, not after.
Cloud migration FAQ
How long does a cloud migration take?
It depends entirely on scope. A small app can move in weeks; an enterprise estate takes a year or more. Phased migrations beat big-bang attempts.
Should I refactor during migration?
Do not mix rehosting and refactoring on the same workload. Change one thing at a time so you can attribute problems correctly.