Migrate Microsoft SQL Server Always On availability group using AWS Application Migration Service

Initialize AWS MGN.

Initialize AWS MGN in the target AWS Region. This creates the required IAM roles and policies. For more information, see Initializing Application Migration Service with the console.

Create replication and launch templates.

Configure the replication and launch templates for use with AWS MGN. For more information, see Configuring the templates in the AWS documentation.

Allow communication ports.

To enable network communications for AWS MGN, allow traffic over TCP ports 443 and 1500. For more information, see Network requirements for Application Migration Service in the AWS documentation.

Verify AWS MGN prerequisites.

Verify that the source servers meet the prerequisites for the AWS MGN agent installation. For more information, see Installation requirements in the AWS documentation.

Install AWS MGN agent.

Install the AWS MGN agent on the source servers. During the installation, choose the AWS Region where the servers will be migrated. After installation, the agent communicates with the service and starts replication. For more information, see Installing the AWS Replication Agent on Windows servers.

Check source server status.

In the AWS MGN console, check the status of source servers. The servers display Ready for testing when replication begins.

If you encounter any errors, see Troubleshooting communication errors in the AWS MGN documentation.

Optimize replication settings.

SQL Always On clusters use high I/O synchronous replication from the primary server to the secondary server. To optimize replication and avoid lag, use a dedicated replication server for each SQL Always On server.

If the database is greater than 5 TB, consider choosing a larger replication server instance size such as m5.large instead of the default t3.small.

Update launch template.

Update the launch settings and choose subnets for the SQL Always On servers. The SQL Always On cluster servers are spread across different AWS Availability Zones for high availability.

Update launch settings.

Based on your size and performance requirements, update the instance type and input/output operations per second (IOPS) in the launch settings.

(Optional) Choose an existing elastic network interface in the launch settings.

Verify source servers.

In the AWS MGN console, verify that the source server status is Ready for testing.

Launch the test instances.

Test for connectivity and database integrity.

Test the connectivity and database integrity of the test instances. Then mark the source servers as Ready for cutover in the AWS MGN console.

Test the database integrity.

This helps to ensure there are no database integrity issues at the source prior to migration. Run DBCC CHECKDB and specify WITH_PHYSICAL_ONLY. Running this check without WITH_PHYSICAL_ONLY can cause performance issues at the source. To maintain database integrity, run a weekly full check of the database.

These commands check the database’s logical and physical integrity by detecting potential corruption issues. The check verifies the database’s structure, such as pages, rows, indexes, and system tables.

Test the connections to linked servers.

Test the connections among all existing servers, and document their status. This helps to ensure that linked servers work as intended after the migration.

Verify the backups.

Confirm the integrity of source backups.

Stop the SQL Server and cluster services.

Stop the SQL Server and Microsoft cluster services on all SQL cluster nodes.

Verify the servers.

In the AWS MGN console, verify that the status of the source servers is Ready for cutover and that the data replication status is Healthy.

Launch the cutover.

For more information, see Launching a cutover instance in the AWS MGN documentation.

Test the launched servers.

Log in to the launched Amazon EC2 instances and validate the cluster’s health. Verify that the servers are in the correct subnets, the instance size and IOPS settings are correct, and the witness server is accessible.

Update the cluster IP address.

Update the cluster IP address for the Windows cluster using the two reserved IP addresses in the target subnets. For more information, see Change the IP Address of a Failover Cluster Instance.

Update the Always On availability group listener IPs.

Verify the connection.

Using SSMS, connect to the Always On availability group listener, and confirm that the connection succeeds.

Check the health of Always On availability group.

Check the error log.

Open the error log, and verify any errors reported for the SQL Server instance. Ensure that the recovery is complete for all databases.

Test the linked servers.

Test the connectivity of any linked servers. In case of any connectivity issues, ensure that the target server and port are accessible.

Finalize the cutover.

After you validate the target SQL Always On clusters, finalize the cutover through the AWS MGN console. This stops data replication from the source servers and discards the data from the replication server. It also removes the replication server and its associated resources.