Yes, your overall high land plan is correct, but to provide more context around cutover, you'll have to plan a schedule for this essentially.
When the actual data migration is complete and the change data capture is going on or the target is already in sync, during this cutover phase, the application will have to be stopped so no new writes can go to source database anymore. Next, you'll track the DMS task to ensure the data is in sync and once all changes have been pushed to target, you will then switch your application to target to Aurora. This will ensure there is no data inconsistency.
"Replicate on-going changes" means that any new changes to source RDS will keep replicating to target Aurora cluster.
I don't see the mention of the database engine, but if you are using MySQL or Postgres RDS, an easier strategy is to create an Aurora read replica which is relatively simple and can migrate all objects fully. The cutover plan would be the same for that though. You can stop application writes to RDS, once Aurora read replica is in sync, promote it to primary cluster and redirect application to this new Aurora cluster.
- Accepted Answerasked 3 years ago
- What are the best practices for migrating an Oracle database to a target RDS for PostgreSQL database using AWS DMS?AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- EXPERTpublished 4 months ago