MariaDB 10.6 to MySQL Aurora 8.0 Migration Guide — Part 5: Execution, Validation, Cutover, and Cleanup

With the schema imported, endpoints tested, and the migration task configured, the final phase covers starting the migration, monitoring its progress, validating data consistency, performing the cutover, and removing all temporary AWS resources created for the migration.

Final Checks Before Starting

Before starting the migration task, verify these items are in place:

Start the Migration Task

Select the migration task in the DMS console and click Actions → Restart/Resume. The task enters the Full load phase immediately.

Monitor progress from the Table statistics tab of the task details. Key columns:

• Full load rows — rows loaded so far for each table
• Inserts / Updates / Deletes — CDC changes applied (will be 0 until full load completes)
• Validation state — will show Not enabled until you enable validation

Monitoring the Migration

CloudWatch Logs

Navigate to CloudWatch Logs → Log groups → find the log group for your DMS task (named /aws/dms/tasks/<task-id>). Monitor for:

• [ERROR] entries — indicate failed row operations or connectivity issues
• LOB warnings — if DMS cannot retrieve a LOB value, it logs the table, row, and column
• Latency metrics — available in the DMS CloudWatch metrics tab of the task

Replication Lag During CDC

Once the full load completes, DMS switches automatically to CDC mode and begins applying binlog events from the source. Monitor the CDCLatencySource and CDCLatencyTarget CloudWatch metrics on the replication instance. These values should trend toward zero as CDC catches up with the current position on the source.

A sustained increase in latency indicates the replication instance is under-sized for the write throughput of the source, or the target is a bottleneck (check Aurora CloudWatch metrics for CPU and write IOPS).

Enable Data Validation

Once the Full load percentage reaches 100% in the task overview, enable data validation. Do not enable it during the full load — validation runs queries against both source and target simultaneously, which adds load and slows the migration.

To enable validation:

1. Stop the task temporarily (Actions → Stop)
2. Edit the task settings → enable Data validation
3. Restart the task

DMS data validation compares row counts and checksums between source and target tables. View results in the Table statistics tab under the Validation state column:

• Validated — row counts and checksums match
• Validation errors — discrepancies found, requires investigation
• Validation suspended — DMS skipped validation for a table (usually due to unsupported data types or missing primary keys)

Any Validation errors findings must be investigated before proceeding with cutover. The AWS DMS data validation documentation covers resolution steps for common discrepancy types.

Enable Batch Apply

Once data validation shows all tables as Validated, enable Batch Apply mode on the CDC replication. Batch Apply groups multiple row-level events per table and applies them as bulk INSERT, UPDATE, or DELETE sets per transaction rather than one row at a time. This reduces commit frequency by up to 90% and significantly lowers write latency on the Aurora target.

To enable Batch Apply:

1. Edit the migration task
2. Under Advanced task settings, find CDC batch apply mode and enable it

Cutover Procedure

Cutover is the moment you stop writing to MariaDB and redirect application traffic to Aurora MySQL. The goal is to minimize the window between stopping writes on the source and resuming writes on the target.

Step-by-Step Cutover

1. Choose a low-traffic window. Identify a period where application write rates are at their daily minimum. This reduces the time needed for CDC lag to reach zero.

2. Stop the application from writing to MariaDB. This is application-specific — options include:

   • Putting the application into maintenance mode
   • Redirecting traffic to a holding page
   • Disabling background jobs and cron tasks that write to the database

3. Wait for CDC lag to reach zero. Watch the CDCLatencySource metric in CloudWatch. It should drop to 0 seconds, indicating DMS has consumed all pending binlog events. Allow at least 2–3 minutes at zero lag before proceeding to confirm stability.

4. Run final validation queries. On both MariaDB and Aurora, compare row counts for critical tables:

   -- Run on both databases and compare
   SELECT table_name, table_rows
   FROM information_schema.TABLES
   WHERE table_schema = '<schema_name>'
   ORDER BY table_name;
   

   Note that table_rows in information_schema is an estimate. For exact counts on critical tables, run SELECT COUNT(*) directly.

5. Create secondary indexes on Aurora. Now that the full load is complete and CDC has caught up, rebuild the secondary indexes that were dropped before the migration:

   mysql -h <aurora-endpoint> -u admin -p -P 3306 <schema_name> < create_indexes.sql
   

   Monitor index creation progress in Aurora — on large tables this can take significant time. You can monitor progress in a separate session:

   SHOW PROCESSLIST;
   

6. Redirect the application to Aurora MySQL. Update the application's database connection string to point to the Aurora cluster endpoint. Aurora's cluster endpoint automatically routes to the current writer instance and handles failovers transparently.

7. Verify the application. Run smoke tests on the critical application paths. Check application logs for database errors.

8. Disable or stop the DMS migration task. Once the application is verified on Aurora, the DMS task is no longer needed.

Post-Migration Validation

After the cutover, run a thorough validation of the Aurora target:

• Compare table counts between MariaDB and Aurora for all tables in the migrated schema
• Test all stored procedures and functions that are critical to application functionality
• Verify scheduled events and triggers fire as expected
• Check application error rates in your APM tool for the first 30–60 minutes after cutover

If critical issues are discovered post-cutover, the rollback path is to redirect the application connection string back to the original MariaDB instance. The MariaDB source remains untouched throughout this process — DMS reads from it but never writes to it.

Cleanup

After successful cutover and a validation period (typically 24–48 hours), clean up all resources created for the migration.

Remove DMS Resources

Remove DMS resources in this order (dependencies must be removed first):

1. Stop and delete migration tasks — select each task, Actions → Stop, then Actions → Delete
2. Delete both endpoints — source (MariaDB) and target (Aurora) endpoints
3. Delete the replication instance — go to Replication instances and delete

Delete DMS Certificate

Go to DMS → Certificates and delete the imported CA certificate.

Revoke DMS User Privileges

Remove the dms_user accounts from both databases once the migration task is deleted:

-- On MariaDB source
DROP USER 'dms_user'@'<replication_instance_ip>';
FLUSH PRIVILEGES;

-- On Aurora MySQL target
DROP USER 'dms_user'@'<replication_instance_ip>';
FLUSH PRIVILEGES;

Remove Temporary Security Group Rules

Remove any inbound rules added to the MariaDB and Aurora security groups specifically for the DMS replication instance. If you reused an existing security group for the replication instance, ensure the rules for port 3306 still make sense for the remaining resources that use that security group.

Delete IAM Roles and Policies

Delete the IAM resources created for DMS:

• Role: dms-vpc-role
• Role: dms-cloudwatch-logs-role
• Role: DMSS3AccessRole-* (the S3 access role created during premigration assessments)
• Policy: DMSS3BucketPolicy-DMSS3AccessRole-*

Delete the S3 Bucket

If the S3 bucket created for migration logs is no longer needed, delete it:

1. Empty the bucket first (required by S3 before deletion)
2. Delete the bucket from the S3 console

Complete Migration Checklist