How long does an Azure migration take?

The honest answer is that the planning and the decommissioning set the length, not the moving. A single well-understood workload can be days. A portfolio takes as long as its dependency mapping, its wave count and its change windows allow, and anyone quoting a duration before seeing the dependencies is quoting a hope.

Can you migrate with no downtime at all?

Near-zero, not zero, and only where the workload architecture supports continuous replication and the network can carry it. It costs more, takes longer to set up and has to be rehearsed. For anything that tolerates a planned window, a downtime migration is simpler and less risky, and saying so is usually worth more than the capability.

What happens to the old estate?

It gets a decommission date set at the same time as the migration date. Left open, it becomes a second estate being paid for and a split environment being operated, which is the most common avoidable cost in a migration programme.

What access do you need?

For planning, read-only across the source estate and the Azure tenant - inventory, configuration, dependencies and the platform's own signals. Anything that moves or changes a system is agreed separately and in writing.

A fixed fee for an agreed scope, quoted after a short call. Where the dependencies are undocumented enough that a wave plan cannot be drawn honestly, the investigation is quoted on its own first rather than buried in a migration price.

Azure Migration

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 method, in order for your estate
Planned through to a decommissioned source

Discuss the work

The method is published. The order is the work

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.

The five steps, and what bites in each

Microsoft's steps, with the part that actually causes trouble beside each one.

01
Plan migration
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
Prepare workloads
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
Execute migration
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
Optimize in cloud
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
Decommission source
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.

How the data actually gets there

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.

The decisions that decide how it goes

Four branch points, each with a wrong answer that costs either money or an outage.

Group by dependency before you group by convenience

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.

Downtime or near-zero downtime is a per-workload answer

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.

Non-production first, and one hard workload per wave

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.

Define what counts as failure before cutover night

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.

What DBHQ does with this

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:

A legacy platform moved, with the systems still talking
Integration and data-migration consultant for a global energy-trading firm connecting its trading systems and moving off legacy platforms.
- Led the migration of a legacy system to SAP using custom SQL abstraction tooling
- Built the enterprise integration layer tying the trading systems together (SQL Server, SSIS, SSAS)

See the work

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

Questions, answered

How long does an Azure migration take?: The honest answer is that the planning and the decommissioning set the length, not the moving. A single well-understood workload can be days. A portfolio takes as long as its dependency mapping, its wave count and its change windows allow, and anyone quoting a duration before seeing the dependencies is quoting a hope.
Do we need a landing zone first?: Microsoft lists an Azure landing zone as a prerequisite of migration planning, and the reason is practical: migrating into an ungoverned subscription means retrofitting governance onto production later, which is harder than building it first. In a small, single-workload move the landing zone can be minimal - but something has to be there.
Can you migrate with no downtime at all?: Near-zero, not zero, and only where the workload architecture supports continuous replication and the network can carry it. It costs more, takes longer to set up and has to be rehearsed. For anything that tolerates a planned window, a downtime migration is simpler and less risky, and saying so is usually worth more than the capability.
What happens to the old estate?: It gets a decommission date set at the same time as the migration date. Left open, it becomes a second estate being paid for and a split environment being operated, which is the most common avoidable cost in a migration programme.
What access do you need?: For planning, read-only across the source estate and the Azure tenant - inventory, configuration, dependencies and the platform's own signals. Anything that moves or changes a system is agreed separately and in writing.
What does it cost?: A fixed fee for an agreed scope, quoted after a short call. Where the dependencies are undocumented enough that a wave plan cannot be drawn honestly, the investigation is quoted on its own first rather than buried in a migration price.

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.

What is moving, and what does it depend on?

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.

Bring me the problem Book a call

I reply within 24 hours

The method is published. The order is the work

The five steps, and what bites in each

Plan migration

Prepare workloads

Execute migration

Optimize in cloud

Decommission source