Migrate the operating model, not just the workloads

The lift-and-shift phase of a cloud programme is the easy part. The workloads run, the invoices arrive, and then the organisation discovers that nothing about how it operates has actually changed — the same tickets, the same change windows, the same three-week wait for an environment.

You do not finish a cloud migration. You finish migrating the operating model, and the workloads follow.

Sequence by capability, not by application

A migration plan organised as a list of applications produces a list of lift-and-shifts. A plan organised around capabilities — identity, networking, a landing zone, a delivery pipeline, an observability baseline — produces a platform that the applications then move onto. The second plan is slower to show its first migrated workload and far faster to show its tenth.

1. Establish the landing zone: management groups, policy, network topology, identity.
2. Stand up the delivery pipeline and infrastructure-as-code workflow.
3. Migrate a low-risk workload end to end to prove the path.
4. Only then migrate at pace, because the path is now repeatable.

Make the landing zone the product

The landing zone is not scaffolding you throw away after migration — it is the product the platform team maintains for the life of the estate. Express it as code so it is reviewable and reproducible. A management-group hierarchy in Terraform is a few lines:

resource "azurerm_management_group" "platform" {
  display_name = "Platform"
  parent_management_group_id = azurerm_management_group.root.id
}

resource "azurerm_management_group" "landing_zones" {
  display_name = "Landing Zones"
  parent_management_group_id = azurerm_management_group.root.id
}

resource "azurerm_management_group_policy_assignment" "require_tags" {
  name                 = "require-cost-center"
  management_group_id  = azurerm_management_group.landing_zones.id
  policy_definition_id = data.azurerm_policy_definition.require_tag.id
}

Budget for the operating model

The line item most transformation plans miss is the cost of running the platform after migration: the platform team, the guardrails they maintain, the FinOps loop that keeps spend honest. That is not overhead on top of the migration. It is the thing the migration existed to build.