Heterogeneous migrations

If you are migrating a non-MySQL-compatible database to Amazon Aurora, several options can help you complete the project quickly and easily.

A heterogeneous migration project can be split into two phases:

1. Schema migration to review and convert the source schema objects (for example, tables, procedures, and triggers) into a MySQL-compatible representation.

2. Data migration to populate the newly created schema with data contained in the source database. Optionally, you can use a CDC replication for near-zero downtime migration.

Schema migration

You must convert database objects such as tables, views, functions, and stored procedures to a MySQL 5.6-compatible format before you can use them with Amazon Aurora.

This section describes two main options for converting schema objects. Whichever migration method you choose, always make sure that the converted objects are not only compatible with Aurora but also follow MySQL’s best practices for schema design.

AWS Schema Conversion Tool

The AWS Schema Conversion Tool (AWS SCT) can greatly reduce the engineering effort associated with migrations from Oracle, Microsoft SQL Server, Sybase, DB2, Azure SQL Database, Terradata, Greenplum, Vertica, Cassandra and PostgreSQL etc. AWS SCT can automatically convert the source database schema and a majority of the custom code, including views, stored procedures, and functions, to a format compatible with Amazon Aurora. Any code that can’t be automatically converted is clearly marked so that it can be processed manually.

For more information, refer to the AWS Schema Conversion Tool User Guide. For step-by-step instructions on how to convert a non-MySQL-compatible schema using the AWS Schema Conversion Tool, refer to the AWS whitepaper Migrating Your Databases to Amazon Aurora.

Manual schema migration

If your source database is not in the scope of SCT compatible databases, you can either manually rewrite your database object definitions or use available third-party tools to migrate schema to a format compatible with Amazon Aurora.

Many applications use data access layers that abstract schema design from business application code. In such cases, you can consider redesigning your schema objects specifically for Amazon Aurora and adapting the data access layer to the new schema. This might require a greater upfront engineering effort, but it allows the new schema to incorporate all the best practices for performance and scalability.

Data migration

After the database objects are successfully converted and migrated to Amazon Aurora, it’s time to migrate the data itself.

The task of moving data from a non-MySQL-compatible database to Amazon Aurora is best done using AWS DMS. AWS DMS supports initial data migration as well as CDC replication. After the migration task starts, AWS DMS manages all the complexities of the process, including data type transformations, compression, and parallel data transfer. The CDC functionality automatically replicates any changes that are made to the source database during the migration process.

For more information, refer to the AWS Database Migration Service User Guide.

For step-by-step instructions on how to migrate data from a non-MySQL- compatible database into an Amazon Aurora cluster using AWS DMS, refer to the AWS whitepaper Migrating Your Databases to Amazon Aurora.