Restoring a VM that was failedover to Azure back down to a physical server.

Question

Restoring a VM that was failedover to Azure back down to a physical server.

Arthur Kutepov 0

Good day, everyone,

Me and my IT services team have been experimenting with ASR and have a pretty solid grasp on how it's configured and performed at this point, but, one part we're struggling with is the act of moving a failedover VM that was brought up to Azure back down to the original server, or MORE IDEALLY, a new physical server. We're working with Hyper-V. We have this project where we want to move a client's VMs from VMWare to Hyper-V. Each time I failover, the option to fail back never appears, always greyed out. I feel like I'm doing something wrong. Any advice any professionals can offer would be appreciated.

Lakshma Reddy Vattijonnala 505 Reputation points Microsoft External Staff Moderator

2026-06-12T16:08:24.8766667+00:00
Hi @Arthur Kutepov

The behavior you're observing (the Failback / Planned Failover option being greyed out) is expected in ASR when reverse replication hasn’t been configured yet. After a VM is failed over from Hyper‑V to Azure, it runs in Azure but must first be reprotected (Azure → on‑premises) before failback becomes available.

Recommended Approach:

To enable failback, please follow the sequence below:

Ensure failover is completed and committed

Failback will not be available until the failover has been finalized.

Run Reprotect (critical step)

Navigate to: Recovery Services Vault → Replicated items → Select VM

Click Reprotect and choose your on‑premises Hyper‑V environment as the target

This step reverses replication so the Azure VM starts syncing back to on‑premises.

Wait for replication to complete

Once reprotect finishes and the VM is healthy, the replication direction will be Azure → Hyper‑V

Perform Failback

The Planned Failover option will now be enabled

Use this to fail the VM back from Azure to your Hyper‑V environment

Microsoft confirms that failback is performed using a planned failover from Azure to on‑premises, and that this requires failover to be completed beforehand. Additionally, reprotect is required so that the VM begins replicating back before failback can proceed.

This article describes how to fail back Azure VMs that were created after failover of Hyper-V VMs from an on-premises site to Azure Fail back Hyper-V VMs from Azure with Azure Site Recovery - Azure Site Recovery | Microsoft Learn

Failback to a New Hyper‑V Server

For your migration scenario (VMware → Hyper‑V), this is supported with some considerations:

You can fail back to a different Hyper‑V host (not just the original one)

The target host must:

Be part of the same Hyper‑V site / VMM (if used)

Be registered with the same Recovery Services vault

Have sufficient capacity and proper configuration

You can refer to the official Reprotect Azure virtual machines to the primary region with Azure Site Recovery - Azure Site Recove…

The greyed-out failback option is expected until Reprotect is completed

The required flow is: Failover → Commit → Reprotect → Planned Failover (Failback)

Once reprotect completes successfully, failback will be automatically enabled

If you found the answer useful, you can click "upvote". If you have further questions regarding this answer, feel free to click "Comment".
Arthur Kutepov 0 Reputation points

2026-06-12T16:31:03.2133333+00:00

Thank you Lakshma. I didn't realize "Planned Failover" after committing to the first failover would allow me to fail back to the original server. I don't have a second server to play with, but I imagine, if I configure a second server as a 2nd Hyper-V host, I can select it and fail the VM back to that one instead. Is that right?

Weirdest part is I still didn't see a "reprotect" button anywhere. But it still let me fail back.
Jose Benjamin Solis Nolasco 8,076 Reputation points Volunteer Moderator

2026-06-12T16:45:41.91+00:00
Welcome to Microsoft Q&A

Hello Arthur Kutepov, I hope you are doing well,

Thank you for reaching out. You have touched on two distinct architectural scenarios with Azure Site Recovery (ASR). Let’s clarify both your current Hyper-V testing and your target production migration.

1. Hyper-V Testing and the Missing "Reprotect" Button Your observation is correct. Unlike VMware or physical server topologies, native Hyper-V (without VMM) does not utilize a standalone "Reprotect" button or a dedicated Master Target Server. Because the Azure Site Recovery Provider integrates directly into the Hyper-V host, reverse synchronization is handled natively. To fail back, you simply execute a "Planned Failover" from Azure to on-premises. Furthermore, ASR fully supports Alternate Location Recovery; you can target a secondary Hyper-V host provided it is registered to the same Recovery Services Vault and Hyper-V Site.

2. The Production Block: VMware to Hyper-V Migration While your Hyper-V-to-Hyper-V testing succeeded, you cannot use ASR to migrate your client from VMware to Hyper-V. ASR strictly prohibits cross-hypervisor failbacks. When a VMware VM is replicated to Azure, the platform permanently tags it with a VMware source metadata dependency. During failback, ASR strictly demands an on-premises VMware vCenter environment containing a Master Target Server. It will natively block you from selecting a Hyper-V host. If you attempt this, the client's VMs will be stranded in Azure.

The Recommendation: ASR is a disaster recovery mechanism, not a V2V migration tool. To migrate from VMware to Hyper-V, utilize a dedicated Virtual-to-Virtual conversion utility locally, such as System Center Virtual Machine Manager (SCVMM) or the StarWind V2V Converter, to translate the .vmdk disks to .vhdx prior to spinning them up on the new host.

The greyed‑out failback is expected until reprotect is complete.

Hyper‑V: You can fail back directly once reprotect is done.

VMware/Physical: You must fail back to VMware first, then migrate to Hyper‑V.

If you want to test failback to a new Hyper‑V host, just register that host in the same vault/site — ASR will allow it once reprotect is configured.

😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!
Lakshma Reddy Vattijonnala 505 Reputation points Microsoft External Staff Moderator

