How to migrate from on-premise to Azure without the drama

Moving out of your own data centre onto Azure follows the same shape as any cloud migration: discover, connect, move in waves, cut over, validate. What is different on Azure is identity and licensing, and both reward planning early. Here is the sequence.

Phase 1: Discover with Azure Migrate

Deploy the Azure Migrate appliance (a small VM in your environment) and let it watch the estate. Agentless against VMware or Hyper-V, agent-based for physical servers, it collects:

• Inventory and specs for every server, plus OS versions. Flag anything end-of-life. Windows Server 2012 era machines still migrate, and Azure is uniquely forgiving here: out-of-support Windows Server gets free Extended Security Updates when it runs on Azure VMs, which buys time to modernize.
• Dependency maps: what talks to what, on which ports. Run it against live traffic for at least two weeks so the monthly batch job and the forgotten reporting query show up.
• Assessments: right-sized Azure VM recommendations and a monthly cost estimate per server. Treat the estimate as a floor and sanity-check it against your own bill model.
• Licensing position. This matters more on Azure than anywhere else. List every Windows Server and SQL Server licence and whether it carries Software Assurance, because Azure Hybrid Benefit lets you reuse those licences instead of renting them inside the VM price. On a Windows-heavy fleet that is the largest single lever in the business case.

Group the surviving inventory into migration waves, assign each app a strategy from the 6 Rs, and expect to retire 10 to 20 percent of servers outright.

Phase 2: Landing zone, network, and identity

Build the destination before workloads arrive. Azure organizes differently from AWS: instead of separate accounts, you get subscriptions under management groups, governed by Azure Policy. The landing zone guide covers structure, logging, and guardrails; the parts that bite on-prem migrations specifically are the network and identity.

The network path

Create a VNet (Azure’s VPC) with IP ranges that do not overlap your on-prem network. An overlap breaks routing between the two environments, and re-addressing either side mid-migration is a project of its own. Lay out subnets across availability zones, keep app and database tiers in private subnets behind network security groups, and put a load balancer or Application Gateway in front of anything public.

Then pick the link:

	Site-to-site VPN	ExpressRoute
Time to provision	Hours to a day	Weeks (carrier involved)
Cost	~$140/mo (VpnGw1) + data	~$440/mo for 1 Gbps + carrier circuit fees
Bandwidth	~650 Mbps on VpnGw1 tiers	50 Mbps to 100 Gbps, dedicated
Latency	Public internet, variable	Private path, consistent
Right when	Most migrations	Sustained bulk transfer, hybrid apps, long-term hybrid

Default to the VPN. If discovery shows you need ExpressRoute, order it immediately: its lead time is the longest item on the plan. For one-time bulk moves that would saturate the link for weeks, Azure Data Box (a shipped appliance) is the offline alternative.

Identity: the Azure-specific homework

This is where Azure differs most from AWS. On AWS, identity for migrated servers is mostly “keep running your AD somewhere.” On Azure, you must choose deliberately, because Entra ID (formerly Azure AD) is not Active Directory. It handles modern sign-in and SSO but does not speak Kerberos or NTLM and does not process Group Policy. Your domain-joined file servers and legacy apps will not authenticate against it.

Three workable patterns:

1. Extend your AD: run one or two domain controllers on Azure VMs in a dedicated identity subnet. The most common lift-and-shift answer, minimal app changes.
2. Microsoft Entra Domain Services: a managed domain (from roughly $110 per month) that provides Kerberos, NTLM, and LDAP without you patching domain controllers. Good when you want to stop babysitting DCs but apps still need a domain.
3. Entra-only: for estates that are already mostly SaaS and modern auth. Rare as a migration-day state, common as a two-year goal.

Whichever you pick, set up Entra Connect sync early so cloud and on-prem identities agree. Identity is the phase teams underestimate; start it during discovery, not during wave one.

Phase 3: Migrate in waves

Start with a low-risk, self-contained wave so the first cutover teaches lessons on a system that can afford them. The tooling maps cleanly:

