Migrations

Plan a database-only migration to a new database on the same host

A scenario for moving just the WordPress database to a new dedicated MySQL instance on the same host, without touching files or domain, covering lock-safe dumps and collation mismatches.

Works with Claude / GPT172 uses 4

The prompt

migrations-database-only-migration-same-host
My WordPress site at [clientsite.com] is outgrowing the shared MySQL instance on my
host and I've been given a new dedicated database instance on the same server. The
domain, files, and hosting stay exactly the same, only the database target changes.
The site takes live traffic and occasional form submissions all day, so I can't just
take it offline for an hour to do this.

Walk me through this as a database-only migration, not a full site migration, and
cover what's specific to moving just the data layer:

1. Consistent dump under load: since the site is live, explain why a plain mysqldump
   can produce an inconsistent snapshot if tables are being written to mid-export
   (specifically explain --single-transaction for InnoDB tables and why it doesn't
   help if any plugin still uses MyISAM tables like some older stats/cache plugins).
2. Character set and collation traps: how to confirm the new database instance uses
   the exact same charset/collation as the source (utf8mb4_unicode_ci mismatches are a
   common silent corruption source for emoji or non-Latin text in post content and
   usernames), and what happens if they don't match.
3. Cutover without file changes: since only wp-config.php's DB_HOST/DB_NAME/DB_USER
   need to change, describe the exact cutover window, how to briefly pause writes
   (or accept a short window where writes during cutover are lost) and confirm no
   stale database connections from persistent connection pooling are still writing to
   the old database after the switch.
4. Drift detection: how to check for any rows written to the old database in the gap
   between the dump and the cutover (new orders, new comments, new form entries) so
   nothing submitted during the migration window silently vanishes.
5. Rollback: the specific condition under which I'd revert wp-config.php back to the
   old database, and what to do about any writes that happened on the new database
   before I noticed something was wrong.

Give me the actual sequence of commands and checks in order, flagging every point where
a live write during the migration could be lost.

A same-host, files-unchanged database migration looks simple because so little is moving, but that’s exactly why the live-write gap between dump and cutover gets missed. This prompt keeps the focus on that gap instead of the mechanics of the dump itself, which most people already know how to run.