Most Azure migration programmes don’t fail because Azure is hard.
They fail because two teams are optimising for different survival instincts.
The landing zone team is incentivised to reduce future risk.
The migration factory is incentivised to move workloads now.
Both are rational.
Together, they create predictable friction.
The Mental Model
Common assumption:
“If the landing zone is ready, migration can start.”
Why it breaks:
A landing zone is not a finish line. It’s a capability backlog.
Migration factories don’t wait for backlog completion, they run on waves, throughput, and external deadlines.
Treating platform readiness as a binary state forces one of two bad outcomes:
- migrations stall waiting for “one last thing”, or
- migrations proceed by bypassing the platform entirely.
Neither is accidental. Both are structural.
How It Really Works
Landing zones and migration factories are operating models, not deliverables.
- The landing zone defines what behaviours the platform permits at a point in time.
- The migration factory defines how quickly new behaviours are introduced.
When these models aren’t deliberately aligned, the faster one wins.
In practice, that’s almost always the migration factory.
At that point, the landing zone stops being a control surface and becomes a clean‑up exercise.
Real‑World Impact (Where This Gets Expensive)
Misalignment doesn’t just “cause issues”. It creates moments that are hard to unwind:
- First production workload without central logging.
You never fully regain observability parity. - First identity exception for speed.
Every subsequent wave expects the same treatment. - First subscription built outside agreed patterns.
Retrofitting guardrails becomes a political negotiation, not a technical one.
These are not theoretical risks. They are irreversible decisions made under time pressure.
Migration Factories Are Not Tools
A migration factory is often reduced to:
- Azure Migrate
- A set of pipelines
- A spreadsheet with wave numbers
That misses the point.
A migration factory is an operating rhythm:
- defined waves and entry criteria
- repeatable architectural decisions
- explicit exception handling
- a feedback loop into platform design
If the landing zone can’t operate at that rhythm, the factory will route around it quietly at first, then systematically.
Sequencing Capabilities Against Migration Waves
The alignment move that matters is sequencing platform capabilities against migration waves, not against a theoretical “target state”.
What this looks like in practice
Wave 1 does not need everything.
But it does need a small set of non‑negotiables.
A hard line worth drawing
In most environments, central identity and logging should exist before any workload migrates.
If you skip those to gain speed, you’re not accelerating you’re borrowing against future outages and audits.
Contract Boundaries That Actually Hold Under Pressure
High‑throughput programmes define explicit contracts and enforce them.
Landing zone team commits to:
- dates when specific capabilities become usable
- supported and unsupported patterns (clearly)
- stability guarantees during migration waves
Migration factory commits to:
- using only supported patterns by default
- declaring upcoming needs before waves begin
- quantifying the business impact of missing capabilities
Anything outside the contract is an exception, with an owner, an expiry date, and a remediation path.
If you can’t say no cleanly, you don’t have a contract, you have a hope.
Gotchas & Failure Modes
- Temporary exceptions fossilise.
If they aren’t time‑boxed, they become precedent. - Platform teams optimise for completeness.
Migration teams optimise for predictability. Confusing the two creates tension. - Security aligns to the wrong wave.
When controls arrive late, they’re perceived as blockers rather than enablers.
These are behavioural problems with technical consequences.
Best Practices
- Treat the landing zone as a product roadmap, not a one‑off build
- Define non‑negotiable capabilities for Wave 1 and defend them
- Align capability delivery explicitly to migration waves
- Design exception paths deliberately and measure how often they’re used
- Re‑negotiate contracts after every major wave, not at programme end
You’ll inherit it later, with interest.