Cut over - AWS Prescriptive Guidance

Cut over

The database cutover strategy is usually tightly coupled with the downtime requirements for the application. Strategies that you can use for the database cutover include offline migration, flash-cut migration, active/active database configuration, and incremental migration. These are discussed in the following sections.

Offline migration

If you can take your application offline for an extended period during write operations, you can use AWS DMS full-load task settings or one of the offline migration options for your data migration. The read traffic can continue while this migration is in progress, but the write traffic must be stopped. Because all the data needs to be copied from the source database, source database resources such as I/O and CPU are utilized.

At a high level, offline migration involves these steps:

  1. Complete the schema conversion.

  2. Start downtime for write traffic.

  3. Migrate the data using one of the offline migration options.

  4. Verify your data.

  5. Point your application to the new database.

  6. End the application downtime.

Flash-cut migration

In flash-cut migration, the main objective is to keep the downtime to a minimum. This strategy relies on continuous data replication (CDC) from the source database to the target database. All read/write traffic will continue on the current database while the data is being migrated. Because all the data needs to be copied from the source database, source server resources such as I/O and CPU are utilized. You should test to make sure that this data migration activity doesn’t impact your application performance SLAs.

At a high level, flash-cut migration involves these steps:

  1. Complete the schema conversion.

  2. Set up AWS DMS in continuous data replication mode.

  3. When the source and target databases are in sync, verify the data.

  4. Start the application downtime.

  5. Roll out the new version of the application, which points to the new database.

  6. End the application downtime.

Active/active database configuration

Active/active database configuration involves setting up a mechanism to keep the source and target databases in sync while both databases are being used for write traffic. This strategy involves more work than offline or flash-cut migration, but it also provides more flexibility during migration. For example, in addition to experiencing minimal downtime during migration, you can move your production traffic to the new database in small, controlled batches instead of performing a one-time cutover. You can either perform dual write operations so that changes are made to both databases, or use a bi-directional replication tool like HVR to keep the databases in sync. This strategy has a higher complexity in terms of setup and maintenance, so more testing is required to avoid data consistency issues.

At a high level, active/active database configuration involves these steps:

  1. Complete the schema conversion.

  2. Copy the existing data from the source database to the target database, and then keep the two databases in sync by using a bi-directional replication tool or dual writes from the application.

  3. When the source and target databases are in sync, verify the data.

  4. Start moving a subset of your traffic to the new database.

  5. Keep moving the traffic until all your database traffic has been moved to the new database.

Incremental migration

In incremental migration, you migrate your application in smaller parts instead of performing a one-time, full cutover. This cutover strategy could have many variations, based on your current application architecture or the refactoring you’re willing to do in the application.

You can use a design pattern to add new independent microservices to replace parts of an existing, monolithic legacy application. These independent microservices have their own tables that are not shared or accessed by any other part of the application. You migrate these microservices to the new database one by one, using any of the other cutover strategies. The migrated microservices start using the new database for read/write traffic while all other parts of the application continue to use the old database. When all microservices have been migrated, you decommission your legacy application. This strategy breaks up the migration into smaller, manageable pieces and can, therefore, reduce the risks that are associated with one big migration.