Every enterprise that hasn't fully moved to the cloud has the same blocker: not the technology, but the decision of which workload to move first, and how. Here's the framework we run with customers — it's boring, it works, and it stops mid-migration second-guessing.
The three strategies, when each one wins
We pick from three patterns per workload:
Lift-and-shift. Move the VM/container as-is. Wins when the workload is stable, well-understood, and the goal is to exit a datacentre fast. Loses when the workload is the bottleneck you needed to fix anyway.
Re-platform. Move the workload, swap stateful services to managed ones (RDS, S3, ElastiCache). Wins when the app is fine but the ops burden of running databases and queues yourself isn't. This is where most enterprises actually live.
Re-architect. Decompose the monolith, introduce services, move to event-driven. Wins when the application is genuinely the constraint on the business. Loses when teams convince themselves they need microservices because everyone has them.
The wrong question is "which is best?". The right question is which workload, which strategy, which deadline. Different workloads can go different ways in the same programme.
What we sequence first
In our customer engagements:
- Stateless workloads first. Lower risk. The team learns the deploy loop on something forgiving.
- Reporting / analytics second. The data is already a derivative; if the migration breaks something, the impact is contained.
- Customer-facing transactional workloads third. By now the team knows the runbook, the observability stack, and the rollback procedure. They've earned the right to touch revenue-bearing systems.
- Mission-critical batch jobs last. Long-running, often poorly documented, often the riskiest. Migrate when the cloud is well-tooled and the team is confident.
Budgeting honestly
The trap: budgeting the migration as a project, not as an operational shift. The bill in month 1 looks higher than the datacentre. By month 12, when the ops staffing assumptions shift and the architecture is finally elastic, the numbers move. Plan for the J-curve.
Done right, the transformation isn't a 12-month programme that ends in a celebration. It's a permanent shift in how the team ships software — and the conversation moves from "are we in the cloud yet" to *"what would we ship if we had another quarter".