Which Workloads Should You Move to the Cloud First?

Most cloud migrations do not fail because of the technology. They stall because the wrong workloads move first, dependencies surface late and early problems undermine confidence. The order in which you migrate matters as much as how you migrate.

This article sets out a simple, repeatable way to decide what moves first.

Start with an honest inventory

You cannot prioritize what you cannot see. Before any scoring, build an inventory of your applications and the infrastructure they run on. For each workload, capture:

• What it does and who depends on it
• Where it runs today and what it costs to run
• Which other systems, databases and file shares it connects to
• Who owns it, technically and in the business
• Any contracts, licenses or hardware renewals tied to it

Discovery tools help with servers and network connections, but they will not tell you which workloads matter most to the business. Short conversations with application owners fill that gap and often reveal dependencies that no tool records.

Score each workload on four factors

Once you have the inventory, score each workload from one to five on four factors.

Factor	Question to ask	Favors early migration when…
Business value	What do we gain by moving it?	Scaling, cost or renewal pressure is high
Complexity	How tangled are its dependencies?	It has few, well-understood connections
Risk	What happens if migration goes wrong?	Downtime has limited business impact
Readiness	Is it stable and well documented?	It changes rarely and has a clear owner

The best first-wave candidates combine reasonable value with low complexity and low risk. Highly critical, tightly connected systems usually belong in later waves, once the team and the platform have proven themselves.

Avoid letting a single factor dominate. A workload with high value but extreme complexity is not a good place to learn.

Choose an approach for each workload

Not every workload should move the same way. For each one, agree a migration approach:

• Rehost: move it largely as it is, to exit a data center quickly.
• Replatform: move it and adopt managed services, such as managed databases or containers, with little or no code change.
• Refactor: change the application itself to use cloud-native patterns. This is application modernization and usually needs its own plan.
• Retain: keep it where it is for now, for technical, contractual or regulatory reasons.
• Retire: switch it off, because it is no longer needed or duplicates another system.

Retiring is often overlooked. An inventory frequently reveals applications that nobody uses, and removing them reduces both migration effort and ongoing cost.

Build the foundation before the first workload

The first workload should land on a prepared foundation, not create one. A landing zone defines your account structure, identity integration, network connectivity, security guardrails and tagging before anything moves.

Building it first avoids rework later, when dozens of workloads would otherwise need to be reconfigured. Delivering it as infrastructure as code makes it repeatable and auditable.

Design the first wave to learn

Treat the first wave as a learning exercise as much as a delivery milestone. Choose a small group of workloads that together test your migration process end to end: discovery, cutover, rollback, monitoring and handover.

Agree what success looks like in advance, such as a cutover within the planned window and no unplanned business impact. Review what happened afterward, update your runbooks and adjust the plan for the next wave.

Plan for life after migration

Migration is not the finish line. Before the first workload moves, decide who will operate it in the cloud, how costs will be tracked and how incidents will be handled.

Without tagging, budgets and regular cost reviews, workloads moved as-is often run larger than they need to. Without clear operational ownership, issues fall between teams. Both are easier to set up at the start than to fix later.

A short checklist

Before you start your first wave, confirm that you have:

1. An inventory of applications, dependencies, owners and costs
2. A score for each workload on value, complexity, risk and readiness
3. An agreed migration approach for each workload
4. A landing zone built and tested
5. A first wave with defined success criteria and rollback plans
6. Clear ownership for operations and cost after migration

If you are early in this process, a short readiness assessment can produce the inventory, scoring and roadmap in a few weeks, giving you a defensible plan before you commit to larger investment.