Azure Cloud Migration in 2026: A Complete Guide for Enterprises

Azure migrations rarely fail on technology. They fail on sequencing — workloads moved before their dependencies were understood, a landing zone designed after the first application had already landed, or a business case built on infrastructure savings that never materialised because nothing was rightsized afterwards.

This guide sets out what an enterprise Azure migration actually involves in 2026: how to assess what you have, how to choose a strategy per workload, what has to exist before anything moves, and what genuinely drives the cost.

Quick answer: what does an Azure cloud migration involve?

An Azure cloud migration involves five phases: assessing the current estate and mapping dependencies, designing a landing zone with identity, network and governance in place, choosing a migration strategy for each workload, executing migration in waves with testing and cutover, and optimising cost and performance afterwards. For a mid-sized enterprise the whole programme typically runs across several months, with the assessment phase determining most of the eventual outcome.

Key takeaways

• The landing zone comes before the first workload. Retrofitting identity, network and policy onto a live estate is materially harder than building it first.
• Migration strategy is a per-workload decision, not a programme-wide one. Most estates use three or four of the five approaches.
• Dependency mapping, not server inventory, is what prevents cutover surprises.
• Lift-and-shift alone rarely reduces cost. Savings come from rightsizing, reservations and shutting down what is no longer needed.
• Cost cannot be quoted generically — it depends on workload profile, licensing position, data volume and how much modernisation is in scope.
• Plan for the two weeks after cutover as carefully as cutover itself.

Why enterprises migrate to Azure

The reasons that hold up under scrutiny are usually one of these, and it is worth being explicit about which applies, because it determines the strategy:

• A hardware refresh is due. The strongest and most common trigger — capital expenditure is already committed, so the comparison is genuine rather than theoretical.
• A data centre contract is ending. A hard deadline, which favours speed over modernisation in the first pass.
• Resilience requirements have changed. Regional redundancy and tested recovery are difficult and expensive to build in a single owned facility.
• Existing Microsoft alignment. Where identity, productivity and line-of-business systems are already Microsoft, integration and licensing tend to be simpler.
• AI and data ambitions. Modern data and AI services are difficult to consume from an isolated on-premises estate.

"Cost saving" on its own is a weak driver. A straight lift-and-shift of an under-utilised estate frequently costs more to run in month one than it did on owned hardware. Savings are real but they come from what you do after landing, which is why FinOps maturity belongs in the plan from the start rather than as a later cleanup.

Phase 1: assessment and discovery

This phase determines most of the eventual outcome, and it is the one most often compressed. Three things need to come out of it.

Workload inventory

Not just a server list. For each application: who owns it, who uses it, what it runs on, what it talks to, its data volume, its availability requirement, its compliance classification, and whether the vendor supports it in Azure.

Dependency mapping

The single highest-value activity in the whole programme. Applications depend on things nobody documented — a file share, a scheduled job on a forgotten server, a hard-coded IP address, a licence server, a database link to a system in another department. Azure Migrate's dependency analysis surfaces much of this from actual network traffic rather than from documentation, which is the point: documentation reflects what people believe, traffic reflects what is true.

Business grouping

Applications move in waves, and a wave should be a set of things that depend on each other. Splitting a dependency chain across two waves means running a hybrid connection between them and paying for the latency, which is survivable once and painful five times.

Output of this phase: a workload register, a dependency map, and a wave plan with an owner named against each wave.

Phase 2: the Azure landing zone

A landing zone is the pre-built Azure environment — identity, network, governance, security and management — that workloads land into. Building it first is what stops the estate becoming a set of unrelated subscriptions with inconsistent controls.

At minimum it establishes:

• Identity. Microsoft Entra ID, synchronisation from on-premises Active Directory where one exists, conditional access, and privileged access management for administrative roles.
• Subscription and management group structure. How workloads are separated for billing, policy and blast radius.
• Network topology. Hub-and-spoke or virtual WAN, connectivity back to on-premises, firewall and egress control, private endpoints for platform services.
• Policy and governance. Azure Policy for what may be deployed, where, and with what configuration — including tagging that makes cost allocation possible later.
• Security baseline. Microsoft Defender for Cloud, logging into a central workspace, and a defined retention period that matches your realistic detection window rather than the default.
• Naming and tagging standards. Unglamorous, and the difference between a cost report that answers questions and one that does not.

