Azure Site Recovery: Move VMware DR from Classic to Modernized Appliance

To move VMware or physical server disaster recovery off the retired classic Azure Site Recovery experience, create a new Recovery Services vault in the same region and tenant as the classic vault, deploy and register an Azure Site Recovery replication appliance on-premises, then open the classic vault's Replicated items and run Upgrade to modernized VMware replication for up to 10 machines at a time. Eligible items move without a full initial replication, usually in one to two hours when healthy, but recovery plans don't move, so you rebuild them in the new vault and run a test failover before relying on it. If the upgrade action isn't offered for a replicated item, Microsoft directs you to Microsoft Support for recovery guidance.

Who this is for and what you will have at the end

This guide is for administrators who still have VMware VMs or physical servers replicating to Azure through a configuration server and process servers, the components of the classic architecture.

At the end you will have:

• A modernized Recovery Services vault with one or more registered replication appliances.
• Your replicated items moved, with recovery points being created in the new vault.
• Recovery plans rebuilt and a successful test failover recorded.
• A clear view of when the classic vault stops billing and cleans itself up.

Where things stand in October 2026

After retirement, any change to an existing machine's replication configuration requires the upgrade, and machines that haven't moved risk disrupted replication health and losing portal management of disaster recovery operations. New features and Mobility agent support for new Linux distributions only ship for the modernized experience.

What changes architecturally

In the modernized architecture the Mobility service sends replication data to the appliance on HTTPS 9443 and management traffic on 443, and the appliance sends encrypted data to Azure on 443. Crash-consistent points are created every five minutes, app-consistent points follow the policy, and maximum recovery point retention is 15 days.

Prerequisites

Azure permissions

The account that registers the appliance needs:

• Contributor or Owner on the subscription.
• Permission to register Microsoft Entra applications. Check Microsoft Entra ID > Users > User settings; if app registrations are set to No, an administrator must grant the permission. The Application Developer role can't be used for this.
• Owner, or Contributor plus User Access Administrator, to create the Key Vault used during registration.

If several people configure appliances for one vault, add each as an owner of the vault's Entra app.

Replication appliance requirements

The appliance validates four Group Policy settings during setup: registry editing tools and the command prompt must not be blocked, trust logic for file attachments must not be set to 3, and the PowerShell execution policy must not be AllSigned or Restricted. It also needs outbound access, directly or through an HTTP proxy, to the URLs in the appliance support matrix, including the sign-in endpoints (login.microsoftonline.com, login.windows.net, *.msftauth.net, *.msauth.net), *.vault.azure.net, management.azure.com, *.blob.core.windows.net, *.siterecovery.windowsazure.com and *.prod.migration.windowsazure.com. The last four can be reached through private endpoints instead.

Sizing

A single appliance with an in-built process server, sized at 16 vCPUs, 32 GB of memory and a 1 TB cache disk, handles up to 200 machines. Microsoft's rule of thumb for this move is one replication appliance per process server in the classic vault: one configuration server plus four process servers means four appliances.

Step 1: Inventory the classic deployment

Before building anything, record for each classic vault:

• The number of process servers, which sets the appliance count.
• The configuration server, process server and Mobility service versions. Site Recovery supports the latest version and the four before it (N-4); the Supported updates table on the What's new page lists the current rollups.
• Each replicated item's health, whether initial replication has finished, and whether it is in resynchronization.
• Any items that aren't eligible: replicating to unmanaged storage, failed over or failed back, replicating from Azure back to on-premises.
• Recovery plans, their groups, ordering, manual actions and runbooks. You need this to rebuild them.
• Whether the classic vault uses private endpoints. Public endpoint to public endpoint and private endpoint to private endpoint migrations are supported; public to private is not.

Step 2: Create the modernized vault

Create a new Recovery Services vault in the same region and tenant as the classic vault; it can be in any subscription or resource group. Microsoft recommends a new, dedicated vault for the replication appliance rather than reusing an existing one. New vaults use the modernized experience by default and can't be switched to classic.

Step 3: Deploy and register the replication appliance

