Most enterprise cloud migrations don’t fail during cutover.

They fail quietly months earlier in planning workshops, governance meetings, and PowerPoint roadmaps, while everyone still believes progress is being made.

By the time the first workload is scheduled to move, the migration plan isn’t risky or immature. It’s structurally unexecutable.

That’s the uncomfortable truth most migration projects only realise after momentum is already gone.

The Mental Model

Common assumption:

“If we invest enough effort up front, execution will be straightforward.”

This assumption feels responsible. It’s also the root cause of many failures.

Enterprise migration planning treats early decisions as temporary scaffolding:

• Discovery will improve later
• Governance can be tuned post‑pilot
• Delivery teams will adapt once constraints are clear

In practice, early decisions behave like hard architectural commitments. They constrain everything that follows, often before the organisation understands what it has committed to.

Planning doesn’t precede architecture.
Planning is architecture.

How It Really Works

Migrations fail early because intent is designed without accountability for execution.

Planning artefacts are optimised for:

• Portfolio visibility
• Cost forecasting
• Executive sequencing
• Partner acceleration

Execution is constrained by:

• Identity boundaries and trust models
• Network topology and egress paths
• Security control enforcement
• CI/CD ownership and permissions
• Who is allowed to deploy what, where, and how

When those systems don’t align, the migration doesn’t “slow down”.
It becomes impossible to deliver without exceptions,, and exception‑driven delivery does not scale.

Structural Failure Modes (Locked In Before Cutover)

1. Discovery Fails by Design, Not by Accident

The problem isn’t that discovery is incomplete.
The problem is that enterprise discovery is structurally incentivised to be incomplete.

Discovery phases are usually:

• Time‑boxed
• Optimised for classification, not behaviour
• Owned by teams without operational accountability

So critical realities surface late:

• Authentication paths that double as integration hubs
• “Low‑risk” apps that terminate shared identity
• Data dependencies that cross assumed trust boundaries

These aren’t edge cases. They’re normal outcomes of shallow discovery operating under schedule pressure.

When discovery is optimistic, migration plans don’t degrade they collapse.

2. Organisational Boundaries Become Hard Technical Constraints

Infrastructure, security, and application teams often agree on outcomes but not on control.

What actually happens:

• Security defines mandatory controls without owning delivery paths
• Platform teams build landing zones without workload context
• Application teams assume exemptions will be negotiable later

This doesn’t create tension, it creates deadlock.

Once those boundaries are encoded into Azure constructs (management groups, policies, network segmentation), the organisation’s silos become enforced by the platform itself.

At that point, delivery friction isn’t cultural. It’s architectural.

3. Early Governance Decisions Are the Most Dangerous Ones

The most damaging migration decisions are often made early because they feel abstract:

• Management group hierarchy
• Subscription strategy
• Policy inheritance models
• Network segmentation patterns

These choices:

• Define who can deploy
• Shape every pipeline
• Determine how quickly teams can change

Changing them later is expensive because everything depends on them.

Technical mistakes can be refactored.
Governance mistakes propagate.

4. Planning Delivery as a Phase Guarantees Failure

A reliable predictor of migration failure is this sentence:

“We’ll build the platform first, then enable delivery.”

That creates a gap between:

• What the platform allows
• What workloads require
• What teams are authorised and able to deploy

If a real workload cannot be deployed safely, repeatedly, and without special approvals in the first few weeks, the migration will devolve into exception management.

And exception‑driven migrations don’t finish.

Real‑World Impact

When these issues exist before cutover, the symptoms are consistent:

• Landing zones that look compliant but host nothing real
• Security reviews blocking “low‑risk” workloads
• CI/CD pipelines that can’t pass policy enforcement
• Migration waves that exist only in planning artefacts
• Growing distrust between platform and application teams

By the time cutover is discussed, confidence is already gone.

Visualising the Failure Pattern

Most failed migrations follow this shape:

The break doesn’t occur at cutover.
It occurs when real workloads first touch governance.

Example: When Governance Becomes a Delivery Blocker

A common early move is enforcing strict network and exposure controls before workloads exist.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

resource denyPublicIP 'Microsoft.Authorization/policyDefinitions@2021-06-01' = {
  name: 'deny-public-ip'
  properties: {
    policyType: 'Custom'
    mode: 'All'
    displayName: 'Deny Public IPs'
    policyRule: {
      if: {
        field: 'Microsoft.Network/publicIPAddresses/ipAddress'
        exists: true
      }
      then: {
        effect: 'deny'
      }
    }
  }
}

The policy itself isn’t wrong.

The failure occurs when:

• Identity flows weren’t designed
• Egress requirements weren’t validated
• CI/CD pipelines don’t have a compliant deployment path
• Ownership of exemptions is unclear

At that point, the organisation learns a hard lesson:
governance without executable delivery paths doesn’t improve security it simply halts change.

Gotchas & Edge Cases

• Pilots harden into standards
  Early “temporary” designs become permanent reference architectures.

• Exception processes create shadow platforms
  Teams will bypass blocked paths rather than wait indefinitely.

• Accelerators amplify structural flaws
  They increase speed, not correctness.

Best Practices That Actually Matter

• Treat discovery as behavioural analysis, not inventory
• Design governance with delivery teams in the room
• Make at least one real workload deployable immediately
• Delay irreversible decisions until constraints are visible
• Measure success by repeatability, not policy coverage

Or more bluntly:

If your platform can’t host a real workload early, your migration plan is fiction.

Learn More

• Microsoft Cloud Adoption Framework — Governance discipline
• Azure Landing Zones design principles
• Enterprise-scale architecture considerations