Merge pull request #237247 from Sharmistha-Rai/main

Correction in how to move section

Author: prmerger-automator[bot]

articles/site-recovery/move-from-classic-to-modernized-vmware-disaster-recovery.md

@@ -19,19 +19,19 @@ This article provides information about the architecture, necessary infrastructu
 
 The components involved in the migration of replicated items of a VMware machine are summarized in the following table:  
 
-|Component|Requirement|
-|---------|-----------|
-|Replicated items in a classic Recovery Services vault| One or more replicated items that are protected using the classic architecture and a healthy configuration server.<br></br>The replicated item should be in a noncritical state and must be replicated from on-premises to Azure with the mobility agent running on version 9.50 or later.|
-|Configuration server used by the replicated items|The configuration server, used by the replicated items, should be in a noncritical state and its components should be upgraded to the latest version (9.50 or later).|  
-|A Recovery Services vault with modernized experience|A Recovery Services vault with modernized experience.|
-|A healthy Azure Site Recovery replication appliance|A noncritical Azure Site Recovery replication appliance, which can discover on-premises machines, with all its components upgraded to the latest version (9.50 or later). The exact required versions are as follows:<br></br>Process server: 9.50<br>Proxy server: 1.35.8419.34591<br>Recovery services agent: 2.0.9249.0<br>Replication service: 1.35.8433.24227|
+| **Component** | **Requirement**
+|---------|-----------
+|Replicated items in a classic Recovery Services vault| One or more replicated items that are protected using the classic architecture and a healthy configuration server.<br></br>The replicated item should be in a noncritical state and must be replicated from on-premises to Azure with the mobility agent running on version 9.50 or later.
+|Configuration server used by the replicated items|The configuration server, used by the replicated items, should be in a noncritical state and its components should be upgraded to the latest version (9.50 or later).
+|A Recovery Services vault with modernized experience|A Recovery Services vault with modernized experience.
+|A healthy Azure Site Recovery replication appliance|A non-critical Azure Site Recovery replication appliance, which can discover on-premises machines, with all its components upgraded to the latest version (9.50 or later). The exact required versions are as follows:<br></br>Process server: 9.50<br>Proxy server: 1.35.8419.34591<br>Recovery services agent: 2.0.9249.0<br>Replication service: 1.35.8433.24227
 
 ## Required infrastructure  
 
 Ensure the following for a successful movement of replicated item: 
 - A Recovery Services vault using the modernized experience.   
   >[!Note] 
-  >Any new Recovery Services vault created will have the modernized experience switched on by default. You can [switch to the classic experience](./vmware-azure-common-questions.md#how-do-i-use-the-classic-experience-in-the-recovery-services-vault-rather-than-the-modernized-experience) but once done, you can’t switch again.   
+  >Any new Recovery Services vault created will have the modernized experience switched on by default. You can not switch to the classic experience, as its deprecation has already been [announced](./vmware-physical-azure-classic-deprecation.md).   
 - An [Azure Site Recovery replication appliance](./deploy-vmware-azure-replication-appliance-modernized.md), which has been successfully registered to the vault, and all its components are in a noncritical state.   
 - The version of the appliance must be 9.50 or later. For a detailed version description, check [here](#architecture). 
 - The vCenter server or vSphere host’s details, where the existing replicated machines reside, are added to the appliance for the on-premises discovery to be successful.  
@@ -121,20 +121,21 @@ Site Recovery will start charging license fee on replicated items in the moderni
 It is important to note that the classic architecture for disaster recovery will be phased out, so users should make sure to switch to the latest and modernized version. The following table provides a comparison of the two architectures to help you choose the right option for securing your machines in the event of a disaster.
 
 
-|Classic architecture| Modernized architecture [New]|
-|---------------------|-----------------------------|
-|Multiple setups required for discovering on-premises data.|**Central discovery** of on-premises data center using discovery service.| 
-|Extensive number of steps required for initial onboarding.|**Simplified the onboarding experience** by automating artifact creation and introduced defaults to reduce required inputs.|  
-|Utilizes a manually downloaded file to obtain cloud context.|**Introduced replication key** for obtaining cloud context when setting up the appliance.|
-|Extensive number of steps required for a simple enable replication process.|**Simplified the enable replication experience** by reducing the number of required inputs and redefining each blade.|
-|Configuration server continues to be an on-premises infrastructure with extensive setup for various components.|Enhanced the appliance by converting all components into Azure hosted microservices. This **simplifies appliance scaling, monitoring, and troubleshooting.**|
-|Need for scale-out process server and master target server in Azure for Linux machines is a hindering requirement.|**Removed** the need to maintain separate **process server and master target server**.| 
-|Used a static passphrase for authentication, which interfered with customer’s business requirements of periodic password rotation.|Introduced **certificate-based authentication**, which is more secure and resolves customer’s security concerns.|
-|Upgrading to an updated version should be done manually and is a cumbersome process.|Introduced **automatic upgrades** for both appliance components and Mobility service.|
-|The configuration server doesn't have high availability and might be at the risk of collapsing.|Implemented **high availability of appliance** to ensure resiliency.|
-|Root credentials should be regularly updated to ensure an error-free upgrade experience.|**Eliminated the requirement to maintain machine’s root credentials** for performing automatic upgrades.|
-|Static IP address should be assigned to configuration server to maintain connectivity.|Introduced **FQDN based connectivity** between appliance and on-premises machines.|
-|Only that virtual network, which has Site-to-Site VPN or Express Route enabled, should be used.|Removed the need to maintain a Site-to-Site VPN or Express Route for reverse replication.|
+|**Classic architecture** | **Modernized architecture [New]**
+|---------------------|-----------------------------
+|Multiple setups required for discovering on-premises data.|**Central discovery** of on-premises data center using discovery service. 
+|Extensive number of steps required for initial onboarding.|**Simplified the onboarding experience** by automating artifact creation and introduced defaults to reduce required inputs.
+|Utilizes a manually downloaded file to obtain cloud context.|**Introduced replication key** for obtaining cloud context when setting up the appliance.
+|Extensive number of steps required for a simple enable replication process.|**Simplified the enable replication experience** by reducing the number of required inputs and redefining each blade.
+|Configuration server continues to be an on-premises infrastructure with extensive setup for various components.|Enhanced the appliance by converting all components into Azure hosted microservices. This **simplifies appliance scaling, monitoring, and troubleshooting.**
+|Need for scale-out process server and master target server in Azure for Linux machines is a hindering requirement.|**Removed** the need to maintain separate **process server and master target server**.
+|Used a static passphrase for authentication, which interfered with customer’s business requirements of periodic password rotation.|Introduced **certificate-based authentication**, which is more secure and resolves customer’s security concerns.
+|Upgrading to an updated version should be done manually and is a cumbersome process.|Introduced **automatic upgrades** for both appliance components and Mobility service.
+|The configuration server doesn't have high availability and might be at the risk of collapsing.|Implemented **high availability of appliance** to ensure resiliency.
+|Root credentials should be regularly updated to ensure an error-free upgrade experience.|**Eliminated the requirement to maintain machine’s root credentials** for performing automatic upgrades.
+|Static IP address should be assigned to configuration server to maintain connectivity.|Introduced **FQDN based connectivity** between appliance and on-premises machines.
+|Only that virtual network, which has Site-to-Site VPN or Express Route enabled, should be used.|Removed the need to maintain a Site-to-Site VPN or Express Route for reverse replication.
+| Third party tool, MySQL, also needs to be setup. |Removed the dependency on any third party tools.
 
 ### What machines should be migrated to the modernized architecture?