|
1 | 1 | --- |
2 | | -title: Move from classic to modernized VMware disaster recovery. |
| 2 | +title: Move from classic to modernized VMware disaster recovery |
3 | 3 | description: Learn about the architecture, necessary infrastructure, and FAQs about moving your VMware or Physical machine replications from classic to modernized protection architecture. |
4 | 4 | ms.service: azure-site-recovery |
5 | 5 | ms.topic: concept-article |
6 | | -ms.date: 05/23/2024 |
| 6 | +ms.date: 03/26/2025 |
7 | 7 | author: ankitaduttaMSFT |
8 | 8 | ms.author: ankitadutta |
9 | 9 | ms.custom: engagement-fy23 |
@@ -114,87 +114,7 @@ Site Recovery will start charging license fee on replicated items in the moderni |
114 | 114 |
|
115 | 115 | >[!Note] |
116 | 116 | > At one point in time, pricing will only happen using one vault, either the classic or modernized vault. |
117 | | -
|
118 | | -## FAQs |
119 | | - |
120 | | -### Why should I migrate my machines to the modernized architecture? |
121 | | - |
122 | | -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. |
123 | | - |
124 | | - |
125 | | -|**Classic architecture** | **Modernized architecture [New]** |
126 | | -|---------------------|----------------------------- |
127 | | -|Multiple setups required for discovering on-premises data.|**Central discovery** of on-premises data center using discovery service. |
128 | | -|Extensive number of steps required for initial onboarding.|**Simplified the onboarding experience** by automating artifact creation and introduced defaults to reduce required inputs. |
129 | | -|Utilizes a manually downloaded file to obtain cloud context.|**Introduced replication key** for obtaining cloud context when setting up the appliance. |
130 | | -|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. |
131 | | -|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.** |
132 | | -|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**. |
133 | | -|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. |
134 | | -|Upgrading to an updated version should be done manually and is a cumbersome process.|Introduced **automatic upgrades** for both appliance components and Mobility service. |
135 | | -|The configuration server doesn't have high availability and might be at the risk of collapsing.|Implemented **high availability of appliance** to ensure resiliency. |
136 | | -|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. |
137 | | -|Static IP address should be assigned to configuration server to maintain connectivity.|Introduced **FQDN based connectivity** between appliance and on-premises machines. |
138 | | -|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. |
139 | | -| Third party tool, MySQL, also needs to be set up. |Removed the dependency on any third party tools. |
140 | | - |
141 | | -### What machines should be migrated to the modernized architecture? |
142 | | - |
143 | | -All VMware or physical machines that are replicated using a configuration server should be migrated to the modernized architecture. |
144 | | - |
145 | | -### Where should my modernized Recovery Services vault be created? |
146 | | - |
147 | | -The modernized Recovery Services vault should be located in the same region and tenant as the classic vault. It can be a part of any subscription or resource group. |
148 | | - |
149 | | -### Will my replication continue while the migration is happening? |
150 | | - |
151 | | -No, the replication will break for some time while the migration is in progress. During this time, the last created recovery point, in the classic Recovery Services vault, will be available for you to failover to. Once the migration is complete, a new recovery point is generated in the modernized Recovery Services vault. |
152 | | - |
153 | | -### When will my migration operation be marked as complete? |
154 | | - |
155 | | -Migration operation will only be marked complete once the first recovery point has been successfully created in the modernized Recovery Services vault. |
156 | | - |
157 | | -### What operations can be performed from my classic Recovery Services vault, after migration is done? |
158 | | - |
159 | | -You can perform failover from your classic vault after the migration. The failover operation will continue to be available in the classic vault until the recovery points expire. |
160 | | - |
161 | | -For example, if the retention period for a replicated item is 72 hours (three days), the latest recovery point on the classic vault will continue to be available for 72 hours (three days), after a successful migration. After the stipulated time, Azure Site Recovery will automatically trigger a purge replication operation on the replicated item and perform the cleanup of all associated storage and billing-causing items. |
162 | | - |
163 | | -### What if a disaster strikes my machine while the migration operation is in progress? |
164 | | - |
165 | | -Any replicated item that is undergoing migration can still support the failover operation through the classic Recovery Services vault until the retention period for the final recovery point has ended. If you try to execute a failover operation, it will take precedence over the migration operation and the migration job is aborted. To ensure that your replicated item is migrated, you'll need to trigger the migration operation again at a later time. |
166 | | - |
167 | | ->[!Note] |
168 | | -> The Compute and Network properties of replicated items can be updated while the migration is in progress. However, the changes may not get replicated in the modernized Recovery Services vault. |
169 | | -
|
170 | | -### How many machines can I migrate in one go from classic to modernized vault? |
171 | | - |
172 | | -You can migrate up to 10 machines via the portal, in one go. |
173 | | - |
174 | | -### Should I recreate the virtual networks, storage accounts, and replication policy to be used in the new vault? |
175 | | - |
176 | | -No, the same resources, which were being used previously will be defaulted to in the modernized vault also. You can always change those from the **Compute** and **Network** blade of your replicated item. You must ensure that the resources continue to have the required access. |
177 | | - |
178 | | -### How will my replication policies be moved to the modernized vault? |
179 | | - |
180 | | -As a prerequisite, Site Recovery will create replication policies in the modernized vault with the same configuration as in the classic vault. So, before a replicated item is moved, the associated policy is created in the modernized vault. We recommend that you avoid making changes to the configuration of replication policies in the classic vault after the migration has been triggered, as these changes won't be reflected in the modernized vault. It's best to make these changes before starting the migration process. |
181 | 117 | |
182 | | -The replication policy created in the modernized vault will have its name changed in the modernized vault. It is prefixed with resource group name and vault name of the modernized Recovery Services vault. So, if the policy name was “default replication policy” in the classic vault, then in the modernized vault, this policy’s name is `default replication policy contoso-modern-vault_contoso-rg`, given the vault’s name is contoso-modern-vault and the vault’s resource group is contoso-rg. |
183 | | - |
184 | | -### Can I edit my replication policy during migration or post migration in the classic vault? |
185 | | - |
186 | | -If the replica of a replication policy has already been created in the modernized vault, then any changes to the policy in the classic vault won't be propagated to the modernized vault. |
187 | | - |
188 | | -So, if there are 10 replicated items, that are replicated using a policy and you decide to move 5 of those to the modernized experience, then a copy of the policy is created before migration starts. Now, before performing migration of the remaining five items, if any changes are made in the policy in classic vault, the policy from modernized vault won't be updated. You'll need to make those configuration changes in the modernized vault too. |
189 | | - |
190 | | -### How do I migrate replicated items, which are present in a replication group, also known as multi-vm consistency groups? |
191 | | - |
192 | | -All replicated items that are part of a replication group are migrated together. You can select all of them by selecting the replication group or skip them all. If the migration process fails for some machines in a replication group but succeeds for others, a rollback to the classic experience is performed for the failed replicated items and the migration process can be triggered again for those items. |
193 | | - |
194 | | -### Can I migrate my classic setup with public endpoint to modernized setup with private endpoint? |
195 | | - |
196 | | -No, you can only move classic disaster recovery setup with public endpoint to modernized public endpoint setup. |
197 | | -Note that, non-private endpoint to private endpoint migration is not supported, but private endpoint to private endpoint migration is supported. |
198 | 118 |
|
199 | 119 | ## Next steps |
200 | 120 |
|
|
0 commit comments