Migrations that clear every milestone and still leave the business worse off are a familiar outcome, and the cloud platform is seldom the explanation. What was missing belongs one level above the schedule: a decision per workload about the form it moves in, the cost it moves at, the risk the business accepts, and the route back if the move has to be undone.
A strategy is where those decisions live. Everything below lays out what they need as input, in the order the inputs arrive, and what goes wrong when one of them is absent.
What a migration strategy contains that a migration plan does not
A migration plan schedules work. A migration strategy settles what the work is. The two get confused because a plan is easier to produce. It has timetables, leads and a dependency chain, and it can be put together before anyone has looked hard at the infrastructure.
According to AWS, a cloud migration strategy provides the business case, the scope and the approach for moving current IT resources to a new cloud environment, and it outlines each existing component and the best method to migrate it. The business case comes first in that definition and the component list comes after. Reverse the order and you get a technically tidy exercise that cannot say why any individual workload is moving.
Microsoft's Cloud Adoption Framework lays out the same dependency: with a clear inventory and an understanding of your workloads, the adoption plan must determine what to do with each workload in the cloud, and the business driver explains why a workload needs to change. The inventory is an input. The driver is an input. The strategy is the output that connects them.
So the deliverable is a set of documented decisions, one per workload, with the reasoning attached. Where a migration has a plan but no strategy, those decisions still get taken. They are taken by whoever is on the call that week, and they are usually taken in the direction of least resistance.
Why the business driver has to come before the approach
An approach choice commits the migration to consequences that outlast the cutover. Rehosting and replatforming buy different things, pay back differently, and leave the team with different ongoing obligations. The driver comes first and the approach derives from it.
| Business driver | Approach it points to | What the choice commits the migration to |
|---|---|---|
| A workload with no future business value | Retire | A decommissioning timetable and evidence that nothing still depends on it |
| No near-term reason to move | Retain, then revisit | A review point and a management route for the on-premises infrastructure |
| Speed out of a data centre, no modernisation planned | Rehost | Acceptance that scaling and the cost profile stay roughly as they are |
| Offload maintenance without rewriting code | Replatform | A managed service dependency and a documented lock-in position |
| Reduce technical debt in the code | Refactor | A development window within the migration schedule |
| Unlock cloud-native scaling and resilience | Rearchitect | The largest budget line and the largest delivery risk |
| A SaaS product already does the job | Repurchase | Process change, data movement and supplier risk |
| Nothing on the market fits the requirement | Rebuild | A product delivery exercise rather than a migration |
Read the right-hand column as the price of the decision. Rehosting looks like the cheap row and it is frequently chosen for that reason, so the caveats belong next to it.
The NHS cloud centre of excellence guidance, Choosing a cloud migration strategy for applications, says rehosting is a widely chosen route because migration effort is relatively low, then explains the drawback plainly: rehosted applications are not decoupled from the operating system, are usually much harder to scale, and experience shows rehosting delivers no major cost advantage. Microsoft goes further and warns against rehosting problematic workloads at all, on the grounds that the move takes existing technical debt forward and creates rework later. It offers a threshold worth copying into your own document: rehost only where you are confident the workload will not need modernisation within two years.
That guidance gives the reason the table matters more than the tooling choice:
The selected strategy fundamentally affects the expected migration effort, the potential amount of benefit of using the cloud, and possible long-term cost savings of the new operations model.
Assessments supply the evidence a strategy cannot invent
The table cannot be filled in from a server list. A strategy built without a workload assessment is a set of preferences dressed as a decision.
The NHS guidance is explicit that the assessment behind each approach choice should include technical aspects and also business, organisation, security and compliance, and that categorising workloads per application is what brings structure to a data-led decision.
CACI reports that poor application and dependency visibility is one of the most common discovery issues, and that missing a single critical dependency can cause an outage when a workload moves. The dependencies that cause the most damage are the undocumented ones, so the assessment has to be proved technically rather than accepted from a configuration management database.
Cloud Bridge's research, Secure Cloud Migration: What UK Businesses Need to Get Right in 2026, found that 85% of respondents say post-migration audits often reveal preventable security mistakes. That figure supports the case for treating security evidence as an input to the assessment rather than a check performed after go-live.
Each workload leaving the assessment should have, at minimum:
- a business contact and a technical contact
- the business capabilities it supports and who consumes them
- runtime dependencies, including integrations that appear in no current diagram
- data classes it contains, including any data about individuals and the lawful basis for processing it
- recovery time and recovery point objectives agreed with the business
- licence and contract terms, especially for anything out of vendor support
- the current run cost split into infrastructure, licence, support and staff time
- the chosen approach and a summary of what that approach gives up
- the acceptance test that will show the workload still works after the move
- the rule that applies if the acceptance test does not pass
Documented that way, a single workload's entry looks like this:
workload: claims-intake
contacts:
business: Head of Claims Operations
technical: Platform Lead, Integration
driver: end of data centre lease, no modernisation funded
approach: rehost
gives_up: horizontal scaling, managed database, licence mobility
rto: 4h
rpo: 15m
data_classes: [customer_data, health_data]
acceptance_rule: error rate above 2% for 15 minutes after cutover
rollback: restore from replica, DNS switch back, 30 minute window
Read the final two lines back to the business before anyone approves the batch. A rollback that exists only as an intention is the item that makes a bad hour into a bad month.
Sequencing converts those decisions into exposure
Once every workload has a decision, the strategy has to say what order they move in and what causes a batch to be paused. Nasstar explains the choice between a big bang and a phased approach, and reports that phased migrations typically begin with non-critical workloads so the team can learn and reduce risk, with low-risk applications piloted first to prove the tooling and the process. The point is to test the approach decisions from the earlier section against reality without a production dependency resting on the result.
CACI adds the control that most batch plans leave out: plan a rollback after each migration batch, not only at project level. A rollback plan that applies to the entire migration and nothing smaller is useless at the moment a single workload misbehaves. The strategy therefore has to define the size of a batch, the rollback that applies to each one, and the condition that triggers it.
Finally, the strategy has to name the person who can pause a batch. Without that, a batch proceeds on schedule even when the acceptance test has not passed, because no one has the clear mandate to stop it.
The strategy does not design the landing zone
The strategy does not choose the cloud provider, design the landing zone, or write the migration scripts. Those are downstream. What it does is establish the business driver for every workload, the approach that driver points to, the evidence the assessment produced, the rollback that applies, and the point at which the batch pauses. Everything else in a migration effort takes its direction from those decisions.
Sources
- What is a Cloud Migration Strategy?
- Select your cloud migration strategies
- Choosing a cloud migration strategy for applications
- Cloud Migration Challenges: Risks, Strategy & Best Practices 2026
- Cloud migration: A step-by-step approach
- Secure Cloud Migration: What UK Businesses Need to Get Right in 2026
The routes open to you
Migration plan
Scheduling work, timetables and dependency chains.
Migration strategy
Settling what the work is based on the business case and scope.
