On-Premises to Azure — A Migration Reference

Most of Azure has a clean AWS analogue. The value is knowing precisely where the analogy holds — and where it quietly stops.

Service mapping

Where the analogy stops

Four mappings above are lossy enough to change how you design:

• Resource Groups have no AWS equivalent. Every resource lives in exactly one, and deleting the group cascades to everything inside it. This is a blast-radius boundary AWS simply doesn't have, and it has to be designed deliberately rather than inherited.
• Azure Policy is an enforcement engine, not an audit tool. AWS Config reports drift; Azure Policy can Deny a non-compliant deployment outright at management-group scope. Guardrails that need custom tooling on AWS are native here.
• The account boundary splits in two. On AWS the account is identity, billing, and blast radius at once. On Azure the subscription is billing and quota, while the Entra tenant is identity. Isolation strategy has to account for both.
• SQL Managed Instance is VNet-injected. Unlike RDS, it lives inside your virtual network on a delegated subnet. That subnet has to be sized and designed before the first instance, and it cannot be changed afterward without a rebuild.

Discovery, wave sequencing, and the three workload classes that need different treatment.

End-to-end flow

Discovery and wave sequencing

The Azure Migrate appliance runs on-premises against vCenter and performs discovery, right-sizing assessment, and — the part that actually matters — dependency mapping. That dependency graph is what defines the waves; wave membership should be derived from observed traffic, not from an org chart or an application list.

Compute — three workload classes

Storage — the decision that carries the most risk

Databases — three targets, not two

Migration method by database size

Where the workloads land, how they survive a region event, and how the estate proves it is compliant.

Landing zone topology

Spokes peer to the hub, never to each other. All egress and inter-spoke traffic transits Azure Firewall in the hub, which is where policy is enforced and logged — the same reason a Transit Gateway inspection VPC exists on AWS.

Disaster recovery

Pre-stage the DR network. A failover that has to build VNets, NSGs, and DNS while the primary region is down is not a DR plan — it is an outage with extra steps.

HIPAA & governance

• The BAA is contractual, not per-service. Microsoft's Business Associate Agreement covers in-scope Azure services through the Product Terms — no separate signature chase per service. Confirm which services are in scope before designing one in.
• Azure Policy carries the compliance weight. Assign the built-in HIPAA/HITRUST initiative at management-group scope. Use Deny, not just Audit, for the controls that genuinely matter — public IP creation, unencrypted storage, missing tags.
• Private Endpoints everywhere. PaaS services default to public endpoints. In a PHI environment, every one gets a Private Endpoint with public network access disabled, and Private DNS Zones linked to the hub.
• Customer-managed keys in Key Vault for storage, disks, and SQL MI where the risk assessment calls for control over the key lifecycle rather than platform-managed encryption.
• Defender for Cloud as the evidence surface — its regulatory compliance dashboard maps live posture to HIPAA controls, which is what turns an audit into a report rather than a project.

The differences that cost time if you arrive from AWS expecting symmetry.

What bites AWS practitioners

1. NSGs evaluate at both subnet and NIC. Two rule sets, both must permit the traffic. A rule that looks correct at one level is silently overridden at the other — a reliable multi-hour debugging session on the first encounter.
2. vCPU quota is per subscription, per region, per VM family. Not a soft global limit. A wave stops dead when a family runs out. Request increases weeks ahead, per family, per region.
3. SQL MI's first deployment into a new subnet takes hours, not minutes — the platform is standing up a dedicated virtual cluster. Schedule it as its own task well ahead of any cutover window it feeds.
4. The delegated subnet for SQL MI is immutable. Size it for the eventual instance count on day one; changing it later means rebuilding.
5. Resource Group deletion cascades. There is no AWS equivalent to this blast radius. Group by lifecycle, not by convenience, and lock production groups with CanNotDelete.
6. Terraform's azurerm provider replaces where aws updates in place. Attributes that are an in-place change on AWS force resource replacement on Azure. Read every plan carefully — a routine tag change should never be recreating a VM.