Microsoft publishes the method in full, and it is good. What no document can give you is the order for your estate, and that is where migrations go wrong.
Microsoft's Cloud Adoption Framework sets out five steps: plan the migration, prepare the workloads, execute it, optimise in the cloud, decommission the source. There is no secret in the list, and any consultancy claiming one is selling you the documentation.
What the framework cannot tell you is which of your workloads moves in which wave, what each of them quietly depends on, and what you are willing to call a failure at two in the morning. Those answers are specific to your estate, and getting them wrong is what turns a migration into an outage.
One prerequisite is worth saying out loud, because plans routinely skip it: Microsoft lists an Azure landing zone as a prerequisite of migration planning, not as a follow-on project. Migrating into an ungoverned subscription means retrofitting governance onto production later.
Microsoft's steps, with the part that actually causes trouble beside each one.
01
Sequencing, not a spreadsheet of servers. This is where dependency groups are drawn and waves are set, and it is the step most often compressed because nothing visible ships from it.
02
The landing zone has to exist to migrate into - Microsoft lists it as a prerequisite of planning, not a follow-up. Preparing also means remediating what is known to be broken before it is moved, rather than after.
03
Cutover, with the rollback already written and tested. The technical move is usually the least surprising part of the whole programme, provided the three steps before it were done honestly.
04
Rehosted workloads bill like rehosted workloads. Right-sizing, reserved capacity and the first real look at what the estate now costs belong here, and this is the step that quietly funds the rest.
05
The step that gets deferred indefinitely, which is how an organisation ends up paying for both estates and running a split environment nobody planned. Set the decommission date with the migration date.
Four paths, and the choice is usually made by what you already have rather than by what is best.
| The path | When | The trade |
|---|---|---|
| ExpressRoute | Any workload, when you already have it | Private and fast. Setup time and data transfer cost |
| VPN | Secure transfer without ExpressRoute | Encrypted over the internet, and slower. Needs a gateway first |
| Azure Data Box | Offline move, large volumes | Takes the data off your network entirely. Slowest, because it ships |
| Public internet | Non-sensitive data, nothing else available | Works anywhere. Least secure, and it eats your bandwidth |
Bandwidth is the constraint people discover late. A volume that copies comfortably over a weekend at 1Gbps does not copy at all over a contended internet link, and a Data Box has to be shipped both ways - which is a date in the plan, not a detail.
Four branch points, each with a wrong answer that costs either money or an outage.
01
Microsoft separates direct, indirect and business dependencies, and the rule that matters is the conservative one: where it is unclear how critical a dependency is, move the components together. A wave drawn around org charts rather than around traffic is how a migration takes out a system nobody listed.
02
Downtime migration is simpler, faster and entirely appropriate for a development environment. Near-zero downtime needs continuous replication, bandwidth to carry it and a rehearsal, and it is the only honest answer for a customer-facing system with an SLA. Deciding it once for the whole estate is the expensive mistake.
03
Development and staging before production, because they are where the process gets debugged rather than the application. Then deliberately include one genuinely complex workload early - a multi-tier application, something database-bound - so the problems that will hit the critical systems surface while the stakes are low.
04
A rollback plan is worth nothing without an agreed trigger: an error rate, a response time, a failed health check, a named person who can call it. Write it, automate what can be automated, and rehearse it in a staging environment. Deciding what failure looks like while it is happening is how a bad night becomes a bad quarter.
Migration planning and execution taken through to a decommissioned source: dependency mapping, wave sequencing, cutover and the rollback that makes cutover safe to attempt. Bounded, scoped and quoted before anything starts.
One engagement from the delivery record, as a contract consultant on the firm's own migration programme:
Integration and data-migration consultant for a global energy-trading firm connecting its trading systems and moving off legacy platforms.
Before a migrated workload is accepted into operations, somebody has to say it is safe to run. That is a separate purchase answering its own question: one workload judged against all five Well-Architected pillars, read-only, with a dated readiness recommendation. The Azure Well-Architected Review in full →
Where the dependencies are too undocumented to draw a wave plan honestly, that investigation is bought on its own first. The bounded investigation → Production delivery in full →
An independent view of Microsoft's Cloud Adoption Framework migration guidance. DBHQ is not affiliated with, endorsed by, or certified by Microsoft. Microsoft's methodology, tooling and service names change - check the current documentation before committing to a plan.
Describe the estate, the deadline driving it and what nobody can afford to have go down. You will get a straight answer on whether the dependencies are known well enough to plan, or whether that is the first piece of work.
I reply within 24 hours