Hyper-V to Azure Virtual Machine Migration
IT Partner migrates virtual machines from your on-premises Hyper-V hosts and clusters to native Azure Virtual Machines as a wave-planned project: Azure Migrate discovery from an appliance on one of your hosts, an assessment that right-sizes every VM on observed utilization with Azure Hybrid Benefit applied where your licensing qualifies, agentless replication driven from the hosts — nothing is installed inside your VMs — a test migration of every wave into an isolated network before anyone commits, planned cutovers, validation against the inventory, and decommissioning guidance for the vacated hosts. It is built for estates of roughly 20 to 500-plus VMs, typically on Windows Server 2016 or 2019 hosts, whose owners want to exit the hosts rather than rebuild them. The dates driving most of these projects are Microsoft's: Windows Server 2016 — the host operating system and, usually, a large share of the guests — leaves extended support on 12 January 2027, and Windows Server 2012 R2 Extended Security Updates end on 13 October 2026, per Microsoft's product lifecycle. A typical estate runs about 6 weeks; the wave plan states the real dates for yours. Pricing is quoted per estate, in writing, before work begins. Three boundaries up front: Azure consumption, Microsoft licensing and any Extended Security Update fees are Microsoft's charges, separate from our fee; VMware sources have their own page; and VMs that should be upgraded, rebuilt or left on-premises get that disposition in writing rather than a forced move.
What this engagement is
Most Hyper-V estates built in the 2016-2019 era have the same shape: a two- to eight-node cluster on Windows Server 2016 or 2019 Datacenter, a shared storage array or Storage Spaces Direct, and a few dozen to a few hundred guests spanning Windows Server 2012 R2 through 2022 — SQL Server, file services, line-of-business applications and a pair of domain controllers among them. What makes the 12 January 2027 date different from an ordinary guest upgrade is that it lands on the hypervisor and the guests at the same time: per Microsoft's product lifecycle, Windows Server 2016 extended support ends that day whether the operating system is running a VM or hosting one. Rebuilding the hosts means new hardware or a cluster rolling upgrade, a storage decision and a licensing renewal — all so the same VMs can keep running in the same room. Exiting the hosts moves the VMs once and retires the platform question entirely. This service is that exit, executed. The engagement runs on Azure Migrate, Microsoft's supported path for Hyper-V migration, and the workflow is genuinely host-side. A discovery appliance — a Windows Server VM deployed from Microsoft's VHD onto one of your hosts — inventories the estate over WinRM: VMs and their configuration, installed software, SQL Server instances, performance history, and the agentless dependency map that decides which servers must move together. From that we build the assessment you decide on: an Azure size per VM based on observed utilization rather than allocated vCPUs and memory, [Azure Hybrid Benefit](https://learn.microsoft.com/en-us/windows-server/get-started/azure-hybrid-benefit) applied wherever your Windows Server and SQL Server licensing qualifies, reservation options priced in, and a projected monthly Azure cost per wave — before any replication starts. Replication is then enabled from the hosts: the Azure Site Recovery provider and Recovery Services agent install on each host or cluster node, and nothing is installed inside the guests. An initial copy of each VM's disks is taken from a snapshot, changes are tracked on the host afterwards and shipped as deltas, and production keeps running throughout. Every wave gets a test migration into an isolated Azure network that touches nothing live; cutover is a final synchronization, a start in Azure, and the DNS and access changes, in a window you approve. VMs move as they are — operating systems, applications and data intact; nobody is rebuilding servers in order to migrate them. What changes is everything around them. Capacity becomes a sizing decision you can revisit monthly instead of a hardware purchase. The hypervisor stops being something you patch, license and cluster. And the end-of-support arithmetic changes in a way that matters for a 2016-era estate: per Microsoft's lifecycle guidance, eligible Windows Server VMs running in Azure are automatically enabled for Extended Security Updates at no additional charge from Microsoft, so a Windows Server 2016 guest that reaches Azure before January 2027 keeps receiving security updates for up to three further years while you upgrade it on your own schedule rather than a deadline's. We are equally plain about the limit of that: Windows Server 2012 R2 reaches the end of its Extended Security Updates on 13 October 2026 everywhere, including in Azure, so 2012 R2 guests get an in-place upgrade inside their new Azure VM — a path Microsoft supports by attaching upgrade media as a managed disk — or a rebuild, and the assessment says which. Lift-and-shift is not always the whole answer, and the assessment says so per VM. Domain controllers are better built fresh in Azure than replicated. SQL Server workloads often deserve a better target than a copied VM. Guest clusters on shared VHDX, VMs with pass-through disks or USB licensing dongles, and workloads bound to a plant floor by latency belong in a different column — upgraded hosts, Azure Local, or staying put under Azure Arc governance — and we scope that path separately instead of forcing it through this one. What you get from us is an executed decision for every VM in the inventory, not a preference for the service we happen to be selling.
Which one applies to you
Not every VM on a Hyper-V host has the same right destination. This is the map the assessment fills in per VM — this service delivers the first column and is honest when another fits better.
| Native Azure VMs (this service) | Upgrade the Hyper-V hosts in place | Azure Local on your hardware | Stay on the current hosts under Azure Arc | |
|---|---|---|---|---|
| What it is | VMs replicated to Azure Virtual Machines — no hypervisor left for you to run. | A cluster rolling upgrade or new hosts on a current Windows Server release; the VMs stay where they are. | Your VMs on your hardware, on Microsoft's hypervisor with the Azure control plane on-premises — Azure Local, formerly Azure Stack HCI. | The VMs stay put; Azure Arc adds inventory, policy, patching and Extended Security Update delivery from the Azure side. |
| When it fits | Most general-purpose Windows and Linux VMs without a hard on-premises dependency — the bulk of a typical estate. | Estates with recent hardware, a valid reason to stay on-premises, and Datacenter licensing with Software Assurance to carry the new release. | Workloads that must stay local — latency, attached hardware, data residency — but should gain a supported platform and cloud-side management. | A tail of VMs that cannot move yet, or a bridge for the months between the deadline and their retirement. |
| What happens to the 2016 and 2012 R2 deadlines | Windows Server 2016 guests receive Extended Security Updates automatically in Azure at no additional charge from Microsoft; 2012 R2 guests are upgraded in place inside Azure or rebuilt. | The host deadline is solved by the upgrade; each guest still needs its own upgrade or an Extended Security Update purchase. | Same as the host upgrade: platform solved, guests handled one by one. | Host and guests both need Extended Security Updates, delivered through Azure Arc and billed by Microsoft per core per year to your Azure subscription. |
| Cost profile | Pay-as-you-go or reserved Azure compute and storage, reduced by Azure Hybrid Benefit where licensing qualifies; Microsoft bills consumption directly. | Hardware refresh or reuse, Windows Server licensing for the new release, storage and support contracts. | Hardware you own plus Azure Local's per-core subscription; no separate hypervisor licence. | Existing hardware plus Extended Security Update fees that step up each year — a cost that buys time, not a destination. |
| Our role | We deliver this end to end — this page. | We advise honestly and scope it separately when it is the right call. | We advise honestly and scope it separately when it is the right call. | The [Azure Arc Hybrid Server Management Implementation](/services/azure-arc-hybrid-server-management) covers exactly this, and pairing it with a partial migration is common. |
The assessment produces a per-VM disposition against exactly this map, from your inventory and utilization data. Estates that need the second or third column are scoped as their own engagement — we do not fold a cluster upgrade into a migration quote.
Success criteria
What you receive
How the work unfolds
Confirm scope, stakeholders, the hosts and clusters in play, the target Azure subscription, the deadline driving the project and the access we need. Deploy the Azure Migrate appliance on a host and start discovery on day one — utilization history needs collection time, and the assessment gets better with every day of it.
Build the assessment from discovery data: right-sized Azure targets, dependency map, SQL Server discovery, Azure Hybrid Benefit and licensing analysis, and projected Azure costs. Every VM gets a disposition — migrate, upgrade then migrate, modernize, stay under Azure Arc, or rebuild — and you approve the map before anything replicates.
Group VMs into waves along dependency lines, agree cutover windows and rollback criteria, and prepare the landing environment within migration scope — or verify the existing landing zone and hybrid connectivity. Build new domain controllers in Azure where the plan calls for them. Ready the hosts for replication: checkpoints consolidated, Hyper-V Replica relationships resolved, log-storage capacity confirmed, outbound access opened.
Install the replication components on each host or cluster node, enable replication in batches and monitor to health. Run a test migration for every wave into an isolated network: boot check, access check, application smoke tests. Findings adjust the runbook, not the cutover night.
Execute cutovers in the agreed windows: source shutdown where zero data loss is required, final synchronization, VM start in Azure, DNS and access changes, per-wave validation and sign-off. Later waves replicate while earlier ones cut over, which is what keeps six weeks honest.
Reconcile the migrated estate against the inventory, run the Windows Server 2012 R2 in-place upgrades scheduled in the wave plan, resolve exceptions within scope, clean up replication, hand over decommissioning guidance for the vacated hosts, and deliver the closeout report.
Prerequisites
Who does what
IT Partner
- Deploy and operate the Azure Migrate tooling: appliance, discovery, assessment, replication components on the hosts, test migrations and cutovers.
- Produce the assessment, disposition map, licensing analysis and wave plan, and keep them current as decisions are made.
- Prepare the target Azure environment within migration scope and document what is built.
- Ready the hosts for replication within scope, and install and remove the replication components cleanly.
- Run test migrations for every wave and production cutovers in the agreed windows, and validate every migrated VM.
- Say plainly when a VM should not be lifted and shifted, and what should happen to it instead.
Your team
- Provide host and cluster access, appliance capacity, network information and firewall changes.
- Provide licensing documentation for the Azure Hybrid Benefit analysis and own licensing compliance decisions.
- Sign off the per-VM disposition, the wave plan and each wave's cutover.
- Provide application owners for smoke tests and staff the client side of cutover windows.
- Own perimeter DNS, third-party vendors whose systems point at migrating VMs, and end-user communications.
- Own host decommissioning execution, hardware disposal, and any Extended Security Update purchases for servers that stay.
What's not included
Limitations & technical notes
Frequently asked questions
Which Hyper-V hosts and guest operating systems can be migrated?
Azure Migrate's Hyper-V path supports hosts running Windows Server 2012 R2, 2016, 2019 or 2022 — standalone or clustered, including Server Core — per Microsoft's support matrix at the time of writing; Windows Server 2025 hosts are confirmed against the current matrix during planning. Guests follow Azure's own operating-system support — current Windows Server releases and the mainstream Linux distributions — and Generation 1 and Generation 2 VMs both migrate. The practical exceptions are configuration, not version: more than 16 disks, pass-through or shared disks, NIC teaming inside the guest, IPv6 dependencies, and encrypted volumes. The assessment lists every VM that needs remediation or a different path before you approve the wave plan.
Is anything installed inside our VMs?
No. The Hyper-V workflow is agentless from the guest's point of view: the Azure Site Recovery provider and the Recovery Services agent install on each Hyper-V host or cluster node, and Microsoft's documentation is explicit that nothing needs to be installed on the VMs themselves. The discovery appliance is a separate VM on one of your hosts that talks to the hosts over WinRM. When the project closes we remove the replication components from the hosts — or leave them, if the hosts are being retired anyway.
How does the replication actually work?
When replication is enabled for a VM, the host takes a snapshot and copies the virtual disks to a storage account in your Azure subscription. Once that initial copy completes, the snapshot is deleted and the host tracks changes in log files that are uploaded as deltas — the same change-tracking mechanism Hyper-V Replica uses. Production keeps running throughout. The host needs free disk space for those logs and outbound HTTPS to Microsoft's endpoints, replication is enabled in batches of up to ten VMs, and throughput is governed by your upload bandwidth and the estate's change rate — all of which the assessment measures before we schedule a wave.
What happens to our Windows Server 2016 servers after 12 January 2027?
In Azure, they keep receiving security updates. Per Microsoft's lifecycle FAQ, eligible Windows Server VMs hosted in Azure are automatically enabled for Extended Security Updates at no additional charge from Microsoft if they are configured to receive updates — for Windows Server 2016 that means Critical and Important security updates for up to three years beyond 12 January 2027. It is a runway, not a destination: ESUs carry no new features or non-security fixes, so the plan still includes upgrading those guests, just on your schedule. Hosts and guests that stay on-premises can also receive ESUs, delivered through Azure Arc and billed by Microsoft per core per year to your Azure subscription — a real cost, and one this project is usually trying to avoid.
We still have Windows Server 2012 R2 guests. Does moving them to Azure keep them patched?
Only until 13 October 2026, when Windows Server 2012 R2 Extended Security Updates end everywhere — including in Azure — per Microsoft's product lifecycle. There is no fourth year to buy. So the plan for a 2012 R2 guest is migrate and upgrade, or rebuild: Microsoft supports in-place upgrades inside an Azure VM by attaching upgrade media as a managed disk, with 2012 R2 able to step to 2016, 2019, 2022 or 2025, and we schedule those upgrades in the wave plan with a disk snapshot taken first. Where the application on the VM will not survive an upgrade, the disposition says rebuild, and that is scoped separately.
Will our servers be down during the migration?
Replication runs while everything stays in service, so downtime is each wave's cutover window: an optional shutdown of the source VM for a zero-data-loss final synchronization, the start in Azure, DNS and access changes, and validation. Window length depends on the final delta and validation depth and is agreed per wave in advance. Every wave is test-migrated first into an isolated network, which is what keeps cutover nights uneventful, and rollback — the source VM is still there, untouched — is available until you sign the wave off.
What is a test migration and why does it matter?
Azure Migrate can start a copy of a replicated VM in an isolated Azure virtual network without touching production or interrupting replication. We do it for every wave: boot check, administrative access, application smoke tests by the named owner. Problems surface days before cutover instead of during it, and the runbook is corrected while there is still time to correct it.
Do we need a landing zone or a VPN before we start?
It depends on what stays behind and how big the estate is. If the whole estate moves and nothing on-premises needs a private path to Azure, a migration-scope landing environment — subscription, networks, security groups, naming and tagging — is built inside this project. If users, printers, a plant network or a tail of servers stay on-premises, a site-to-site VPN or ExpressRoute must be in place before the first cutover; that is a separate one-week engagement we schedule ahead of wave one. Enterprise estates that will keep growing in Azure are better served by a governed landing zone first, and the assessment says so rather than building a foundation twice.
What about our domain controllers, DNS and DHCP?
Domain controllers are the one server class we prefer not to replicate. Building new domain controllers in Azure, adding an Active Directory site and subnet for the Azure network, letting replication settle and then demoting the on-premises ones is cleaner and avoids the update-sequence and time-skew risks of a copied domain controller. DNS moves with them, with conditional forwarders where a hybrid footprint remains. DHCP does not apply to Azure VMs — Azure assigns addresses — so servers that need a fixed address get a static private IP in the plan, and applications that hard-code addresses are identified in the dependency map before their wave.
What does Azure Hybrid Benefit do for us, and what is the 180-day rule?
Azure Hybrid Benefit lets qualifying Windows Server and SQL Server licences — those with active Software Assurance or subscription equivalents — cover the licensing portion of an Azure VM's price, and we apply it per VM in the assessment. The edition matters during a migration: Windows Server Standard licences can be used on-premises and in Azure at the same time only once, for up to 180 days, to allow the move; Windows Server Datacenter licences used for VM licensing allow simultaneous use. We sequence waves so a Standard-licensed estate does not run out of its window, and we will not book a benefit your licensing cannot back. If your licensing position is unclear, our Volume Licensing consulting sorts it out first.
We have SQL Server in the estate — is it included?
SQL Server VMs can move as part of the lift-and-shift, and often should. But two things make them worth a second look. SQL Server 2016 leaves extended support on 12 January 2027, the same day as Windows Server 2016 per Microsoft's product lifecycle, so a 2016 instance on a 2016 guest needs a plan for both. And SQL workloads frequently deserve a better target than a copied VM — a version upgrade in flight, Azure SQL Managed Instance, or Azure SQL Database. The assessment's SQL discovery flags those cases and they run through our dedicated SQL Server migration services, scoped alongside this engagement so nothing falls between the two.
Which VMs cannot be migrated this way?
The usual list from Microsoft's support matrix: VMs with more than 16 disks, OS disks over 2 TB (Generation 1) or 4 TB (Generation 2), pass-through or shared disks — which rules out guest clusters on shared VHDX — NIC teaming inside the guest, IPv6 dependencies, and encrypted or BitLocker-protected volumes until they are decrypted. Generation 2 VMs with Secure Boot are handled per VM against the current matrix. Each of those gets an explicit alternative in the disposition: remediation before its wave, the agent-based path we use for physical servers, a rebuild in Azure, or staying on-premises under Azure Arc. What we avoid is discovering the exception on cutover night.
What does this cost, and what is Microsoft's share?
Our fee is quoted per estate, in writing, before work begins, and you pay after you approve delivery. The drivers are VM count and total storage, change rate and bandwidth, host and cluster count, application complexity, the number of Windows Server 2012 R2 upgrades, and the wave count — which is why a 20-VM single host and a 400-VM multi-cluster estate are different quotes rather than one price. Microsoft's share is separate and yours: Azure consumption for the migrated VMs, which the assessment projects per wave; Azure Migrate's replication licensing, free per server for Microsoft's published period and charged per server per month after it; and any Extended Security Update fees for servers that stay on-premises.
How long does it take, and can we beat 12 January 2027?
A typical wave-planned estate runs about six weeks, with discovery starting on day one. Whether that beats the date depends on when you start and how much runway remains — upload bandwidth and change-freeze calendars are the usual constraints, and a large tail of 2012 R2 upgrades adds time. Bring the date to the scoping call; sequencing waves against a hard date is exactly what the wave plan is for. If the date is not achievable for the whole estate we say so before you spend money and prioritise the VMs that matter most — knowing that Windows Server 2016 guests that reach Azure before the date keep receiving security updates there.
What happens to the Hyper-V hosts afterwards?
If the whole estate moves, they get decommissioning guidance in the closeout — replication components removed, licences reassigned where Azure Hybrid Benefit was applied, storage retired in coordination with your backup and compliance owners — and you execute the retirement. If a tail of VMs stays, the hosts become the problem the project did not solve: a Windows Server 2016 host leaves support on the same day as its guests, so the choices are Extended Security Updates through Azure Arc, a host upgrade, or Azure Local — each scoped separately, none of them ignored.
What happens after the migration is done?
You own a native Azure estate, and the closeout hands it over cleanly: validation evidence, right-sizing rationale, licensing decisions and the exception list. Most clients then want four things, each a separate engagement so the migration stands on its own: backups for the new VMs through Azure Backup, a disaster-recovery plan now that the old cluster is gone through Azure Site Recovery, someone watching the environment through Azure Resource Monitoring and Maintenance, and a cost discipline so the Azure bill stays honest through the FinOps assessment.