The single most important thing you do before any migration is make a complete, verified backup — because it is the safety net that turns every subsequent step from a gamble into a reversible action. If a migration goes wrong and you have a good backup, the worst case is a do-over; if it goes wrong and you do not, the worst case is losing everything you built. This is why ‘back up first’ is the universal rule that opens every migration guide, and it is worth doing properly.

This guide covers backing up before a migration thoroughly: why the backup is your safety net, what a complete backup must include, the ways to create one, the crucial step of verifying it is restorable, where to store it safely, and how it fits into the migration. By the end you will know how to create a backup you can genuinely rely on, so your migration is protected from the worst outcome before it even begins.

Why the backup is your safety net

A migration involves copying, moving, reconnecting, and switching — a series of steps, any of which could go wrong: a corrupted transfer, a mistaken deletion, a botched database import, an incompatible new environment. A complete backup taken before you start means that whatever happens, you can always restore your site to exactly the state it was in before the migration, and either try again or stay put.

This transforms the risk profile of the entire migration. Without a backup, a serious mistake could mean permanent loss of your content, and that fear (rightly) makes people nervous about migrating at all. With a verified backup, the very worst realistic outcome shrinks to a wasted afternoon and a second attempt, because your original site is safely preserved and restorable. The backup is what makes migration safe to attempt.

So the backup is not a formality but the foundation of a low-risk migration — the thing that lets you proceed confidently through every subsequent step, knowing none of them is truly irreversible. This is why every migration begins here, and why cutting this corner is the single most dangerous thing you can do. Never start a migration without a complete, verified backup in hand; it is the difference between a controlled procedure and a genuine gamble.

What a complete backup must include

A backup is only useful if it is complete, which means it must capture both components of your site — everything needed to fully reconstruct it. Missing either half leaves you with a backup that cannot actually restore a working site.

• All the files: the entire web directory — code, themes or templates, plugins, and crucially the media/uploads folder, which holds your images and is often the largest and most irreplaceable part.
• The full database: for a dynamic site, a complete export of the database, containing all content, settings, users, and configuration.
• Configuration files: the config file (like wp-config.php) and any special server settings or redirect rules the site relies on.
• Nothing skipped: the backup must be the whole site, not a partial or selective copy, or a restore will be incomplete.

The key is that a website is files plus database, so a complete backup must include both — a files-only or database-only backup cannot restore a working dynamic site. The media/uploads folder deserves special attention, as it is both the largest part (easy to skip to save time) and often the most irreplaceable (your original images). A backup that captures everything is one you can genuinely rebuild the whole site from; a partial one is a false sense of security.

Ways to create a backup

There are several ways to create a complete backup, and any of them works as long as the result captures both components. The manual method is to download all the files (via FTP or a compressed archive from the file manager) and export the database (via phpMyAdmin) — the same actions that begin a manual migration, which is why a manual migration produces its own backup as a by-product.

A backup plugin (for WordPress) automates this, packaging both files and database into a downloadable archive with a few clicks — convenient and reliable, and often the easiest route for a WordPress site. Many hosts also provide their own backup tools or automatic backups in the control panel, which you can generate or download on demand before migrating. And some migration tools themselves create a full package that doubles as a backup.

So choose whichever method fits your comfort and setup: manual download-and-export for full control, a backup plugin for convenience, or your host’s backup feature if it offers a complete one. What matters is not the method but the result — a complete backup of both files and database, captured before you touch anything. Use the approach you find easiest, so long as you actually end up with the full, restorable copy the migration depends on.

Verify the backup is restorable

A backup you have not verified is only a hope, not a safety net — and this is the step people most often skip, to their eventual regret. A backup file existing is not the same as a backup that will actually restore a working site: the export could be incomplete, corrupted, or missing a component, and you do not want to discover that at the moment you desperately need to restore.

Verification means confirming the backup is complete and genuinely usable. At minimum, check that the backup includes both the full files (with the media folder) and the complete database, and that the files are not zero-byte or truncated and the database export is a full dump, not an error message. For higher-stakes sites, the gold standard is a test restore — restoring the backup to a separate location (a staging area or local environment) to confirm it actually produces a working site.

So do not just create a backup; confirm it works. The few minutes spent verifying — checking completeness, or better, doing a test restore — is what turns a backup from a comforting file into a genuine safety net you can rely on under pressure. An unverified backup that turns out to be broken at the moment of crisis is exactly the nightmare a backup is supposed to prevent, so close that gap by verifying before you proceed.

Where to store the backup safely

Where you keep your backup matters, because a backup stored only on the server you are migrating away from — or only on the server that might break — is vulnerable to the very failure it is meant to protect against. The safest practice is to store the backup somewhere separate and independent of both the old and new hosts.

Download the backup to your own computer, and ideally also keep a copy in separate storage (external drive or cloud storage), so that it survives whatever happens to either host. This ‘offsite’ independence is important: if the old host has a problem, or the new host’s setup goes wrong, your restore point is safe elsewhere, untouched by either. A backup that lives only on a server involved in the migration is a backup at risk.

