After failover(using ASR) can we keep on-prem infrastructure (VM's, Disks, applications) on azure by stoping failback to on-prem.

Hi @Kiran Ese ,

Thank you for your post! I was speaking with one of my colleagues from the Azure Site Recovery Team and wanted to add some clarifying details that should assist you with determining the best approach to this process and to help you better understand the answers to these questions.

First, I did want to provide some more clarifying information on the purpose of ASR and also explain to you a new tool we have since created called Azure Migrate which you can review more details about below:

1. ASR primary function is to protect the source machines/VMs (on-prem or Azure) in case of a site disaster (fire/weather/etc) found here.
2. When protected machines are failed over, it is implied that, if not testing/validating, they were victim of such scenarios.
3. When failing over the machines/VMs that are in production, the source machine may or may not be shutdown, as such, the infrastructure remains untouched. This scenario may have conflict implications depending on how the connectivity between Azure and on-prem networks is configured, including IP assignments, and DNS to mention a few.
4. Customers, in the past used ASR to “lift & shift” (migrate) from on-prem, other clouds and from Azure region to another. This is still the case for Azure to Azure migration, however, Microsoft has since developed Azure Migrate for on-prem and cloud migrations which you can learn more about this product here.
5. Similar to ASR “lift & shift”, Azure Migrate may shutdown the source VMs and will not change the infrastructure.
6. Azure Migrate allows for better orchestration and provides better discovery and assessment of the source environment. Also, optimized replication when using VMWare agentless migration.
7. Azure migrate for physical (and other clouds) and VMWare agent-based, as well as Hyper-V will use the same appliances/provider/agent and flows as classic ASR.

To migrate machines to Azure it is recommended to use Azure Migrate for the reasons above.

That said, based on the information you have provided for this scenario, it seems to defeat the objective of both products, as replicating a machine from on-prem and other clouds to Azure or from Azure to Azure regions just to failover/migrate to the destination and shutting down the target VM will not accomplish the purpose of migration nor the protection of the VM:

1. You may failover the VM and keep the source running, however, if the source VM is failed over and keeps running while the target Azure VM is shutdown, the replication is not taking place, after some time, the target VM is neither a candidate for migration or failback as it is stale and outdated.
2. I can’t see the practical use of such operation, if you are trying to save money, then you may not pay for compute charges but will definitely pay for storage for the disks in Azure. (Az migrate has 180 days grace period). The only scenario where I see this useful is if the protected/source VM is a stateless machine, which is hard to fathom because even if the application suffers no updated, it is rarely not the case of the OS/security/etc.

Now, answering your questions directly:

1. Is there a way to stop failback to on-premises?
   ASR follows this cycle: Discovery/protection(replication)/failover/re-protection/failback/re-protect. If by “stop failback” you mean “cancel the failback job” it is possible, though not
   recommended and a permanent state for the reasons explained above.
2. Is it possible to stop or change S2S VPN?
   Please note, S2S VPN is not an ASR topic but happy to help assist. Should a VM be protected using S2S VPN, any changes to the network have to account for the connectivity between on-
   prem infrastructure and ASR endpoints which you can find more information on this process here.
3. What are the challenges/issues if it works?
   Please, refer to my comments above.
4. Can DB servers need to re-configure ? When clustered?
   Assuming SQL: https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/business-continuity-high-availability-disaster-recovery-hadr-overview?view=azuresql,
   https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-sql, https://azure.microsoft.com/en-us/blog/leveraging-azure-site-recovery-with-sql-always-on-availability-groups-for-
   disaster-recovery-to-azure/, https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/move-sql-vm-different-region?view=azuresql
5. Is it possible to set up DR in other Azure regions for this type of scenario?
   Please, see my comments above. https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-move-overview

Please let us know if you have any further questions or concerns and I hope this helps you evaluate which process works best for you to proceed further given your environment.

Thanks!
Carlos V.

----------

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.