Who this is for
Checklist: migrate MySQL to a managed cloud database is for founders, CTOs, IT leads, finance and operations people who run MySQL on their own servers or virtual machines and are moving it to a managed service. You may run a small product team, an internal business system, or a set of customer facing applications that share one database. The checklist assumes you can read a schema, change a connection string and schedule a maintenance window.
It fits MySQL 5.7, 8.0 and 8.4 estates, including single server installs, primary replica pairs and simple group replication setups. It also fits teams that use WordPress, WooCommerce, Laravel, Django, Rails, Java or PHP applications on top of MySQL. If you have a large sharded estate or a custom storage engine, use this as a starting point and add a deeper review. The goal is a repeatable migration with proof at each step, not a one night gamble.
Before you begin
Start with an inventory you can trust. Record the exact MySQL version and build, the operating system, data size, table count and write rate. List every schema, table, view, trigger, stored procedure, function and scheduled event. Note the storage engine for each table, because MyISAM, MEMORY and archive tables need a conversion or an exception. Check character sets and collations, sql_mode, time zone, lower_case_table_names and max_allowed_packet. These settings change query behavior and can cause silent data differences.
Map the accounts and privileges. Separate application users, read only users, admin users, backup users and replication users. Find objects with DEFINER clauses that point to accounts or hosts that will not exist in the managed service. Managed MySQL services often block SUPER, FILE, PROCESS, SHUTDOWN and direct binlog access, so rewrite grants and test the application with the reduced privilege set. Decide whether you need events, triggers and procedures at all, and which ones can be replaced by scheduled jobs outside the database.
Agree on the target version, downtime window and rollback rule before anyone changes a setting. Pick a target version that matches your application and driver support. Define success: checksums match, smoke tests pass, error rates stay normal, backups restore and the old server remains available for a set rollback period. Name one migration owner and one application owner. Put the cutover in a change record so support and finance know what is happening.
The checklist
Work through the list in order and keep evidence for each step. Do not skip the restore test or the privilege review. Those two items cause most late surprises.
Treat the managed instance as a new production system. Build it with the same backup, monitoring, alerting and access rules you use elsewhere. Test with production sized data, not a sample.
- Record MySQL version, edition, storage engine per table, row counts and data size, and confirm every table uses InnoDB or has a plan for MyISAM conversion.
- Capture server settings that affect behavior, including sql_mode, character_set_server, collation_server, time_zone, lower_case_table_names, max_allowed_packet and innodb_buffer_pool_size.
- List all objects outside tables: views, triggers, stored procedures, functions, events, and check DEFINER clauses for accounts that will not exist in the managed service.
- Export users and grants, separate application accounts from admin and replication accounts, and remove or rewrite privileges that the managed service blocks, such as SUPER, FILE and PROCESS.
- Choose a migration method, logical dump for small databases or physical backup and restore for large ones, and test restore time with production sized data.
- Create the target instance with matching version, parameter group, maintenance window, backup retention, point in time recovery and read replica plan.
- Load a full copy into a staging target and run CHECKSUM TABLE or pt-table-checksum to prove row and object parity.
- Replay representative read and write traffic, run application test suites, and compare query plans for the top slow queries.
- Set up continuous replication from source to target using binlog position or GTIDs, confirm Seconds_Behind_Master and replication filters, and monitor lag.
- Put application connection strings, TLS settings, DNS TTL and pool sizes under change control, and lower DNS TTL at least a day before cutover.
- Rehearse cutover end to end: stop writes, wait for replication to drain, compare checksums, switch traffic, run smoke tests and keep the old server ready for rollback.
- After cutover, watch error rates, slow query log, connections, storage growth, backup completion and replication lag, then decommission the source only after the rollback window.
What good looks like
A good migration has no mystery data. Row counts and checksums match for every table, object counts match, and the application test suite passes against the managed target. The cutover has a named start time, a named decision maker and a rollback test that has already run once. The old server is not switched off until the rollback window closes.
The target runs on InnoDB, uses the same sql_mode and time zone, and has parameter changes recorded in version control or a change log. Backups complete, point in time recovery has been tested, and alerts cover replication lag, connections, storage, slow queries and failed logins. The application uses TLS, a least privilege account and a connection pool sized for the new instance.
Performance is understood, not guessed. The top queries have been compared before and after, the slow query log is on, and the team knows which queries need indexes or rewrites. There is a capacity plan for storage growth and read replicas. The runbook explains what to check at 10 minutes, 1 hour and 1 day after cutover.
What to do next
Assign an owner and book a two hour working session to complete the inventory and privilege review. That session will tell you whether this is a straight restore or a project with application changes. Then choose the migration method and run one restore into a staging target.
If your team needs help with architecture, cutover design or a phased plan, one option is the Cloudverg Discovery and roadmap sprint at $9,500 fixed price. It runs two weeks, starts within 10 business days, and ends with target architecture, a phased roadmap, risks and dependencies, and a fixed price quote for phase one. The fee is credited to phase one if you start with us within 60 days, and you keep all documents.
Whichever route you take, do not cut over until the rollback has been tested. Keep the source read only for a short period, compare checksums one last time and watch the first business cycle on the managed service.
Frequently asked questions
What is the hardest part of moving MySQL to a managed cloud database?
The hardest part is usually the details around privileges, DEFINER clauses and settings such as sql_mode and lower_case_table_names. These decide whether the schema loads cleanly and whether the application behaves the same. Test these on a staging target with production data before you plan the cutover.
Can I migrate MySQL to a managed service with almost no downtime?
Yes, if you can run the source and target side by side and replicate changes with the binary log. Load a full copy, start replication, let it catch up, then stop writes for the final drain and switch the application. The switch still needs a short write freeze, so plan a low traffic window and a rollback path.
Should I use mysqldump or a physical backup for a MySQL migration?
Use a logical dump for small databases or when you need to change schema details during the move. Use a physical backup or a managed import service for large databases where dump and restore time is too long. In both cases, test the restore time and verify checksums on the target before cutover.