1. In the new vault, go to Getting started > Site Recovery, and under VMware machines to Azure select Prepare Infrastructure.
2. Download the OVF template (recommended, because it applies the prerequisites for you) and deploy it in vSphere. Power it on, accept the evaluation license, set the administrator password and select Finalize. If you can't use the OVF, build a Windows Server 2022 machine, download the installer package and run DRInstaller.ps1 as an administrator.
3. The appliance configuration manager starts automatically and checks connectivity, time sync and the Group Policy settings above. Configure a proxy here if the appliance uses one.
4. Choose how machines reach the appliance: FQDN (needed if source machines are in several subnets) or a NAT IP.
5. Give the appliance a friendly name (it can't be changed later) and paste the Azure Site Recovery replication appliance key from Recovery Services vault > Getting started > Site Recovery > VMware to Azure: Prepare Infrastructure. Select Login and complete the device code sign-in; the code expires five minutes after it's generated.
6. Select Add vCenter Server and enter the vCenter address, port, credentials and a friendly name. If you add the same vCenter to several appliances, use the same friendly name on each.
7. Select Add virtual machine credentials: root for Linux, a local administrator account for Windows. These are used to push the Mobility service.
8. For physical servers, expand Provide Physical server details, add credentials, then add each server by IP address or FQDN.
9. Select Continue. Installing and registering the components can take up to 30 minutes; keep the browser open.

Register appliances one at a time; parallel registration isn't supported, and cloning an appliance VM isn't supported either. When finished, Prepare infrastructure (Modernized) in the vault shows the registered appliance and a Discovered items tab listing your vCenter servers.

Step 4: Estimate the migration window

Disks and machines migrate in parallel, so 10 machines with two 256 GiB disks each take about the same 4 hours 15 minutes as one such machine. The portal shows the calculated Maximum migration time before you commit.

Step 5: Run the migration

1. Open the classic Recovery Services vault and select Replicated items.
2. Select Upgrade to modernized VMware replication. Read the Prerequisites page and select Next.
3. Select the modernized vault, the machines to move, and an appliance for each machine. The portal moves up to 10 machines per run.
4. Select Next, review Maximum migration time, and select I understand the risk. Proceed to move selected replicated item(s).
5. Select Migrate and monitor progress in the vault's Site Recovery jobs.

Replication groups (multi-VM consistency groups) move together: select the whole group or none of it. If some members fail, those are rolled back to classic and you rerun the migration for them.

During the migration

Replication pauses while an item migrates. The only operation available is Failover, from the classic vault, to the last available recovery point. A failover takes precedence and aborts the migration. If the migration fails, Site Recovery rolls the item back so it continues replicating from the classic vault. The migration is marked complete only when the first recovery point exists in the modernized vault.

Policies and settings

Site Recovery copies each replication policy into the new vault before moving its items. The copy is renamed with the new vault's name and resource group, so default replication policy becomes something like default replication policy contoso-modern-vault_contoso-rg. Changes you make to the classic policy after the copy is created aren't carried over, so finish policy edits before you start. Target virtual networks, storage accounts and other Compute and Network settings default to what the classic item used.

Step 6: Understand the classic vault afterwards

Failover and Disable replication remain available in the classic vault until the retention period of its last recovery point expires; then Site Recovery purges the item automatically. During that window you can fail over from either vault. If you fail over from the classic vault after migrating, the item in the modernized vault is cleaned up and commit, reprotect and failback must all happen from the classic vault.

Billing happens in only one vault at a time. The classic vault charges until its recovery points expire, and the modernized vault starts charging once its first recovery point exists and the old vault is cleaned up. Unused free-trial days carry over.

Step 7: Rebuild recovery plans

1. In the modernized vault, select Recovery Plans (Site Recovery) > +Recovery Plan.
2. Name the plan, choose the source and target that match the migrated machines, and select Resource Manager.
3. In Select items virtual machines, add the machines or replication group. All machines in a plan must replicate into a single subscription.
4. To order start-up, right-click the plan, select Customize, then +Group. A plan can have up to seven groups, and a machine belongs to only one group.
5. Add pre- or post-actions: Manual action pauses the plan until someone confirms it, and Script lets you attach an Azure Automation runbook. For VMware to Azure, runbooks are supported on failover but not on failback.

Step 8: Test failover

Run a test failover of each plan from Recovery Plans > plan name > Test Failover. Pick Latest processed for the lowest recovery time, Latest app-consistent, Latest for the lowest recovery point objective, or the multi-VM options if the plan contains replication groups. Select an Azure virtual network that is isolated from production but mirrors its subnet names and address ranges. Test failover doesn't affect ongoing replication. VMware Linux VMs, physical servers and machines without DHCP enabled need an extra step of 8 to 10 minutes during failover, so expect that in your timings. When validation is complete, select Cleanup test failover, record notes, and confirm.

For the same drill pattern applied to Azure VMs, see Azure-to-Azure disaster recovery with Site Recovery.

Verification

• Every migrated item shows a recent recovery point and healthy replication in the modernized vault.
• The appliance and its components are noncritical with a healthy heartbeat.
• Copied replication policies have the expected retention and app-consistent frequency.
• No classic item is left unaccounted for: each is migrated or escalated to Microsoft Support.

Troubleshooting

Upgrade to modernized VMware replication isn't shown. The item isn't eligible or the action is no longer available after retirement. Check the eligibility list in Step 1; if the item meets it and the action still isn't there, open a Microsoft Support case as the documentation instructs.

Appliance prerequisite check fails. One of the Group Policy checks failed. DisableRegistryTools under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System must be 0, DisableCMD under HKLM\SOFTWARE\Policies\Microsoft\Windows\System must be 0, UseTrustedHandlers under the Attachments policy key must not be 3, and the execution policy must not be AllSigned or Restricted.

Registration sign-in fails or loops. The device code expired after five minutes, or the account can't register Entra applications. Generate a new code and confirm the app registration setting.

Migration rolls back. Site Recovery rolls an item back to the classic vault when its migration fails. Recheck the prerequisites: the item, configuration server and appliance must all be noncritical with healthy heartbeats, and every component must be within N-4. Fix what's out of line and retrigger the migration.

Changes made during migration don't appear in the new vault. Compute and Network changes made while an item migrates might not replicate to the modernized vault. Reapply them on the new item.

Checklist

• Classic inventory recorded: process servers, versions, item health, recovery plans, endpoint type.
• New Recovery Services vault in the same region and tenant.
• Replication appliances deployed, one per classic process server, all registered and noncritical.
• vCenter and physical server details added with consistent friendly names.
• Items migrated in batches of up to 10, replication groups together.
• First recovery point confirmed in the modernized vault for every item.
• Recovery plans rebuilt and test failover completed.
• Classic vault left to expire and purge on its own.

For broader planning of Azure moves, see the enterprise Azure cloud migration playbook, and for VM-level backup alongside disaster recovery, Azure VM backup with Recovery Services vaults.

References

• Classic experience (deprecated) to protect VMware and physical machines
• Prepare infrastructure for migration from classic to modernized
• Move resources from classic to modernized experience
• Common questions about moving from classic to modernized
• Deploy Azure Site Recovery replication appliance - Modernized
• Support requirements for the replication appliance
• VMware VM disaster recovery architecture - Modernized
• What's new in Azure Site Recovery
• Create and customize recovery plans
• Run a test failover to Azure