Workload	Tool	Notes
Whole servers (rehost)	Azure Migrate: Server Migration	Agentless replication from VMware/Hyper-V or agent-based from physical; test-failover into an isolated VNet while the source keeps serving
Databases	Azure Database Migration Service	Full load plus continuous sync until cutover; method details in the database guide
Bulk file data	AzCopy, Azure File Sync, Storage Mover	Into Blob object storage or Azure Files; see the file storage guide

Each wave runs the same loop: replicate, test-failover, validate, cut over, observe. The test failover is the safety net: boot a full copy of the wave in an isolated VNet, point a test client at it, and find the hardcoded IP on a quiet afternoon instead of during the window.

Take the small replatform wins mid-flight: self-managed SQL Server to Azure SQL Managed Instance (Hybrid Benefit applies there too), static file servers to Blob Storage. Resist bigger rewrites; that is a separate project with its own tradeoff analysis.

Phase 4: Cut over via DNS

Once a wave’s Azure copy is validated and replication lag is near zero:

1. T-48h: lower DNS TTLs to 60 seconds, checking the whole CNAME chain.
2. Pick the lowest-traffic window and announce it.
3. Stop writes on the source, let replication drain.
4. Validate: row counts and checksums for databases, functional smoke tests for apps, a domain-joined client actually authenticating.
5. Repoint DNS at the Azure load balancer or Application Gateway.
6. Watch error rates, latency, and one business metric for the first hour. Keep the on-prem side answering; some clients ignore TTLs for days.

Rehearsed, this is a 15 to 60 minute window per wave. For systems that cannot take even that, see the zero-downtime playbook.

Phase 5: Validate, then decommission

Keep each wave’s on-prem source alive, read-only where possible, for at least a week. Verify data integrity and the paths that write, then check the first real invoice against the Azure Migrate estimate. Confirm Hybrid Benefit is actually enabled on every eligible VM and SQL instance; it is a per-resource setting, and forgetting it silently doubles the Windows licence line. Right-size after a month of metrics, then take a final snapshot, archive it to cool-tier Blob storage, and turn the old hardware off. The savings only start when it actually powers down.

FAQ

How long does an on-premise to Azure migration take?

For a small-to-mid estate (20 to 80 servers), plan 3 to 9 months: 2 to 6 weeks of discovery and assessment with Azure Migrate, 1 to 2 weeks for the landing zone and network, then migration waves of 2 to 4 weeks each. Identity work (extending Active Directory or standing up Entra Domain Services) is the item most likely to add weeks, so start it in parallel with discovery.

Do we need ExpressRoute, or is a VPN enough?

A site-to-site VPN gateway is enough for most migrations. A VpnGw1 gateway costs roughly $140 per month, is running within a day, and carries around 650 Mbps. ExpressRoute earns its cost for sustained large transfers, latency-sensitive hybrid apps, or a long-term hybrid footprint, but a 1 Gbps circuit runs roughly $440 per month plus carrier fees and takes weeks to provision, so order it during discovery if the numbers point that way.

Is Entra ID a replacement for our Active Directory?

Not for a lift-and-shift. Entra ID handles cloud sign-in and SSO but does not speak Kerberos or NTLM and does not apply Group Policy, so domain-joined servers still need real AD. Most teams extend their existing domain with domain controllers on Azure VMs, or use Microsoft Entra Domain Services as a managed domain, and sync identities with Entra Connect.

What is Azure Hybrid Benefit worth?

If you own Windows Server or SQL Server licences with Software Assurance, Azure Hybrid Benefit lets you bring them instead of paying licence-included VM rates. Savings run up to roughly 40 percent on Windows VMs and up to 85 percent on SQL Server when combined with reserved capacity. On a Windows-heavy estate this single checkbox often decides the AWS vs Azure business case.

---

If you want a second set of eyes on your Azure Migrate assessment, your identity plan, or your wave sequence, talk to a Webisoft cloud engineer. You’ll get an honest read on timeline, licensing savings, and cost before committing to anything.