Migration Insurance: Backup Before Starting

Every WordPress migration guide tells you to back up first, and most people skim past it because nothing has gone wrong yet. Then a search-replace command gets run against the wrong database, a file transfer gets interrupted halfway through overwriting the destination, or a host’s “free migration” tool silently drops a table — and there’s no way back. A backup taken before you start isn’t a formality; it’s the only thing standing between a bad step and a total loss.

Why This Step Gets Skipped

Migrations feel low-risk because the source site usually keeps running untouched while you work on the copy. That’s true right up until the moment you point DNS at the new server, run a destructive command against the wrong target, or a plugin’s migration tool modifies the source site’s database as part of its process (several “push” style migration plugins do exactly this). The backup isn’t insurance against the destination — it’s insurance against your own tooling and your own mistakes during a process with more moving parts than routine maintenance.

What a Real Migration Backup Covers

A full backup for migration purposes needs four components, not just the database:

• Database export — every table, not just the WordPress core ones, since plugins frequently add their own tables that a partial export skips.
• wp-content directory — themes, plugins, and uploads. This is usually the largest piece and the one most likely to be forgotten if you’re focused on the database.
• wp-config.php — not to transfer as-is (it has old database credentials), but to reference for any custom constants, salts, or site-specific configuration you’d otherwise have to reconstruct from memory.
• .htaccess or server config — rewrite rules and any custom directives (security headers, redirects) that aren’t stored in the database and are easy to forget entirely.

Backup Method Comparison

Method	Speed	Restore reliability	Best for
Host’s one-click snapshot	Fast	Good, if host retains snapshots long enough	Quick pre-migration safety net on managed hosts
WP-CLI manual export (wp db export + tar wp-content)	Fast, no plugin overhead	Very reliable, fully in your control	Developers, larger sites, repeatable process
UpdraftPlus / similar plugin	Moderate	Good, widely tested restore path	Non-technical users wanting a GUI restore
BlogVault / managed backup service	Fast (offsite, automated)	Very reliable, includes staging restore test	Sites that can’t tolerate any migration risk

The Step Almost Everyone Skips: Test the Restore

A backup file you’ve never restored is a hope, not a backup. Before starting a migration, restore your export to a staging environment or local dev copy and confirm the site actually loads — logged-in admin access, key pages rendering, and any custom post types intact. This catches the two most common silent failures: an export that completed but is missing tables (some tools skip tables with non-standard prefixes), and a database dump that’s technically valid SQL but was taken mid-write during a cron job, leaving it in an inconsistent state. Both look fine in a file browser and both are unusable until you try to actually load the site from them.

A Simple 3-2-1 Approach for Migrations

Borrowing from general backup practice: keep 3 copies of your migration backup (the live site being one), on 2 different types of storage (not two folders on the same server — an external drive or cloud storage counts, the same disk twice doesn’t), with 1 copy stored somewhere other than the server you’re migrating from or to. If the migration goes wrong and both servers are compromised, misconfigured, or simply unreachable, that third off-server copy is what lets you rebuild from scratch instead of starting over with nothing.

FAQ

How long should I keep the pre-migration backup after a successful move?
At minimum until you’ve verified the new site fully — forms submitting, e-commerce checkout working, search functioning — under real traffic for a few days. Don’t delete it the same day you cut over.

Is a host’s automatic daily backup enough on its own?
Not by itself. Those are for disaster recovery, often overwritten on a rolling schedule, and may not capture the exact pre-migration state if the migration itself takes more than a day. Take a dedicated, separately-stored export right before you start.

Do I need to back up the destination server too?
Yes if it’s not a fresh empty server — anything already on the destination should be backed up before you overwrite it with the migrated site.

What’s the single most common cause of a migration going unrecoverable?
Running a destructive command (a database import, a bulk search-replace) against the wrong target because the source and destination look similar in a terminal with multiple SSH sessions open — always confirm the hostname before running anything destructive.

Verdict

A pre-migration backup costs a few minutes and disk space you already have. Skipping it costs nothing until the one time it doesn’t — and by then there’s no way to buy the option back. Treat the backup-and-test-restore step as part of the migration itself, not an optional precaution before it, and store at least one copy somewhere neither the old nor new server can take down with it.