Merge pull request #116141 from ianmsgit/vmware-sql-migrations

move tested configs sections

Author: Jak-MS

articles/azure-vmware/migrate-sql-server-always-on-availability-group.md

@@ -14,6 +14,10 @@ In this article, you learn how to migrate a SQL Server Always On Availability Gr
 
 :::image type="content" source="media/sql-server-hybrid-benefit/sql-always-on-architecture.png" alt-text="Diagram showing the architecture of Always On SQL Server for  Azure VMware Solution." border="false" lightbox="media/sql-server-hybrid-benefit/sql-always-on-architecture.png":::
 
+## Tested configurations
+
+Microsoft SQL Server (2019 and 2022) was tested with Windows Server (2019 and 2022) Data Center edition with the virtual machines deployed in the on-premises environment. Windows Server and SQL Server have been configured following best practices and recommendations from Microsoft and VMware. The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.
+
 ## Prerequisites
 
 These are the prerequisites to migrating your SQL Server instance to Azure VMware Solution.
@@ -25,25 +29,30 @@ These are the prerequisites to migrating your SQL Server instance to Azure VMwar
 - VMware HCX must be configured between your on-premises datacenter and the Azure VMware Solution private cloud that runs the migrated workloads. For more information on how to configure HCX, see [Azure VMware Solution documentation](install-vmware-hcx.md).
 - Ensure that all the network segments in use by SQL Server and workloads using it are extended into your Azure VMware Solution private cloud. To verify this step, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
 
-VMware HCX over VPN is supported in Azure VMware Solution for workload migration.
-However, due to the size of database workloads, VMware HCX over VPN is not recommended for Microsoft SQL Server Always On FCI or AG migrations for production workloads.
-ExpressRoute connectivity is recommended as more performant and reliable. 
-For Microsoft SQL Server standalone and non-production workloads this may be suitable, depending upon the size of the database, to migrate. 
+Either VMware HCX over VPN or ExpressRoute connectivity can be used as the networking configuration for the migration.
+VMWare HCX over VPN, due to its limited bandwidth, is typically suited for workloads that can sustain longer periods of downtime (such as non-production environments). 
+
+For any of the following scenarios, ExpressRoute connectivity is recommended for a migration:
+
+- Production environments
+- Workloads with large database sizes
+- Any case where there is a need to minimize downtime for migration the ExpressRoute connectivity is recommended for the migration.
+
+Further downtime considerations are discussed in the next section.
 
-Microsoft SQL Server (2019 and 2022) was tested with Windows Server (2019 and 2022) Data Center edition with the virtual machines deployed in the on-premises environment. Windows Server and SQL Server have been configured following best practices and recommendations from Microsoft and VMware. The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.
 
 ## Downtime considerations
 
 Downtime during a migration depends upon the size of the database to be migrated and the speed of the private network connection to Azure cloud.
 While SQL Server Availablity Group migrations can be executed with minimal solution downtime, it is optimal to conduct the migration during off-peak hours within a pre-approved change window.
 
-The table below indicates the estimated downtime for migraton of each SQL Server topology.
+The following table indicates the estimated downtime for migration of each SQL Server topology.
 
 | **Scenario** | **Downtime expected** | **Notes** |
 |:---|:-----|:-----|
-| **Standalone instance** | Low | Migrate with VMware vMotion, the database is available during migration, but it is not recommended to commit any critical data during it. |
-| **Always On Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
-| **Always On     Failover Cluster Instance** | High | All nodes of the cluster are shutdown and migrated using VMware HCX Cold Migration. Downtime duration depends upon database size and private network speed to Azure cloud. |
+| **Standalone instance** | Low | Migration is done using VMware vMotion, the database is available during migration time, but it isn't recommended to commit any critical data during it. |
+| **Always On SQL Server Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
+| **Always On SQL Server Failover Cluster Instance** | High | All nodes of the cluster are shutdown and migrated using VMware HCX Cold Migration. Downtime duration depends upon database size and private network speed to Azure cloud. |
 
 ## Windows Server Failover Cluster quorum considerations
 

articles/azure-vmware/migrate-sql-server-failover-cluster.md

@@ -24,6 +24,12 @@ However, you can overcome this limitation by performing the steps shown in this
 > [!NOTE]
 > This procedure requires a full shutdown of the cluster. Since the SQL Server service will be unavailable during the migration, plan accordingly for the downtime period.  
 
+## Tested configurations
+
+Microsoft SQL Server 2019 and 2022 were tested with Windows Server 2019 and 2022 Data Center edition with the virtual machines deployed in the on-premises environment. 
+Windows Server and SQL Server have been configured following best practices and recommendations from Microsoft and VMware. 
+The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.
+
 ## Prerequisites
 
 - Review and record the storage and network configuration of every node in the cluster.
@@ -34,27 +40,30 @@ However, you can overcome this limitation by performing the steps shown in this
 - VMware HCX must be configured between your on-premises datacenter and the Azure VMware Solution private cloud that runs the migrated workloads. For more details about installing VMware HCX, see [Azure VMware Solution documentation](install-vmware-hcx.md).
 - Ensure that all the network segments in use by SQL Server and workloads using it are extended into your Azure VMware Solution private cloud. To verify this step, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
 
-VMware HCX over VPN is supported in Azure VMware Solution for workload migration.
-However, due to the size of database workloads it isn't recommended for Microsoft SQL Server Failover Cluster Instance and Microsoft SQL Server Always On migrations, especially for production workloads.
-ExpressRoute connectivity is recommended as more performant and reliable.
-For Microsoft SQL Server Standalone and non-production workloads this can be suitable, depending upon the size of the database, to migrate.
+Either VMware HCX over VPN or ExpressRoute connectivity can be used as the networking configuration for the migration.
+VMWare HCX over VPN, due to its limited bandwidth, is typically suited for workloads that can sustain longer periods of downtime (such as non-production environments). 
+
+For any of the following scenarios, ExpressRoute connectivity is recommended for a migration:
+
+- Production environments
+- Workloads with large database sizes
+- Any case where there is a need to minimize downtime for migration the ExpressRoute connectivity is recommended for the migration.
+
+Further downtime considerations are discussed in the next section.
 
