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.
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.