2026-06-12T17:32:14.5433333+00:00
Hi @Arthur Kutepov ,

Can you fail back to a new/different Hyper‑V host?

Yes, this is supported, but with the correct setup.

During the failback (planned failover from Azure → on‑premises), you can:

Select a different Hyper‑V host

Or allow ASR to create the VM on new hardware if it doesn’t exist

This is part of the supported alternate location recovery scenario, where ASR recreates the VM on the selected host during failback.

In practice, ensure the target host:

Is part of the same Hyper‑V site / VMM (if used)

Is registered with the same Recovery Services vault

Has sufficient capacity and network configuration

Why might “Reprotect” not be visible?

In Azure Site Recovery, reprotect is a required stage in the failback workflow, not optional.

Microsoft defines the recovery flow as:

Failover to Azure

Commit the failover

Reprotect (enable reverse replication)

Fail back (Planned Failover)

After reprotection completes and the VM is replicating to the primary site, you can perform the failback

If you did not see the Reprotect option but were still able to proceed:

The VM was likely already in a state where:

Reverse replication had been configured or completed, or

The workflow had progressed past reprotect implicitly as part of prior steps

In all supported scenarios, failback depends on reverse replication being in place whether configured explicitly via Reprotect or already established.

For consistent and predictable failback behavior, always follow this sequence:

Commit the failover

Go to Recovery Services Vault → Replicated items

Select the VM and run Reprotect

Choose target Hyper‑V host (original or new)

Wait for replication to complete (Azure → on‑premises)

Run Planned Failover to perform the failback

Please refer Official Microsoft Documentation for more information:

Fail back Hyper‑V VMs from Azure (Microsoft Learn)

Failover and failback workflow in Azure Site Recovery

Reprotect failed-over VMs (reverse replication)

1 answer

Your answer

Arthur Kutepov 0 Reputation points

2026-06-12T16:31:03.2133333+00:00

Thank you Lakshma. I didn't realize "Planned Failover" after committing to the first failover would allow me to fail back to the original server. I don't have a second server to play with, but I imagine, if I configure a second server as a 2nd Hyper-V host, I can select it and fail the VM back to that one instead. Is that right?

Weirdest part is I still didn't see a "reprotect" button anywhere. But it still let me fail back.

Answer 1

For physical or VMware machines that have failed over to Azure using Azure Site Recovery, failback is supported only to VMware virtual machines, not directly to physical servers or to Hyper‑V.

Key points from the supported flow:

Physical servers replicated to Azure can only fail back as VMware VMs
- A VMware infrastructure is required on‑premises to perform failback.
- This is explicitly called out in the failback preparation guidance: physical servers replicated to Azure using Site Recovery can only fail back as VMware VMs.
Why the Fail back option is greyed out
- Failback depends on:
  - An on‑premises configuration server that knows about the original machine.
  - A master target server and vCenter/ESXi environment that meet the VMware failback requirements.
- If the configuration server, master target, vCenter, or required discovery is not in place or not connected, failback will not be available and options will appear disabled.
- Additionally, there are explicit scenarios where failback is not possible, including:
  - Using ESXi 5.5 free edition or vSphere 6 Hypervisor free edition.
  - Certain OS versions (for example, Windows Server 2008 R2 SP1 physical server).
  - VMs that have been migrated or moved to another resource group.
  - Replica Azure VM deleted or not protected back to on‑premises.
Required components for failback To see and use failback, the following must be in place and healthy:
- On‑premises configuration server running and connected to Azure.
- On‑premises master target server (VMware) and process server configured per the VMware failback preparation article.
- Site‑to‑site VPN or ExpressRoute private peering between Azure and on‑premises for failback traffic.
- vCenter Server connected and discovered with appropriate permissions so datastores and VMs are visible.
- No snapshots on the master target server VMs.
- Correct UUID configuration and no UUID clashes if templates were used.
Original vs alternate location recovery
- Original Location Recovery (OLR): fail back to the same on‑premises VMware VM if it still exists and its datastore is accessible to the master target host.
- Alternate location recovery: if the original VM does not exist, fail back to a new VMware VM on a datastore accessible to the master target.
- Failback is only supported to the original vCenter and configuration server; a new configuration server or new vCenter cannot be used for failback of existing Azure replicas.
How this relates to a Hyper‑V migration
- ASR’s physical/VMware‑to‑Azure scenario does not support direct failback to Hyper‑V or to bare‑metal physical servers.
- To move workloads ultimately to Hyper‑V, a typical pattern is:
  1. Use ASR for DR between on‑premises VMware/physical and Azure.
  2. Fail back from Azure to VMware (supported path).
  3. Perform a separate migration from VMware to Hyper‑V (outside ASR’s physical/VMware failback flow).
High‑level failback sequence once prerequisites are met
- Prepare for reprotection and failback:
  - Ensure configuration server, master target, vCenter, connectivity, and permissions are correct.
  - Remove snapshots and resolve any unsupported scenarios listed in the documentation.
- Reprotect Azure VMs to on‑premises (Azure → on‑premises direction) so data starts replicating back.
- When replication is healthy, run failover from Azure to on‑premises (planned/unplanned as appropriate), choosing the desired recovery point.
- Commit the failover to finalize and remove the Azure replicas.

Because of these platform constraints, failing a VM over to Azure and then directly restoring it to a new physical server or to Hyper‑V is not supported with this ASR scenario; failback targets must be VMware VMs managed through the supported VMware/physical‑to‑Azure failback path.

References:

Share via

Restoring a VM that was failedover to Azure back down to a physical server.

1 answer

Your answer