Move MySQL Database to New Server

The Problem

You're migrating hosting or upgrading servers and need your database moved over completely and correctly — a rushed migration risks partial data, character set corruption, or application downtime longer than necessary.

About this problem

A database move is really an export-transfer-import sequence, and each step has its own way to go wrong — an incomplete export, a lost connection during transfer of a large file, or a character set mismatch on import — with the added pressure that the application is typically unusable until the move completes successfully.

This comes up during hosting migrations, server upgrades, or consolidating multiple databases onto new infrastructure.

What's Included

• A verified, complete export from the source server
• Secure transfer of the database file to the new server
• Correct import with matching character set and collation on the destination
• Verification that data is complete and the application connects and works correctly on the new server before cutover

What's NOT Included

• Migrating the application's files alongside the database (can be bundled as a fuller migration service)
• Choosing or provisioning the new server
• Extended downtime beyond what's genuinely needed for the transfer and verification

How It Works

1. Export the database from the source server with appropriate flags for consistency (especially important on a live, active database).
2. Transfer the export file securely to the new server.
3. Create the destination database with matching character set and collation before importing.
4. Import the data and verify table structure and row counts match the source.
5. Update the application's connection details to point at the new database, test thoroughly, then confirm old access can be safely decommissioned.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

How much downtime does moving a database require?

It depends on database size and how actively it's being written to during the move — for most small-to-medium databases, a brief maintenance window during the final export/import/cutover minimises the risk of lost writes.

Can I move a database without any downtime at all?

For very active databases this typically needs a more advanced approach (like replication) rather than a simple export/import — for most small business sites, a short planned window is the simpler and more reliable approach.

What happens to data written during the migration window?

Anything written to the old database after the final export won't be in the new one — that's exactly why the application is typically paused or put in maintenance mode briefly during the actual cutover.

Can I move between different MySQL versions?

Usually yes, especially moving to a newer version, though it's worth checking for any deprecated features the current database relies on that might behave differently on the new version.

How do I verify the migration was successful?

Comparing table structures and row counts between source and destination, then testing the actual application thoroughly against the new database, confirms a genuinely successful migration.

Is it risky to delete the old database right after migrating?

Yes — keeping the old server/database available (even just as a dormant backup) for a reasonable period after cutover is good practice in case anything unexpected surfaces.