# Migrating a SQL Server Database to Amazon Aurora MySQL
<a name="chap-sqlserver2aurora"></a>

Using this walkthrough, you can learn how to migrate a Microsoft SQL Server database to an Amazon Aurora MySQL-Compatible Edition database using the AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS). AWS DMS migrates your data from your SQL Server source into your Aurora MySQL target.

 AWS DMS doesn’t migrate your secondary indexes, sequences, default values, stored procedures, triggers, synonyms, views, and other schema objects that aren’t specifically related to data migration. To migrate these objects to your Aurora MySQL target, use AWS SCT.

To estimate what it will cost to run this walkthrough on AWS, you can use the AWS Pricing Calculator. For more information, see [https://calculator.aws/](https://calculator.aws/).

To avoid additional charges, delete all resources after you complete the walkthrough.

**Topics**
+ [

# Prerequisites for Migrating from a SQL Server database to Amazon Aurora MySQL
](chap-sqlserver2aurora.prerequisites.md)
+ [

# Step-by-step SQL Server database to Amazon Aurora MySQL migration walkthrough
](chap-sqlserver2aurora.steps.md)
+ [

# SQL Server database migration to Amazon Aurora MySQL troubleshooting
](chap-sqlserver2aurora.steps.troubleshooting.md)

# Prerequisites for Migrating from a SQL Server database to Amazon Aurora MySQL
<a name="chap-sqlserver2aurora.prerequisites"></a>

The following prerequisites are required to complete this walkthrough:
+ An understanding of Amazon Relational Database Service (Amazon RDS), the applicable database technologies, and SQL.
+ Create a user with AWS Identity and Access Management (IAM) credentials that allows you to launch Amazon RDS and AWS Database Migration Service (AWS DMS) instances in your AWS Region. For information about IAM credentials, see [Setting up for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SettingUp.html#CHAP_SettingUp.IAM).
+ An understanding of the Amazon Virtual Private Cloud (Amazon VPC) service and security groups. For information about using Amazon VPC with Amazon RDS, see [Amazon Virtual Private Cloud (VPCs) and Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.html). For information about Amazon RDS security groups, see [Amazon RDS Security Groups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html).
+ An understanding of the supported features and limitations of AWS DMS. For information about AWS DMS, see https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html.
+ An understanding of how to work with Microsoft SQL Server as a source and Amazon Aurora MySQL as a target. For information about working with SQL Server as a source, see [Using a SQL Server Database as a Source](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html). Aurora MySQL is a MySQL-compatible database. For information about working with Aurora MySQL as a target, see [Using a MySQL-Compatible database as a target](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html).
+ An understanding of the supported data type conversion options for SQL Server and Aurora MySQL. For information about data types for SQL Server as a source, see [Source Data Types for Microsoft SQL Server](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Reference.Source.SQLServer.DataTypes.html). For information about data types for Aurora MySQL; as a target, see [Target Data Types for MySQL](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Reference.Target.MySQL.DataTypes.html).
+ Size your target Aurora MySQL database host. DBAs should be aware of the load profile of the current source SQL Server database host. Consider CPU, memory, and IOPS. With Amazon RDS, you can size up the target database host, or reduce it, after the migration. If this is the first time that you’re migrating to Aurora MySQL, we recommended that you have extra capacity to account for performance issues and tuning opportunities.
+ Audit your source SQL Server database. For each schema and all the objects under each schema, determine whether any of the objects are no longer being used. Deprecate these objects on the source SQL Server database, because there’s no need to migrate them if they aren’t being used.
+ Decide between these migration options: migrate existing data only or migrate existing data and replicate ongoing changes.
  + If you migrate existing data only, the migration is a one-time data transfer from a SQL Server source database to the Aurora MySQL target database. If the source database remains open to changes during the migration, these changes must be applied to the target database after the migration is complete.
**Note**  
If the SQL Server database is an Amazon RDS database, replication is not supported, and you must use the option to migrate existing data only.
  + If you migrate existing data and replicate ongoing changes, one option is to replicate the source database changes. Replication keeps the source and target databases in sync with each other during the migration process and can reduce database downtime. With this option, you complete an initial sync operation and then configure MS-REPLICATION. This option requires the Standard, Enterprise, or Developer SQL Server edition. You enable MS-REPLICATION for each SQL Server instance that you want to use as a database source.
  + If you want to migrate existing data and replicate ongoing changes, another option is change data capture (CDC) instead of replication. This option allows AWS DMS to perform ongoing migration of data. In the case of CDC, AWS DMS uses the CDC tables to enable ongoing database migration. This option requires the Standard, Enterprise or Developer edition of SQL Server.

For more information about AWS DMS, see [Getting started with Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).

# Step-by-step SQL Server database to Amazon Aurora MySQL migration walkthrough
<a name="chap-sqlserver2aurora.steps"></a>

The following steps provide instructions for migrating a Microsoft SQL Server database to an Amazon Aurora MySQL database. These steps assume that you have already prepared your source database as described in [Prerequisites](chap-sqlserver2aurora.prerequisites.md).

**Topics**
+ [

# Step 1: Install the SQL Drivers and AWS Schema Conversion Tool on Your Local Computer
](chap-sqlserver2aurora.steps.installsct.md)
+ [

# Step 2: Configure Your Microsoft SQL Server Source Database
](chap-sqlserver2aurora.steps.configuresqlserver.md)
+ [

# Step 3: Configure Your Aurora MySQL Target Database
](chap-sqlserver2aurora.steps.configureaurora.md)
+ [

# Step 4: Use AWS SCT to Convert the SQL Server Schema to Aurora MySQL
](chap-sqlserver2aurora.steps.convertschema.md)
+ [

# Step 5: Create an AWS DMS Replication Instance
](chap-sqlserver2aurora.steps.createreplicationinstance.md)
+ [

# Step 6: Create AWS DMS Source and Target Endpoints
](chap-sqlserver2aurora.steps.createsourcetargetendpoints.md)
+ [

# Step 7: Create and Run Your AWS DMS Migration Task
](chap-sqlserver2aurora.steps.createmigrationtask.md)
+ [

# Step 8: Cut Over to Aurora MySQL
](chap-sqlserver2aurora.steps.cutover.md)

# Step 1: Install the SQL Drivers and AWS Schema Conversion Tool on Your Local Computer
<a name="chap-sqlserver2aurora.steps.installsct"></a>

First, install the SQL drivers and the AWS Schema Conversion Tool (AWS SCT) on your local computer. Do the following:

1. Download the JDBC driver for Microsoft SQL Server [mssql-jdbc-7.2.2.jre11.jar](https://docs.microsoft.com/en-us/sql/connect/jdbc/release-notes-for-the-jdbc-driver?view=sql-server-ver15#72).

1. Download the [JDBC driver for Aurora MySQL](https://dev.mysql.com/downloads/connector/j/). Amazon Aurora MySQL uses the MySQL driver.

1. Install AWS SCT and the required JDBC drivers.

   1. See [Installing, verifying, and updating the Schema Conversion Tool](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Installing.html), and choose the appropriate link to download AWS SCT.

   1. Start AWS SCT, and choose **Settings**, **Global settings**.

   1. In **Global settings**, choose **Drivers**, and then choose **Browse** for **Microsoft SQL Server driver path**. Locate the JDBC driver for SQL Server, and choose **OK**.

   1. Choose **Browse** for **MySQL driver path**. Locate the JDBC driver you downloaded for Aurora MySQL, and choose **OK**.  
![\[Locating JDBC Drivers\]](http://docs.aws.amazon.com/dms/latest/sbs/images/sbs-rdsqlserver2aurora-drivers.png)

   1. Choose **OK** to close the **Global settings** dialog box.

# Step 2: Configure Your Microsoft SQL Server Source Database
<a name="chap-sqlserver2aurora.steps.configuresqlserver"></a>

After installing the SQL drivers and AWS Schema Conversion Tool, you can configure your Microsoft SQL Server source database using one of several options, depending on how you plan to migrate your data.

When configuring your source database, you can choose to migrate existing data only, migrate existing data and replicate ongoing changes, or migrate existing data and use change data capture (CDC) to replicate ongoing changes. For more information about these options, see [Prerequisites](chap-sqlserver2aurora.prerequisites.md).

 **Migrating existing data only** 

No configuration steps are necessary for the SQL Server database. You can move on to [Step 3: Configure Your Aurora MySQL Target Database](chap-sqlserver2aurora.steps.configureaurora.md).

**Note**  
If the SQL Server database is an Amazon RDS database, replication is not supported, and you must use the option for migrating existing data only.

 **Migrating existing data and replicating ongoing changes** 

To configure MS-REPLICATION, complete the following steps:

1. In Microsoft SQL Server Management Studio, open the context (right-click) menu for the **Replication** folder, and then choose **Configure Distribution**.

1. In the **Distributor** step, choose ** *db\$1name* will act as its own distributor**. SQL Server creates a distribution database and log.

   For more information, see [Microsoft documentation](https://docs.microsoft.com/en-us/sql/relational-databases/replication/enable-a-database-for-replication-sql-server-management-studio).

   When the configuration is complete, your server is enabled for replication. Either a distribution database is in place, or you have configured your server to use a remote distribution database.

**Note**  
Replication requires a primary key for all tables that are being replicated. If your tables don’t have primary keys defined, consider using CDC instead.

 **Migrating existing data and using change data capture (CDC) to replicate ongoing changes** 

To configure MS-CDC, complete the following steps:

1. Connect to SQL Server with a login that has SYSADMIN role membership.

1. For each database containing data that is being migrated, run the following command within the database context:

   ```
   use [DBname]
   EXEC sys.sp_cdc_enable_db
   ```

1. For each table that you want to configure for ongoing migration, run the following command:

   ```
   EXEC sys.sp_cdc_enable_table @source_schema = N'schema_name', @source_name = N'table_name', @role_name = NULL;
   ```

   For more information, see [Microsoft documentation](https://docs.microsoft.com/en-us/sql/relational-databases/track-changes/enable-and-disable-change-data-capture-sql-server).

**Note**  
If you are migrating databases that participate in an Always On Availability Group, it is best practice to use replication for migration. To use this option, publishing must be enabled, and a distribution database must be configured for each node of the Always On Availability Group. Additionally, ensure you are using the name of the availability group listener for the database rather than the name of the server currently hosting the availability group database for the target server name. These requirement apply to each instance of SQL Server in the cluster and must not be configured using the availability group listener.
If your database isn’t supported for MS-REPLICATION or MS-CDC (for example, if you are running the Workgroup Edition of SQL Server), some changes can still be captured, such as `INSERT` and `DELETE` statements, but other DML statements such as `UPDATE` and `TRUNCATE TABLE` will not be captured. Therefore, a migration with continuing data replication is not recommended in this configuration, and a static one time migration (or repeated one time full migrations) should be considered instead.

For more information about using MS-REPLICATION and MS-CDC, see [Configuring a Microsoft SQL Server Database as a Replication Source](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.SQLServer.html#CHAP_Source.SQLServer.Configuration).

# Step 3: Configure Your Aurora MySQL Target Database
<a name="chap-sqlserver2aurora.steps.configureaurora"></a>

 AWS DMS migrates the data from the SQL Server source into an Amazon Aurora MySQL target. In this step, you configure the Aurora MySQL target database.

1. Create the AWS DMS user to connect to your target database, and grant Superuser or the necessary individual privileges (or for Amazon RDS, use the master username).

   Alternatively, you can grant the privileges to an existing user.

   ```
   CREATE USER 'aurora_dms_user' IDENTIFIED BY 'password';
   
   GRANT ALTER, CREATE, CREATE TEMPORARY TABLES, DROP, INDEX, INSERT, UPDATE, DELETE,
   SELECT ON target_database.* TO 'aurora_dms_user';
   ```

1.  AWS DMS uses control tables on the target in the database `awsdms_control`. Use the following command to ensure that the user has the necessary access to the `awsdms_control` database:

   ```
   GRANT ALL PRIVILEGES ON awsdms_control.* TO 'aurora_dms_user';
   FLUSH PRIVILEGES;
   ```

# Step 4: Use AWS SCT to Convert the SQL Server Schema to Aurora MySQL
<a name="chap-sqlserver2aurora.steps.convertschema"></a>

Before you migrate data to Amazon Aurora MySQL, convert the Microsoft SQL Server schema to an Aurora MySQL schema using the AWS Schema Conversion Tool (AWS SCT). [This video covers all the steps of this process](https://youtu.be/1mwrggZe5UM).

To convert a SQL Server schema to an Aurora MySQL schema, do the following:

1. Launch AWS SCT. In AWS SCT, choose **File**, then choose **New Project**. Create a new project named ` AWS Schema Conversion Tool SQL Server to Aurora MySQL`, specify the **Location** of the project folder, and then choose **OK**.

1. Choose **Add source** to add a source Microsoft SQL Server database to your project, then choose **Microsoft SQL Server**, and choose **Next**.

1. Enter the following information, and then choose **Test connection**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.convertschema.html)  
![\[Test Connection to SQL Server Database\]](http://docs.aws.amazon.com/dms/latest/sbs/images/sbs-rdsqlserver2aurora-sctconnectsqlserv.png)

1. Choose **OK** to close the alert box. Then choose **Connect** to close the dialog box and connect to the Microsoft SQL Server database instance. AWS SCT displays the structure of the Microsoft SQL Server database instance in the left panel.

1. Choose **Add target** to add a target Amazon Aurora MySQL database to your project, then choose **Amazon Aurora (MySQL compatible)**, and choose **Next**.

1. Enter the following information and then choose **Test Connection**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.convertschema.html)

1. Choose **OK** to close the alert box. Then choose **Connect** to close the dialog box and connect to the Aurora MySQL database instance.

1. In the tree in the left panel, select the schema to migrate. In the tree in the right panel, select your target Aurora MySQL database. Choose **Create mapping**.

1. Choose **Main view**. In the tree in the left panel, right-click the HR schema and choose **Create report**.  
![\[Creating a mapping rule\]](http://docs.aws.amazon.com/dms/latest/sbs/images/sbs-rdsqlserver2aurora-sctconvert.png)

1. Open the context (right-click) menu for the schema to migrate, and then choose **Convert schema**.

1. Choose **Yes** for the confirmation message. AWS SCT analyzes the schema, creates a database migration assessment report, and converts your schema to the target database format.

1. Choose **Assessment Report View** from the menu to check the database migration assessment report. The report breaks down by each object type and by how much manual change is needed to convert it successfully.

   Generally, packages, procedures, and functions are more likely to have some issues to resolve because they contain the most custom Transact-SQL code. AWS SCT also provides hints about how to fix these objects.

1. Choose the **Action Items** tab.

   The **Action Items** tab shows each issue for each object that requires attention.

   For each conversion issue, you can complete one of the following actions:
   + Modify the objects on the source SQL Server database so that AWS SCT can convert the objects to the target Aurora MySQL database.

     1. Modify the objects on the source SQL Server database.

     1. Repeat the previous steps to convert the schema and check the assessment report.

     1. If necessary, repeat this process until there are no conversion issues.

     1. Choose **Main View** from the menu. Open the context (right-click) menu for the target Aurora MySQL schema, and choose **Apply to database** to apply the schema changes to the Aurora MySQL database, and confirm that you want to apply the schema changes.
   + Instead of modifying the source schema, modify scripts that AWS SCT generates before applying the scripts on the target Aurora MySQL database.

     1. Choose **Main View** from the menu. Open the context (right-click) menu for the target Aurora MySQL schema name, and choose **Save as SQL**. Next, choose a name and destination for the script.

     1. In the script, modify the objects to correct conversion issues.

        You can also exclude foreign key constraints, triggers, and secondary indexes from the script because they can cause problems during the migration. After the migration is complete, you can create these objects on the Aurora MySQL database.

     1. Run the script on the target Aurora MySQL database.

   For more information, see [Converting Database Schema to Amazon RDS](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Converting.html).

1. (Optional) Use AWS SCT to create migration rules.

   1. Choose **Mapping view** and then choose **New migration rule**.

   1. Create additional migration transformation rules that are required based on the action items.

   1. Save the migration rules.

   1. Choose **Export script for DMS** to export a JSON format of all the transformations that the AWS DMS task will use. Choose **Save**.

# Step 5: Create an AWS DMS Replication Instance
<a name="chap-sqlserver2aurora.steps.createreplicationinstance"></a>

After validating the schema structure between source and target databases, continue with the core part of this walkthrough, which is the data migration. The following illustration shows a high-level view of the migration process.

![\[Migration process diagram showing source and target databases\]](http://docs.aws.amazon.com/dms/latest/sbs/images/datarep-conceptual2.png)


An AWS DMS replication instance performs the actual data migration between source and target. The replication instance also caches the transaction logs during the migration. The amount of CPU and memory capacity a replication instance has influences the overall time that is required for the migration.

For information about best practices for using AWS DMS, see [AWS Database Migration Service Best Practices](https://d0.awsstatic.com/whitepapers/RDS/AWS_Database_Migration_Service_Best_Practices.pdf).

To create an AWS DMS replication instance, do the following:

1. Sign in to the AWS Management Console, and open the [AWS DMS console](https://console.aws.amazon.com/dms/v2).

1. In the console, choose **Create migration**. If you are signed in as an AWS Identity and Access Management (IAM) user, you must have the appropriate permissions to access AWS DMS. For more information about the permissions required, see [IAM Permissions](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.html#CHAP_Security.IAMPermissions).

1. On the Welcome page, choose **Next** to start a database migration.

1. On the **Create replication instance** page, specify your replication instance information.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createreplicationinstance.html)

1. For the **Advanced** section, specify the following information.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createreplicationinstance.html)

   For information about the KMS key, see [Setting an Encryption Key and Specifying KMS Permissions](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Security.EncryptionKey.html).

1. Click **Next**.

# Step 6: Create AWS DMS Source and Target Endpoints
<a name="chap-sqlserver2aurora.steps.createsourcetargetendpoints"></a>

While your replication instance is being created, you can specify the source and target database endpoints using the [AWS Management Console](https://console.aws.amazon.com/). However, you can test connectivity only after the replication instance has been created, because the replication instance is used in the connection.

1. In the AWS DMS console, specify your connection information for the source SQL Server database and the target Aurora MySQL database. The following table describes the source settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createsourcetargetendpoints.html)

   The following table describes the advanced source settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createsourcetargetendpoints.html)

   The following table describes the target settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createsourcetargetendpoints.html)

   The following table describes the advanced target settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createsourcetargetendpoints.html)

   The following is an example of the completed page.  
![\[Completed Replication Task Page showing Replication instance created successfully\]](http://docs.aws.amazon.com/dms/latest/sbs/images/sbs-rdsqlserver2aurora-dmsconnect.png)

   For information about extra connection attributes, see [Using Extra Connection Attributes](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.ConnectionAttributes.html).

1. After the endpoints and replication instance are created, test the endpoint connections by choosing **Run test** for the source and target endpoints.

1. Drop foreign key constraints and triggers on the target database.

   During the full load process, AWS DMS does not load tables in any particular order, so it might load the child table data before parent table data. As a result, foreign key constraints might be violated if they are enabled. Also, if triggers are present on the target database, they might change data loaded by AWS DMS in unexpected ways.

   ```
   ALTER TABLE 'table_name' DROP FOREIGN KEY 'fk_name';
   
   DROP TRIGGER 'trigger_name';
   ```

1. If you dropped foreign key constraints and triggers on the target database, generate a script that enables the foreign key constraints and triggers.

   Later, when you want to add them to your migrated database, you can just run this script.

1. (Optional) Drop secondary indexes on the target database.

   Secondary indexes (as with all indexes) can slow down the full load of data into tables because they must be maintained and updated during the loading process. Dropping them can improve the performance of your full load process. If you drop the indexes, you must to add them back later, after the full load is complete.

   ```
   ALTER TABLE 'table_name' DROP INDEX  'index_name';
   ```

1. Choose **Next**.

# Step 7: Create and Run Your AWS DMS Migration Task
<a name="chap-sqlserver2aurora.steps.createmigrationtask"></a>

Using an AWS DMS task, you can specify what schema to migrate and the type of migration. You can migrate existing data, migrate existing data and replicate ongoing changes, or replicate data changes only.

1. In the AWS DMS console, on the **Create task** page, specify the task options. The following table describes the settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createmigrationtask.html)

   The page should look similar to the following:  
![\[Create task page\]](http://docs.aws.amazon.com/dms/latest/sbs/images/sbs-rdsqlserver2aurora-dmstask.png)

1. Under **Task settings**, specify the settings. The following table describes the settings.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/dms/latest/sbs/chap-sqlserver2aurora.steps.createmigrationtask.html)

1. Leave the Advanced settings at their default values.

1. If you created and exported mapping rules with AWS SCT in the last step in [Step 4: Convert the SQL Server Schema to Aurora MySQL](chap-sqlserver2aurora.steps.convertschema.md), choose **Table mappings**, and select the **JSON** tab. Then select **Enable JSON editing**, and enter the table mappings you saved.

   If you did not create mapping rules, then proceed to the next step.

1. Choose **Create task**. The task starts immediately.

The **Tasks** section shows you the status of the migration task.

![\[Tasks section showing the source, target, type, and completion status for a task\]](http://docs.aws.amazon.com/dms/latest/sbs/images/sbs-rdsqlserver2aurora-dmsmonitor.png)


If you chose **Enable logging** during setup, you can monitor your task. You can then view the Amazon CloudWatch metrics.

1. On the navigation pane, choose **Tasks**.

1. Choose your migration task.

1. Choose the **Task monitoring** tab, and monitor the task in progress on that tab.

   When the full load is complete and cached changes are applied, the task stops on its own.

1. On the target Aurora MySQL database, if you disabled foreign key constraints and triggers, enable them using the script that you saved previously.

1. On the target Aurora MySQL database, re-create the secondary indexes if you removed them previously.

1. If you chose to use AWS DMS to replicate changes, in the AWS DMS console, start the AWS DMS task by choosing **Start/Resume** for the task.

   Important replication instance metrics to monitor include the following:
   + CPU
   + FreeableMemory
   + DiskQueueDepth
   + CDCLatencySource
   + CDCLatencyTarget

   The AWS DMS task keeps the target Aurora MySQL database up to date with source database changes. AWS DMS keeps all the tables in the task up to date until it’s time to implement the application migration. The latency is zero, or close to zero, when the target has caught up to the source.

For more information, see [Monitoring DMS tasks](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html).

# Step 8: Cut Over to Aurora MySQL
<a name="chap-sqlserver2aurora.steps.cutover"></a>

To move connections from your Microsoft SQL Server database to your Amazon Aurora MySQL database, do the following:

1. End all SQL Server database dependencies and activities, such as running scripts and client connections. Ensure that the SQL Server Agent service is stopped.

   The following query should return no results other than your connection:

   ```
   SELECT session_id, login_name from sys.dm_exec_sessions where session_id > 50;
   ```

1. Kill any remaining sessions (other than your own).

   ```
   KILL session_id;
   ```

1. Shut down the SQL Server service.

1. Let the AWS DMS task apply the final changes from the SQL Server database on the Amazon Aurora MySQL database.

1. In the AWS DMS console, stop the AWS DMS task by choosing **Stop** for the task, and then confirming that you want to stop the task.

# SQL Server database migration to Amazon Aurora MySQL troubleshooting
<a name="chap-sqlserver2aurora.steps.troubleshooting"></a>

When you work with Microsoft SQL Server as a source database and Amazon Aurora MySQL as a target database, the two most common problem areas are SQL Server change data capture (CDC) and foreign keys.
+ MS-CDC: If you are using MS-CDC with SQL Server for the migration, errors that are related to permissions or errors during change data capture are common. These types of errors usually result when one of the prerequisites was not met. For example, the most common overlooked prerequisite is a full database backup.
+ Foreign keys: During the full load process, AWS DMS does not load tables in any particular order, so it might load the child table data before parent table data. As a result, foreign key constraints might be violated if they are enabled. You should disable foreign keys on the Aurora MySQL target database. You can enable the foreign keys on the target after the migration is complete.

For more tips, see the AWS DMS troubleshooting section in the [Troubleshooting migration tasks](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html).

To troubleshoot issues specific to SQL Server, see the SQL Server troubleshooting section:
+  [Troubleshooting Microsoft SQL Server Specific Issues](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.SQLServer) 

To troubleshoot Aurora MySQL issues, see the Aurora MySQL troubleshooting section and the MySQL troubleshooting section:
+  [Troubleshooting Amazon Aurora MySQL Specific Issues](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.Aurora) 
+  [Troubleshooting MySQL Specific Issues](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.MySQL)