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

Arthur Kutepov 0 Reputation points

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.

  1. Arthur Kutepov 0 Reputation points

    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.

  2. Jose Benjamin Solis Nolasco 8,561 Reputation points • Volunteer Moderator

    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!

  3. Lakshma Reddy Vattijonnala 830 Reputation points • Microsoft External Staff • Moderator

    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:

    1. Failover to Azure
    2. Commit the failover
    3. Reprotect (enable reverse replication)
    4. 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:

    1. Commit the failover
    2. Go to Recovery Services Vault → Replicated items
    3. Select the VM and run Reprotect
      • Choose target Hyper‑V host (original or new)
    4. Wait for replication to complete (Azure → on‑premises)
    5. Run Planned Failover to perform the failback

    Please refer Official Microsoft Documentation for more information:

  4. Lakshma Reddy Vattijonnala 830 Reputation points • Microsoft External Staff • Moderator

    Hi @Arthur Kutepov We have shared the information about your issue. Let me know if it was helpful or please feel free to comment if you need further assistance.

  5. Lakshma Reddy Vattijonnala 830 Reputation points • Microsoft External Staff • Moderator

    Hi @Arthur Kutepov I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so we can help you to assist further

Sign in to comment

2 answers

  1. Lakshma Reddy Vattijonnala 830 Reputation points • Microsoft External Staff • Moderator

    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:

    1. 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 find the answer helpful, please click "upvote" and accept it. This will help others in the community with similar questions easily find the solution.

    0 comments No comments
    Sign in to comment

  2. AI answer

    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:

    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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).
    6. 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:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer