For admins running Azure Local clusters in branch offices, factories, hospitals or any other server closet, it means a supported way to fail VMs over to Azure without building and paying for a second site.
What actually changed at GA
Microsoft's Tech Community announcement says Azure Site Recovery for Azure Local is now fully supported for production workloads and available in all Azure Local-supported regions. The post also says the integration now fully supports WDAC in enforce mode.
The WDAC change matters most. In the earlier preview documentation, Microsoft told testers that to test Azure Site Recovery for Azure Local VMs, you can temporarily configure Application Control policy to Audit mode. That meant lowering a security control on your hypervisor hosts to try out a disaster recovery feature, which no security team wants to approve. With GA, that tradeoff is gone.
Before GA, admins had two imperfect choices. An independent technical write-up on Medium put it this way: the supported route was the classic Hyper-V setup: install and register the provider on every node, one at a time, with a registration key that expires in five days. The faster route was a preview extension limited to test environments, with Application Control switched to audit mode.
Section summary:
- The automated, portal-driven integration is now supported for production.
- It's available in all regions that support Azure Local.
- WDAC (Application Control) can stay in enforce mode.
Watch out for documentation lag
Microsoft's own docs don't fully agree yet. The Azure Local VM resiliency guide still says that Azure Site Recovery extension for Azure Local is in preview and only applicable to test environments. For those customers that need a production ready solution, Azure Site Recovery can be configured manually on Azure Local cluster using the Hyper-V to Azure disaster recovery option. The general Site Recovery overview page also still labels the feature Azure Local integration (preview).
The main protection guide, by contrast, has dropped the "(preview)" label from its title. The announcement and the Azure Updates status both say GA, so treat the preview wording elsewhere as stale and expect it to be fixed. If your change board finds the old wording, you'll know why.
How the protection cycle works
The workflow is the standard Hyper-V-to-Azure disaster recovery model, wrapped in an Azure Local front end. Microsoft's guide splits it into these stages:
- Replicate: each VM's virtual hard disk is copied to an Azure Storage account.
- Test failover: a test copy of the VM starts in Azure on an isolated network. Production replication keeps running.
- Fail over (planned or unplanned): the VM runs in Azure even if its original host is down. It starts from its last replicated state, and anything that was only in memory is lost.
- Re-protect: the VM replicates from Azure back to the on-premises system.
- Fail back: a planned failover moves the VM back to Azure Local.
- Reverse replicate: replication to Azure resumes. Only the changes made since the VM was shut down in Azure are sent.
The supported VM types are Windows Generation 1 and 2 and Linux Generation 1 and 2. All four can fail over to Azure and fail back to the same host or a different one.
On replication speed, Microsoft's Site Recovery overview cites replication frequency as low as 30 seconds for Hyper-V. Treat that as the best case. Your actual recovery point depends on how much data your VMs change and how much upload bandwidth your site has.
Prerequisites checklist
Check these before you start:
- A registered Azure Local system with internet access, so it can replicate to Azure.
- Owner permissions on the Recovery Services vault, so the managed identity can be granted access.
- Read/write permissions on the Azure Local resource and its child resources.
- Capacity planning: Microsoft points admins to its capacity planning tool to check what replication and failover will need.
- Hyper-V configured on each host. A missing Hyper-V setup is one of the documented reasons the agent fails to install.
The older preview docs added a requirement that may still apply. They said that if VMs aren't highly available, then the replication would fail. The current GA guide doesn't repeat it, so confirm your target VMs are clustered before you rely on protection.
Step-by-step: preparing infrastructure
Setup starts on the Azure Local resource. Per the current Microsoft Learn guide:
- In the Azure portal, open the Overview pane of the Azure Local system that hosts the VMs you want to protect.
- Go to the Capabilities tab and select the Disaster recovery tile.
- Under Protect, select Protect VM workloads.
- On Replicate VMs to Azure, select Prepare infrastructure.
- Pick an existing Recovery Services vault or create one. A new vault gets the subscription and resource group filled in automatically. Put it in the same location as the system.
- Select or create a Hyper-V site.
- Select or create a replication policy, then select OK.
- Select Prepare infrastructure.
When you start preparation, Azure creates a resource group containing a storage account, the vault and the replication policy. It downloads the Site Recovery agent to every node that hosts VMs. The managed identity fetches the vault registration key and finishes installing the agent. Finally, Azure links the policy to the Hyper-V site and registers the hosts. The manual process used to do all of this one node at a time.
Preparation can take several minutes, depending on how many nodes you have. You can follow progress under the portal's notification bell. Without owner-level access to the target subscription or resource group, you'll get an authorization error.
Enabling replication and confirming success
After preparation finishes, you work in the Recovery Services vault:
- Select Enable replication, then Replicate > Hyper-V machines to Azure.
- Choose your Hyper-V site as the source.
- Set the target subscription and the resource group where VMs will be created after failover. Choose Resource Manager as the deployment model. Microsoft recommends managed disks for storage.
- Optionally specify the Azure virtual network and subnet now. You can also set them later under the replicated VM's Compute and Network settings.
- Select the VMs, along with their OS type, OS disk and data disks.
- Confirm that the replication policy is the one you created during preparation, then select Enable Replication.
What success looks like: under Protected items > Replication items, the VM's Disks view shows both the operating system disk and the data disks as Protected. Until they do, don't assume the VM is covered.
Next, set up an isolated Azure network and run a test failover. Then build recovery plans in the vault. Recovery plans group an application's VMs, set the order they start in and automate recovery tasks, and you can test a whole plan. This matters for multi-tier applications, where starting the app server before the database it depends on just produces a pile of error logs.
Caveats that affect day-to-day operations
A failover isn't invisible to your management tools. Microsoft documents several side effects:
- Arc extensions: you can't see or manage extensions installed through Azure Arc while the VM runs in Azure.
- Guest Configuration policies stop running while the VM is in Azure. Policies that audit OS security or configuration won't run again until the VM is back on-premises, so your compliance reporting has a gap for the duration of the failover.
- Logs are split. Data from Sentinel, Defender and Azure Monitor attaches to the Azure VM during failover, while historical data stays with the Arc-enabled server. Search by computer name instead of resource ID, because portal views that query by resource ID show only part of the data.
- The Azure VM Guest Agent: Microsoft strongly recommends not installing it if the VM might return on-premises. If you must install it, disable extension management, or the guest agent and Arc can conflict over extension state.
Failback to a different cluster has its own catch. Microsoft's resiliency guide says that if your cluster isn't available, you can register another Azure Local cluster to the Azure Site Recovery Hyper-V site and failback the VM to a node on an alternate cluster. In that case, the VM comes back unmanaged and has to be registered and reconnected before you can manage it from Azure again. A VM that fails back to its original cluster reconnects without that step, as long as it's within Azure Arc's 45-day reconnection window.
Troubleshooting the two known issues
| Symptom | Likely cause / fix |
|---|---|
| A node fails to install Site Recovery or register with the service, so its VMs may be unprotected | Check Recovery Services vault > Jobs > Site Recovery Jobs and confirm every machine in the system registered |
| The agent install fails, and the Azure Local portal shows no error details | Hyper-V isn't set up on the host, or the host is already tied to a different Hyper-V site |
Site Recovery or Hyper-V Replica?
Site Recovery isn't the only replication option on Azure Local. Microsoft's comparison lists Replication destinations | Azure Local to Azure | Azure Local to Azure Local for Site Recovery and Hyper-V Replica respectively, and notes that Site Recovery incurs Azure usage costs. Hyper-V Replica has no Azure charge, but you configure it by hand with PowerShell or Failover Cluster Manager, and you need a second cluster to replicate to.
Microsoft's suggestion is to use both: Site Recovery for remote sites with a single cluster, and Hyper-V Replica between larger hubs that have spare hardware.
The bottom line
GA moves the portal-driven, all-nodes-at-once Azure Local integration from a lab feature to something you can use in production, and you no longer have to switch WDAC to audit mode. It doesn't replace backups. Replication copies corruption and ransomware just as reliably as it copies good data, so Microsoft's own resiliency guidance still calls for a backup strategy. It also doesn't remove the need for testing: Microsoft recommends a test failover at least once a month.
If your Azure Local estate has been protected only by a manual Hyper-V setup, or not protected at all, now is a good time to:
- confirm your permissions,
- size the bandwidth,
- prepare the infrastructure, and
- run a test failover.
Until you've run one successfully, you don't really know whether your VMs will come up in Azure.