Azure Migration and Governance

Most Azure migrations that go wrong were not poorly executed. They were poorly assessed and ungoverned. The technical team knew how to move workloads. Nobody had mapped what those workloads did, who depended on them, or what rules the new environment should enforce. Six months later the migration is done and the Azure estate is already a sprawl of untagged resources, inconsistent access, and spend nobody owns.

Migration and governance are two halves of the same job. Migration gets you into Azure. Governance keeps the estate from becoming the next thing you have to clean up. This guide covers both: assessing readiness before you move, migrating in a controlled sequence, and putting the guardrails in place so the environment stays coherent as it grows.

Assess before you move

A readiness assessment is not a formality. It is the work that turns a migration plan from a guess into a project with known risks. Before a single workload moves, you need:

An application inventory and dependency map. Every workload in scope, what it does, what it talks to, and what talks to it. Most teams underestimate the lateral dependencies, and an undiscovered one is what breaks a migration mid-flight.

Data classification and compliance scope. Which workloads carry regulated data, and therefore which frameworks apply. For UK and Irish businesses that usually means UK GDPR, FCA operational resilience rules, and for EU financial services, DORA. Microsoft is a regulated third party in scope under DORA, and so is any provider you use to run the migration.

A migration strategy per workload. Rehost (lift and shift), replatform (targeted changes to use managed services), refactor (re-architect for cloud-native), or retire. Decide per workload, not per project. A real migration uses all four.

A target landing zone. Where workloads will land, configured correctly, before they arrive. This is the governance half, and skipping it is what produces the sprawl.

Migrate in controlled waves

Not everything moves at once. Sequence the migration by risk:

Start with non-production and low-risk workloads. They build Azure operational familiarity and validate your landing zone, connectivity, and identity model under real conditions, at low stakes. Move to well-understood production workloads next, once the environment is proven. Save the complex, high-risk, and heavily regulated workloads for last, when your team has real Azure experience and the environment is battle-tested.

Azure Migrate is the native tooling for discovery, assessment, and the migration itself. It builds the dependency map, sizes the target resources, and orchestrates the move. It reduces manual effort, but the judgement (which workloads, which strategy, which order) stays with you.

Govern from day one with landing zones

A landing zone is the pre-configured, governed environment workloads land in. Getting it right before migration is far easier than retrofitting governance onto a sprawling estate afterwards. The core elements:

Management group hierarchy. Subscriptions organised so policy and access apply consistently across the estate rather than per-subscription by hand.

Azure Policy. The enforcement engine. Define the rules (encryption must be on, public network access off, only approved regions, mandatory tags) and Azure applies or audits them automatically across every subscription. This is governance as code, and it is also your compliance evidence, because a policy that denies non-compliant resources produces a continuous record.

Identity and RBAC baseline. How access works across the estate, defined once and applied consistently, rather than accumulating ad hoc as teams self-serve.

A network topology. Hub-and-spoke or equivalent, with connectivity, firewalls, and private endpoints designed up front rather than bolted on.

The Azure Landing Zone reference architecture from the Cloud Adoption Framework is the well-trodden path here. The point of a landing zone is that governance is structural: every workload that lands inherits the guardrails automatically, so the estate stays coherent without anyone policing it manually.

Tagging is the foundation of governance

Tagging looks trivial and is foundational. Without consistent tags you cannot attribute cost, you cannot find resources by owner or environment, and you cannot enforce policy by classification. A tagging strategy (environment, owner, cost centre, data classification, applied consistently and enforced through Azure Policy) is what makes cost management, governance, and compliance possible at all. Apply it from the first resource, not as a cleanup project later, because retrofitting tags across a live estate is painful and never quite complete.

Governance is continuous, not a setup step

The estate drifts. New resources get created, policies need updating, access accumulates, and an environment that was governed at launch is non-compliant six months later if nobody is watching. Continuous governance means Azure Policy enforcing the baseline, Microsoft Defender for Cloud scoring posture against benchmarks in real time, regular access reviews, and cost reviews on a cadence. Governance is an operating discipline, not a one-time configuration.

For regulated businesses, this continuous governance is also continuous compliance. The same Azure Policy that keeps the estate coherent produces the evidence an auditor asks for, and the same Defender for Cloud dashboard that scores your posture maps it against PCI DSS, ISO 27001, and the rest. Built right, governance and compliance are one system, not two.

Where Critical Cloud comes in

Running an Azure migration that lands workloads correctly, then governing the estate so it stays coherent and compliant as it grows, is operationally demanding and easy to defer until it has become a problem. We run structured Azure migrations and ongoing governance for technology-led and regulated businesses across the UK, Ireland and EMEA. As the world's first Powered by Datadog accredited partner, we put observability and governance in place from the first workload, so the environment is visible, compliant, and operable from day one rather than cleaned up later. If you are planning a migration, or your Azure estate has already outgrown its governance, see how Critical Support works.