Microsoft publishes reference architectures for this under the Cloud Adoption Framework. Use them as the starting point rather than designing from scratch — most enterprises need to adapt the reference rather than replace it.

Phase 3: choosing a migration strategy per workload

Five approaches, commonly known as the five Rs. Most estates use three or four of them.

The judgement to make per workload is whether the application will still be here in five years and whether anyone is actively developing it. A stable, low-change application with no roadmap is a rehost candidate almost regardless of technical merit — spending refactor effort on it buys nothing. A system under active development is where modernisation pays back. The trade-off between moving a system and reworking it is the subject of our legacy modernisation playbook.

A sixth option deserves naming: retire. Every assessment we run finds applications nobody uses. Not migrating them is the cheapest possible outcome, and it requires only that somebody is willing to make the decision.

Phase 4: security, identity, governance and compliance

These are not a phase that follows migration. They are conditions that have to hold throughout it.

• Identity first. Everything authenticates against it, so getting it wrong means every later workload inherits the problem.
• Least privilege from the start. Standing Owner assignments granted "temporarily" during migration are one of the most common findings in post-migration reviews.
• Data classification before data movement. You cannot decide what may live where until you know what it is — which matters particularly where residency requirements apply, as we cover for UAE data residency.
• Logging with deliberate retention. Default retention is frequently shorter than the time it takes to detect an incident.
• Policy as guardrails, not as cleanup. Azure Policy applied to the landing zone prevents misconfiguration; applied afterwards it only reports it.

Phase 5: execution, testing and cutover

Migration runs in waves. Each wave follows the same rhythm:

1. Replicate. Initial data and server replication runs while everything continues in production. This is the long part, and nobody notices it.
2. Test migration. Bring the wave up in an isolated network in Azure and let the application owners verify it. This step is skipped under time pressure more often than any other, and it is where problems are cheap to find.
3. Delta sync. Catch up the changes since replication started.
4. Cutover. Switch traffic. Keep the source available but not serving, so rollback remains possible.
5. Hypercare. Elevated support for one to two weeks, with the migration team still engaged.

Two practical points. Lower DNS time-to-live at least 24 hours before cutover, or traffic will keep arriving at the old environment for hours. And define the rollback decision in advance — who can call it, and by when — because at two in the morning nobody wants to be deciding both whether to roll back and who has the authority to say so.

Azure cloud migration checklist

Before the first workload moves:

• ☐ Workload inventory complete, with a named owner per application
• ☐ Dependency map produced from observed traffic, not documentation
• ☐ Applications explicitly marked for retirement rather than migration
• ☐ Vendor support in Azure confirmed for each third-party application
• ☐ Landing zone built: identity, network, policy, security baseline, logging
• ☐ Subscription and management group structure agreed
• ☐ Naming and tagging standard published and enforced by policy
• ☐ Licensing position reviewed, including Azure Hybrid Benefit eligibility
• ☐ Data classification complete for anything crossing a boundary
• ☐ Migration strategy chosen and recorded per workload
• ☐ Wave plan agreed, with dependencies kept inside a wave
• ☐ Test migration environment available and application owners briefed
• ☐ Rollback criteria and decision authority defined in writing
• ☐ DNS time-to-live reduced ahead of cutover
• ☐ Hypercare rota staffed for two weeks after each wave
• ☐ Cost baseline captured, so post-migration change is measurable

Azure migration roadmap: a phased framework

The pilot phase earns its place. Rehearsing a rollback you never need is far cheaper than discovering during the third wave that rollback was never actually possible.

How much does Azure migration cost?

There is no credible universal figure, and anyone offering one without seeing your estate is guessing. Cost is determined by a small number of factors, and knowing them lets you build a real estimate.

• Workload profile. How much compute and memory the estate actually consumes, which is usually well below what was provisioned.
• Storage volume and performance tier. Frequently underestimated, particularly for backups and archives that were effectively free on owned hardware.
• Licensing position. Existing Windows Server and SQL Server licences with Software Assurance may be eligible for Azure Hybrid Benefit, which materially changes the comparison. Confirm eligibility against current Microsoft terms before relying on it.
• Commitment. Reserved instances and savings plans reduce compute cost substantially in exchange for a one- or three-year commitment — worth applying only once usage has stabilised after migration.
• Data egress. Small for most enterprise workloads, significant for data-heavy or media applications.
• Modernisation scope. Usually the largest single variable. Rehosting is priced in weeks; refactoring in months.
• Parallel running. Both environments run during migration. Budget for the overlap explicitly rather than being surprised by it.