-Microsoft SQL Server 2019 and 2022 were tested with Windows Server 2019 and 2022 Data Center edition with the virtual machines deployed in the on-premises environment. 
-Windows Server and SQL Server have been configured following best practices and recommendations from Microsoft and VMware. 
-The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.
 
 ## Downtime considerations
 
 Downtime during a migration depends on the size of the database to be migrated and the speed of the private network connection to Azure cloud.
 Migration of SQL Server Failover Cluster Instances Always On to Azure VMware Solution requires a full downtime of the database and all cluster nodes, however you should plan for the migration to be executed during off-peak hours with an approved change window.
 
-The table below indicates the downtime for each Microsoft SQL Server topology.
+The following table indicates the estimated downtime for migration of each SQL Server topology.
 
 | **Scenario** | **Downtime expected** | **Notes** |
 |:---|:-----|:-----|
-| **Standalone instance** | Low | Migration will be done using vMotion, the database will be available during migration time, but it isn't recommended to commit any critical data during it. |
-| **Always-On SQL Server Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
-| **Always On SQL Server Failover Cluster Instance** | High | All nodes of the cluster will be shut down and migrated using VMware HCX Cold Migration. Downtime duration will depend upon database size and private network speed to Azure cloud. |
+| **Standalone instance** | Low | Migration is done using VMware vMotion, the database is available during migration time, but it isn't recommended to commit any critical data during it. |
+| **Always On SQL Server Availability Group** | Low | The primary replica will always be available during the migration of the first secondary replica and the secondary replica will become the primary after the initial failover to Azure. |
+| **Always On SQL Server Failover Cluster Instance** | High | All nodes of the cluster are shutdown and migrated using VMware HCX Cold Migration. Downtime duration depends upon database size and private network speed to Azure cloud. |
 
 ## Windows Server Failover Cluster quorum considerations
 

articles/azure-vmware/migrate-sql-server-standalone-cluster.md

@@ -24,6 +24,14 @@ VMware HCX Cold Migration is also valid, but it requires a longer downtime perio
 
 :::image type="content" source="media/sql-server-hybrid-benefit/migrated-sql-standalone-cluster.png" alt-text="Diagram showing the architecture of Standalone SQL Server for  Azure VMware Solution." border="false" lightbox="media/sql-server-hybrid-benefit/migrated-sql-standalone-cluster.png"::: 
 
+## Tested configurations
+This scenario was validated using the following editions and configurations:
+
+- Microsoft SQL Server (2019 and 2022)  
+- Windows Server (2019 and 2022) Data Center edition  
+- Windows Server and SQL Server were configured following best practices and recommendations from Microsoft and VMware.  
+- The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.+
+
 ## Prerequisites
 
 - Review and record the storage and network configuration of every node in the cluster.
@@ -34,28 +42,23 @@ VMware HCX Cold Migration is also valid, but it requires a longer downtime perio
 - Configure VMware HCX between your on-premises datacenter and the Azure VMware Solution private cloud that runs the migrated workloads. For more information about configuring VMware HCX, see [Azure VMware Solution documentation](install-vmware-hcx.md).
 - Ensure that all the network segments in use by the SQL Server and workloads using it are extended into your Azure VMware Solution private cloud. To verify this step in the process, see [Configure VMware HCX network extension](configure-hcx-network-extension.md).
 
-Either VMware HCX over VPN or ExpressRoute connectivity can be used as the networking configuration for the migration. 
+Either VMware HCX over VPN or ExpressRoute connectivity can be used as the networking configuration for the migration.
+VMWare HCX over VPN, due to its limited bandwidth, is typically suited for workloads that can sustain longer periods of downtime (such as non-production environments). 
 
-With VMWare HCX over VPN, due to its limited bandwidth it is typically suited for workloads that can sustain longer periods of downtime (such as non-production environments).
+For any of the following scenarios, ExpressRoute connectivity is recommended for a migration:
 
-For production environments, or workloads with large database sizes or where there is a need to minimize downtime the ExpressRoute connectivity is recommended for the migration.  
+- Production environments
+- Workloads with large database sizes
+- Any case where there is a need to minimize downtime for migration the ExpressRoute connectivity is recommended for the migration.
 
 Further downtime considerations are discussed in the next section.
 
-This scenario was validated using the following editions and configurations:
-
-- Microsoft SQL Server (2019 and 2022)  
-- Windows Server (2019 and 2022) Data Center edition  
-- Windows Server and SQL Server were configured following best practices and recommendations from Microsoft and VMware.  
-- The on-premises source infrastructure was VMware vSphere 7.0 Update 3 and VMware vSAN running on Dell PowerEdge servers and Intel Optane P4800X SSD NVMe devices.
-
-
 ## Downtime considerations
 
 Downtime during a migration depends on the size of the database to be migrated and the speed of the private network connection to Azure cloud.
 Migration of a  SQL Server standalone instance using the VMware HCX vMotion mechanism is intended to minimize the solution downtime, however we still recommend the migration take place during off-peak hours within an pre-approved change window.
 
-This table indicates the estimated downtime for migration of each SQL Server topology.
+The following table indicates the estimated downtime for migration of each SQL Server topology.
 
 | **Scenario** | **Downtime expected** | **Notes** |
 |:---|:-----|:-----|