Testing and cutover - Amazon Aurora MySQL Migration Handbook

Testing and cutover

Once the schema and data have been successfully migrated from the source database to Amazon Aurora, you are now ready to perform end-to-end testing of your migration process. The testing approach should be refined after each test migration, and the final migration plan should include a test plan that ensures adequate testing of the migrated database.  

Migration testing

Test category Purpose
Basic acceptance tests

These pre-cutover tests should be automatically run upon completion of the data migration process. Their primary purpose is to verify whether the data migration was successful. Following are some common outputs from these tests:

  • Total number of items processed

  • Total number of items imported

  • Total number of items skipped

  • Total number of warnings

  • Total number of errors

If any of these totals reported by the tests deviate from the expected values, then it means the migration was not successful, and the issues need to be resolved before moving to the next step in the process or the next round of testing.

Functional tests These post-cutover tests exercise the functionality of the applications using Aurora for data storage. They include a combination of automated and manual tests. The primary purpose of the functional tests is to identify problems in the application caused by the migration of the data to Aurora.
Nonfunctional tests These post-cutover tests assess the nonfunctional characteristics of the application, such as performance under varying levels of load.
User acceptance tests These post-cutover tests should be run by the end users of the application once the final data migration and cutover is complete. The purpose of these tests is for the end users to decide if the application is sufficiently usable to meet its primary function in the organization.


Once you have completed the final migration and testing, it is time to point your application to the Amazon Aurora database. This phase of migration is known as cutover. If the planning and testing phase has been conducted properly, cutover should not lead to unexpected issues.

Pre-cutover actions

  • Choose a cutover window — Identify a block of time when you can accomplish cutover to the new database with minimum disruption to the business. Normally you would select a low activity period for the database (typically nights and/or weekends).

  • Ensure changes are caught up — If a near-zero downtime migration approach was used to replicate database changes from the source to the target database, make sure that all database changes are caught up and your target database is not significantly lagging behind the source database.

  • Prepare scripts to make the application configuration changes — In order to accomplish the cutover, you need to modify database connection details in your application configuration files. Large and complex applications may require updates to connection details in multiple places. Make sure you have the necessary scripts ready to update the connection configuration quickly and reliably.

  • Stop the application — Stop the application processes on the source database and put the source database in read-only mode so that no further writes can be made to the source database. If the source database changes aren’t fully caught up with the target database, wait for some time while these changes are fully propagated to the target database.

  • Run pre-cutover tests — Run automated pre-cutover tests to make sure that the data migration was successful.


  • Run cutover — If pre-cutover checks were completed successfully, you can now point your application to Amazon Aurora. Use scripts created in the pre-cutover phase to change the application configuration to point to the new Aurora database.

  • Start your application — At this point, you may start your application. If you have an ability to stop users from accessing the application while the application is running, exercise that option until you have run your post-cutover checks.

Post-cutover checks

  • Run post-cutover tests: Run predefined automated or manual test cases to make sure your application works as expected with the new database. It’s a good strategy to start testing read-only functionality of the database first before executing tests that write to the database.

Enable user access and closely monitor: If your test cases were success, you may give user access to the application to complete the migration process. Both application and database should be closely monitored at this time.