Build the estimate bottom-up from your own assessment data, and treat the first three months post-migration as a distinct cost line — consumption is always higher before optimisation than after. The discipline for bringing it down is set out in our FinOps maturity model.

Post-migration optimisation

The migration is not finished at cutover. Four activities in the first quarter determine whether the business case holds:

• Rightsizing. Machines were sized for on-premises peaks and headroom. Actual usage data in Azure tells you what they need.
• Commitment purchasing. Once consumption is stable, reservations and savings plans apply to the steady-state baseline.
• Decommissioning. Source infrastructure has to actually be switched off. Programmes that leave it running "just in case" for a year pay twice.
• Cost allocation. Tagging enforced at the landing zone means each business unit can see its own consumption, which is what changes behaviour.

Common Azure migration mistakes

• Skipping dependency mapping and discovering at cutover that an application talks to something that has not moved.
• Building the landing zone after the first workloads have landed, which turns governance into remediation.
• Rehosting everything because it is fastest, then finding the business case depended on savings that rehosting alone does not deliver.
• Migrating applications nobody uses, because retiring them requires a decision and migrating them does not.
• Granting broad standing access during migration and never revoking it.
• Never decommissioning the source, so the organisation pays for two estates indefinitely.
• Treating the business case as complete at cutover, when the optimisation phase is where the savings actually appear.
• Under-resourcing hypercare. The technical migration succeeds and the service desk is overwhelmed.

Conclusion

An Azure migration is mostly a sequencing problem. Assess properly and map real dependencies; build the landing zone before anything lands in it; choose a strategy per workload rather than for the programme; move in waves that keep dependencies together; and treat the quarter after cutover as part of the project rather than the end of it.

The decisions that are expensive to reverse are all made early — the landing zone design, the subscription structure, the tagging standard, and which workloads are modernised rather than moved. Those deserve the time. The migration itself is well-trodden engineering.

Frequently asked questions

How long does an Azure cloud migration take?

For a mid-sized enterprise, typically several months from assessment to the final wave, with optimisation continuing for a quarter afterwards. The variables that move the timeline most are the number of application dependencies, how quickly application owners can test their workloads, and how much modernisation is in scope. Assessment and landing zone work usually account for a third of the elapsed time and determine most of the outcome.

What is an Azure landing zone and why does it matter?

It is the pre-built Azure environment — identity, network topology, subscription structure, policy, security baseline and logging — that workloads land into. It matters because retrofitting governance onto a live estate is far harder than building it first. Without one, you end up with unrelated subscriptions carrying inconsistent controls and cost data nobody can allocate.

Should we lift and shift or modernise?

Per workload, not per programme. A stable application with no active development is usually a rehost candidate regardless of technical merit, because refactoring effort buys nothing where nothing will change. Systems under active development, or where the current architecture is the constraint on the business, are where modernisation repays the cost. Most estates end up using three or four of the five migration strategies.

Does migrating to Azure reduce costs?

Not automatically, and often not in the first month. A straight lift-and-shift of an under-utilised estate can cost more to run than owned hardware that was already paid for. Savings come from what follows: rightsizing against real usage data, reserved instances or savings plans once consumption is stable, decommissioning the source environment, and retiring applications nobody uses.

What is the most common cause of Azure migration problems?

Undiscovered dependencies. Applications rely on things nobody documented — a file share, a scheduled job, a hard-coded address, a licence server, a database link into another department's system. Dependency analysis based on observed network traffic finds these; documentation does not, because documentation records what people believe rather than what is true.

Can we migrate to Azure without downtime?

Near-zero downtime is achievable for many workloads using replication and a short cutover window, but "no downtime at all" is rarely worth what it costs. The practical approach is to size the acceptable window per application with its owner, replicate ahead of time so the cutover itself is short, reduce DNS time-to-live a day in advance, and keep the source available but not serving so rollback stays possible.

What should happen after the migration is complete?

Four things in the first quarter: rightsize machines against actual Azure usage rather than the on-premises sizing they inherited, purchase reservations or savings plans once consumption is stable, decommission the source infrastructure rather than leaving it running, and enforce tagging so each business unit can see its own consumption. Programmes that stop at cutover usually miss the savings the business case assumed.