So keep your pre-migration backup on independent storage — your computer plus a separate copy — for the duration of the migration, and do not delete it until the migration is fully complete and verified stable (typically several days after cutover, when you would also retire the old host). Storing it safely and keeping it until you are certain the new site is solid ensures your safety net is genuinely there for the whole risky window, not just at the start.

How the backup fits the migration

The pre-migration backup sits at the very start of the migration sequence and underpins everything after it. You create and verify it before you touch anything, and it then stays in reserve — your guaranteed restore point — through the whole process: copying the site, reconnecting, testing, cutting over, and verifying. At every step, if something goes wrong, the backup is what lets you recover rather than lose data.

In a manual migration, the backup is created as a natural by-product, since downloading the files and exporting the database (your first steps) are exactly what a backup is; you simply keep that downloaded copy safe rather than only using it as the migration source. In a plugin or host-assisted migration, you take the backup as a deliberate separate step first, since the tool’s own package is not a substitute for an independent safety net.

So the backup is the foundation the whole migration rests on: created and verified first, stored safely and independently, kept until the migration is confirmed stable, and available to restore from at any point. It is the least glamorous step and the most important one — the difference between a migration where any mistake is recoverable and one where a mistake could be catastrophic. Do it completely and verify it, and you have made your migration fundamentally safe before the real work even begins.

FAQs

How do I back up my website before migrating?

Capture both components completely: download all the files (via FTP or a compressed archive from the file manager) and export the full database (via phpMyAdmin) — or use a backup plugin or your host’s backup tool that packages both. Then verify the backup is complete and restorable, and store it on independent storage (your computer plus a separate copy), keeping it until the migration is confirmed stable.

What must a complete backup include?

Both components: all the files (the whole web directory — code, themes/templates, plugins, and especially the media/uploads folder) and the full database (all content, settings, users). Plus configuration files like wp-config.php and any special server settings. A files-only or database-only backup can’t restore a working dynamic site — completeness of both halves is what matters.

Why is backing up before migration so important?

Because it’s the safety net that makes every migration step reversible. A migration involves copying, moving, reconnecting, and switching — any of which could go wrong. With a verified backup, the worst case is a do-over; without one, a serious mistake could mean permanent data loss. It’s the single most dangerous corner to cut, and the foundation of a low-risk migration.

How do I verify a backup is good?

Don’t just create it — confirm it works. Check it includes both the full files (with the media folder) and a complete database dump (not an error message or truncated file). For higher-stakes sites, do a test restore to a separate location (staging or local) to confirm it produces a working site. An unverified backup that turns out broken at the moment of crisis is exactly what a backup should prevent.

Where should I store my pre-migration backup?

Somewhere independent of both the old and new hosts — download it to your own computer, and ideally keep a second copy in separate storage (external drive or cloud). A backup living only on a server involved in the migration is vulnerable to the very failure it protects against. Keep it until the migration is fully verified stable, typically several days after cutover.

Does a manual migration create its own backup?

Effectively yes — downloading all the files and exporting the database (the first steps of a manual migration) together are a full backup. Just treat that downloaded copy deliberately as your safety net: keep it safe and untouched as your restore point, separate from the working copies you upload to the new host. For plugin or host-assisted moves, take a separate backup first, since the tool’s package isn’t a substitute.

The bottom line

Backing up before a migration is the single most important thing you do, because it is the safety net that turns every subsequent step from an irreversible gamble into a recoverable action — with a verified backup, the worst realistic outcome of a botched migration shrinks to a wasted afternoon and a second attempt, while without one it can be permanent data loss. A backup is only useful if it is complete, which means capturing both components a website is made of: all the files (the whole web directory, and especially the large, irreplaceable media/uploads folder) and the full database (all content and settings), plus configuration files. A files-only or database-only backup cannot restore a working dynamic site, so completeness of both halves is what counts.

You can create the backup however suits you — the manual download-and-export (which a manual migration produces naturally), a backup plugin, or your host’s backup tool — but the method matters far less than two things: verify it and store it safely. Verification means confirming the backup is genuinely complete and restorable, ideally with a test restore to a separate location, because an unverified backup that turns out broken at the moment of crisis is exactly the nightmare a backup exists to prevent. And storage means keeping it independent of both hosts — on your own computer plus a separate copy — so it survives whatever happens to either server, and keeping it until the migration is confirmed stable days after cutover. Complete, verified, and safely stored: get those three right, and you have made your migration fundamentally safe before the real work even starts.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Back up before migrating: capture both the full files (whole web directory, especially the media folder) and the complete database, plus config files. Create it manually (download + phpMyAdmin export), via a backup plugin, or your host’s tool — then verify it’s restorable (ideally a test restore) and store it independently of both hosts (your computer plus a separate copy). Keep it until the move is stable. It’s the safety net that makes every step reversible.