Enterprise Migration
Consider an enterprise moving a large on-premises estate to Azure: hundreds of servers, several databases, strict governance, and a business that cannot tolerate a big-bang cutover. The requirements are a governed foundation to land in, hybrid connectivity during the transition, a way to manage both worlds at once, and an incremental sequence that de-risks the move.
The architecture is less about any single service and more about order of operations. A landing zone is built first, hybrid connectivity and Azure Arc bridge the two estates, Azure Migrate assesses and moves workloads, and a strangler-fig sequence replaces the old system slice by slice — so value lands early and the risky all-at-once cutover never happens.
Foundation First
Nothing migrates into an ungoverned account. The landing zone — management-group hierarchy, identity, policy, networking, and a security baseline — is built before workloads move, so every migrated system inherits governance from day one. Skipping this to 'move fast' produces the ungovernable sprawl that then costs more to retrofit than it saved.
Hybrid Connectivity and Arc
During the transition the two estates must interoperate. ExpressRoute (or VPN Gateway) provides private connectivity between on-premises and Azure, and Azure Arc projects the still-on-premises servers and Kubernetes into Azure so they are governed and monitored with the same tools as the migrated ones. The hybrid period is managed as one estate, not two disconnected ones.
Assess and Move
Azure Migrate discovers the on-premises estate, assesses readiness and right-sizing, and moves workloads — rehost (lift-and-shift to VMs), or replatform onto managed services. Databases often land on SQL Managed Instance for near-full compatibility with minimal change, using its link feature (which requires SQL Server 2016 or newer on-premises) for near-zero-downtime cutover. The assessment is what turns a vague 'move to cloud' into a sequenced, costed plan.
Strangler-Fig Sequencing
Rather than rewriting and cutting over all at once, the strangler-fig pattern routes slices of functionality to new Azure services incrementally while the legacy system keeps running, until the old system is fully strangled and retired. Each slice delivers value and is reversible, so the migration de-risks itself — the opposite of a big-bang cutover that fails wholesale or not at all.
Strangler-fig — Replace the legacy system slice by slice while it keeps running. Value lands early, each step is reversible, risk is incremental. The default for large estates.
Big-bang cutover — Move everything at once. Simpler to plan, but fails wholesale and is hard to reverse. Only for small, low-risk migrations.
- Migrating workloads into an ungoverned environment instead of building the landing zone first, producing sprawl that costs more to fix.
- Attempting a big-bang cutover for a large estate, where a failure is total and hard to reverse.
- Treating the hybrid period as two disconnected estates instead of unifying management with Arc.
- Lifting every server as-is when replatforming onto managed services would cut long-term operational cost.
- Migrating databases with a one-shot backup/restore when SQL MI's link feature offers near-zero-downtime cutover.
- Skipping Azure Migrate's assessment and right-sizing, then over-provisioning the migrated estate.
- Build the landing zone — governance, identity, networking, security baseline — before moving any workload.
- Establish ExpressRoute or VPN connectivity and use Azure Arc to manage on-premises and Azure as one estate.
- Use Azure Migrate to assess, right-size, and sequence the move rather than guessing.
- Replatform onto managed services where it cuts long-term cost; rehost where speed matters more.
- Migrate databases to SQL Managed Instance with the link feature for near-zero-downtime cutover where compatibility is needed.
- Sequence with the strangler-fig pattern so value lands early and each step is reversible.
Knowledge Check
What should be built before any workload migrates into Azure?
- The landing zone — governance, identity, networking, and a security baseline — so migrated systems inherit it
- A multi-region active-active deployment spanning paired Azure regions for every migrated workload from day one
- A Microsoft Sentinel workspace already ingesting every system log
- The production database, restored from its latest backup into Azure
Why prefer a strangler-fig sequence over a big-bang cutover for a large estate?
- Value lands early and each slice is reversible, making risk incremental instead of a wholesale all-or-nothing failure
- It is simpler to plan and sequence up front than any other migration approach for an estate of this size and complexity
- It avoids the need for any hybrid connectivity between the estates
- It requires no landing zone to be built beforehand
What does Azure Arc contribute during a migration?
- It projects still-on-premises servers and clusters into Azure so both estates are governed and monitored as one
- It moves the on-premises workloads into Azure automatically once it is connected to the servers across both estates
- It replaces ExpressRoute as the private connectivity between estates
- It rewrites legacy applications to run natively in the cloud
You got correct