MySQL to Amazon RDS Migration Guide
Published on · Updated on
Rewrote the guide with current RDS version support, supported import paths, consistent dump caveats, DMS limits, and a controlled cutover and rollback plan.
Moving a self-managed MySQL database to Amazon RDS for MySQL is a database migration, not a copy of server files. Choose a path that fits the source version, data size, change rate, and allowed write outage; then test the target and rehearse cutover before production traffic moves.
Migration scope
This guide covers self-managed MySQL to RDS for MySQL. Aurora MySQL has different engine and service behavior; check its documentation separately if it is your intended target.
Choose a migration path
The best method depends on how much time the source can stop accepting writes and whether the source and target combination is supported by the selected AWS service.
| Method | Use it when | Plan for |
|---|---|---|
Logical dump with mysqldump | The database is manageable as a SQL dump and a planned write outage is acceptable. | Export and import time; a dump is a snapshot, so later source writes need to stop or be replicated separately. |
| Percona XtraBackup through Amazon S3 | A larger database benefits from a supported backup-file restore and you can coordinate the snapshot, restore, and later source changes. | Strict source, backup-format, Region, and target-instance restrictions; use a write pause or compatible change catch-up. |
| AWS DMS full load plus CDC | A supported DMS mode fits the source and target versions, and the initial load should overlap with change capture. | Mode-specific version and object limits, binary-log setup and retention, validation work, and a final write pause for cutover. |
Test each candidate with representative data before estimating duration. A “low downtime” design still needs a controlled point when writes stop and the target becomes authoritative.
Prepare the source and RDS target
Check engine versions and application compatibility
Record the exact source engine and minor version, storage engines, character sets and collations, SQL modes, authentication plugins, case sensitivity, and application driver versions. Test the application against the proposed RDS engine version; matching the product name does not guarantee that old SQL, plugins, or authentication settings behave the same.
Amazon RDS’s current support page lists MySQL 8.4, 8.0, and 5.7, but lifecycle status differs. As of October 4, 2026, 8.0 and 5.7 are available only through paid RDS Extended Support; standard support ended for 8.0 on July 31, 2026 and for 5.7 on February 29, 2024. Do not treat MySQL 5.6 as a current RDS target. Check the current RDS for MySQL version and support table for the exact minor version, Region availability, and end dates before choosing a target.
List the databases, tables, views, routines, triggers, events, users, grants, scheduled jobs, and application dependencies that must move. Include data volume, ongoing write rate, acceptable outage, recovery objectives, and any features the source uses that RDS might not support. A broader application portfolio assessment can help expose owners and dependencies outside the database itself.
Decide how to keep the data consistent
A migration must account for writes made after its initial snapshot. With a dump-only or backup-only move, stop application writes before the final export or backup and keep them stopped until the target is validated and traffic switches. If the source must remain writable during the initial copy, use a supported change-capture method and verify that it has applied all changes before cutover.
Secure access and prepare a recoverable target
Keep the database private. Allow MySQL port 3306 only from the migration host, DMS resources, and application security groups that need it. Use TLS with certificate verification, separate migration and application accounts with only the required permissions, and keep dump files in encrypted storage with access limited to the migration team. Do not put passwords in command arguments, shell history, or logs. See AWS guidance on RDS security groups and TLS connections, plus this AWS migration security checklist.
Create the target with the intended engine version, parameter group, subnet group, storage, encryption, backup retention, and access rules. Take a source backup and prove that it can be read or restored before the change window. Use an RDS endpoint and a verified CA bundle for client connections; do not rely on a public endpoint as a shortcut.
Migration approaches
Logical migration with mysqldump
A logical dump is portable and easy to inspect, but its duration grows with the amount of data and target capacity. The following example uses a dedicated source export account, a pre-created appdb database on RDS, and password prompts instead of password values in the command. Replace the endpoint, user, and CA-file placeholders with your values. Use a MySQL client release compatible with the source and target.
umask 077
mysqldump --host=SOURCE_HOST --user=EXPORT_USER --password --ssl-mode=VERIFY_IDENTITY --ssl-ca=/path/to/source-ca.pem --single-transaction --quick --set-gtid-purged=OFF --hex-blob --routines --events --triggers --no-create-db --databases appdb > appdb.sql
mysql --host=RDS_ENDPOINT --port=3306 --user=IMPORT_USER --password --ssl-mode=VERIFY_IDENTITY --ssl-ca=/path/to/rds-global-bundle.pem < appdb.sql
Create the empty target database and grant the import account access to it before loading. The mysqldump account needs read access to the selected database and the additional rights required for the objects you export; the RDS import account needs only the rights required to create and load those objects. The --password option prompts for each password; it does not put the password in the command text.
This is a one-time logical import, not a GTID seed for replication. If you pair a dump with GTID-based replication, coordinate the GTID state and replication start point separately, then test that exact source and target combination.
--single-transaction gives a consistent snapshot for InnoDB tables without locking them for the duration of the dump. It does not make MyISAM or MEMORY tables consistent, and concurrent table changes such as ALTER TABLE, DROP TABLE, or RENAME TABLE can invalidate the dump. Freeze schema changes while dumping. Writes committed after the snapshot are not included, so stop writes for a dump-only cutover or replicate later changes. Review definers, grants, and RDS-supported object behavior before restoring routines, triggers, and events. The MySQL 8.4 mysqldump reference documents these snapshot limits.
Treat appdb.sql as production data: keep it in a restricted, encrypted location, do not upload it to general-purpose logs or shared storage, and remove it according to the retention policy after validation.
Restore a supported backup from Amazon S3
Amazon RDS does not give you access to its database host files, so copying a MySQL data directory to an RDS instance is not a supported migration. RDS has a specific restore-from-S3 workflow for MySQL backup files: it requires backups created with Percona XtraBackup and restores them to a new RDS DB instance. The S3 bucket and target must be in the same Region. AWS documents that this path doesn't accept an encrypted source database, MySQL 5.5 or 5.6, an RDS snapshot export, or a backup loaded into an existing instance. Check the remaining source-version and backup-format requirements before choosing it.
Percona XtraBackup can create a hot backup, but the backup represents a point in time. If the source keeps accepting writes while the backup is copied and restored, plan supported binary-log replication or DMS change capture; the backup alone does not include later transactions. Keep the original source available until the restored database and application have passed validation.
Use DMS Homogeneous Data Migrations for supported MySQL pairs
For MySQL-to-MySQL moves, AWS recommends evaluating AWS DMS Homogeneous Data Migrations when its source and target version matrix supports the pair. This managed workflow uses MySQL tools such as mydumper and myloader for full load, and can migrate data and secondary objects. As of this update, its RDS for MySQL source and target lists include versions 5.7 and 8.0, not 8.4; confirm the current DMS source matrix and target matrix before selecting a mode. This homogeneous path has no built-in data-validation tool, MySQL selection rules apply only to full load, and it migrates MySQL keyring-encrypted databases and tables as unencrypted objects on the target. Plan separate validation and verify the target's data-protection requirements.
Use full load plus CDC when the supported path fits
For a compatible DMS task that uses CDC, configure and retain the source binary logs as required by that mode; common MySQL prerequisites include row-based logging and a full row image. For an RDS MySQL source, AWS also calls out automated backups and sufficient binlog retention. Review the current DMS MySQL source prerequisites and limitations and run the available premigration assessment. The classic DMS task path has a different support matrix from Homogeneous Data Migrations; AWS currently lists MySQL 8.4 for classic data migration with DMS 3.5.4 and later, but verify the exact source, target, and CDC combination before planning around it.
Do not treat every DMS mode as a complete schema copier. Homogeneous Data Migrations can move secondary objects, subject to its version and feature limits. Classic DMS table migration creates tables and primary keys but does not create secondary indexes, non-primary constraints, data defaults, or objects such as routines, triggers, views, events, users, and grants; migrate and validate those separately. CDC captures supported row changes, not arbitrary DDL. The MySQL source documentation excludes some table renames and drops, and InnoDB cascade operations might not produce child-row changes for DMS to copy. Review the limits for the chosen mode, build or convert objects it doesn't handle, and rehearse DDL coordination.
Validate the target before switching traffic
Compare database and application behavior
Do not use a green task status as the only acceptance check. Confirm every expected schema and object exists, review task errors and latency, compare table counts and selected checksums or business totals, and test important reads and writes through the application. Check character encoding, timestamps, auto-increment values, constraints, indexes, routines, triggers, and events where they are part of the workload. Reconcile any difference before routing production traffic.
Establish an RDS performance baseline
Watch application latency and errors together with database load, CPU, memory, connections, storage latency, and replication lag where applicable. Test representative reads and writes, backup and restore, monitoring alarms, and failover behavior against the service level the application needs. Change RDS parameters only after measuring a workload-specific bottleneck; the Amazon RDS performance tuning guide covers that workflow.
Cut over with a rollback boundary
Stop writes, catch up, then switch
- Announce the maintenance window and stop or drain application writes to the source.
- For DMS or binary-log replication, wait until all captured changes have applied and task errors are resolved. For a dump-only migration, finish the final dump and import while writes remain stopped.
- Run the agreed data checks, update the application to use the RDS endpoint while production writes remain disabled, and confirm connectivity, representative reads, and health checks.
- When those checks pass, make RDS authoritative, enable production writes there, and verify the write path. Keep the source isolated from writes while the observation and rollback window remains open.
Do not let both databases accept application writes. Before RDS accepts new writes, rollback can usually mean routing the application back to the unchanged source. After writes reach RDS, the old source is stale; returning to it requires a tested reverse-replication or data-reconciliation plan. Decide that boundary before cutover instead of assuming a DNS or endpoint change can undo database writes.
Check access and symptoms by layer
If the application cannot connect, verify that it uses the RDS endpoint and port, the network path and security-group source are correct, TLS verification trusts the current RDS CA, and the database user has access to the intended schema. If performance changes, compare the same workload against the source baseline and inspect query plans, connection use, and RDS metrics before changing instance size or parameters.
Migration checklist
Go/no-go checks
- The exact RDS engine version and migration mode are supported in the chosen Region.
- A rehearsal covers the full data volume, change rate, security path, validation checks, and target capacity.
- The application owner and database operator agree on the write-stop point and what happens if rollback is needed after target writes begin.
Next steps
Run a migration rehearsal with production-shaped data, record the measured export/load and catch-up time, and fix compatibility or validation gaps before scheduling cutover. Preserve the source and a recoverable backup until the rollback window closes; then remove temporary migration access and sensitive files.
DMS support details
AWS documentation
FAQs
Should I migrate the MySQL system schemas?
No. Select only user-created databases for migration. RDS manages its system schemas and AWS warns that DMS selection rules which include them can fail; recreate application users and grants separately with supported privileges.
Can I restore an XtraBackup import into an existing RDS instance?
No. The documented S3 restore creates a new RDS for MySQL DB instance. Plan the endpoint change and validation around that target.