You’ve planned your website migration for weeks. You’ve chosen a new host, mapped your DNS, and prepped your content. Then the backup fails. Or worse – you think it worked, but the restored site is broken. Backup mistakes cause most migration disasters. Here are the five most common ones and how to avoid them.

1. Skipping the Database Backup

Many people back up their website files and assume that’s enough. It’s not. Your database contains posts, pages, user accounts, comments, and plugin settings. Without it, your site is a shell.

A file-only backup can’t rebuild your content. You need both. If you’re using a plugin, check that the database option is enabled. If you’re going manual, export your MySQL database using phpMyAdmin or the command line. The Beginner’s Guide to Database Backups for Website Migration walks you through the process step by step.

2. Not Verifying Backup Integrity After Creation

Creating a backup is only half the work. The other half is confirming it actually works. A corrupted backup file is useless – you won’t know until you try to restore it.

Always verify your backups. Check that files open correctly and the database file isn’t truncated or empty. Many backup plugins offer a verification option. Use it. If you’re doing manual backups, test the restore on a staging site first. This is one area where Manual vs Plugin Backups: Which Is Better for Migrations? gives plugins a clear edge, since they often include built-in verification.

What exactly should you look for when verifying? Open the backup archive and check file sizes match the original. For database exports, ensure the SQL file starts with valid SQL and ends with a known marker (like “– Dump completed”). A file that’s suspiciously small or ends abruptly is likely corrupted.

3. Keeping Only One Copy of the Backup

A single backup is a single point of failure. If the server crashes during the migration or the backup file gets corrupted during transfer, you have nothing to fall back on. Always keep at least two copies of your backup in separate locations.

Store one copy locally (on your computer or an external drive) and another in cloud storage like Google Drive or Dropbox. For large sites, consider using a dedicated backup service or a remote server. Multiple copies give you a safety net if one fails.

Practical tip: use a 3-2-1 backup strategy. Three copies of your data, on two different media types, with one copy offsite. For example: one copy on your local hard drive, one on an external USB drive, and one in cloud storage. This covers hardware failure, accidental deletion, and regional disasters.

4. Overlooking Encryption for Sensitive Data

Backups often contain sensitive information: customer emails, order details, API keys, and database credentials. If your backup falls into the wrong hands, you expose your entire business to risk.

Always encrypt your backup files, especially if you’re storing them offsite or transferring them over a network. Use AES-256 encryption, which is standard and reliable. Many backup plugins include encryption options. For manual backups, you can encrypt the archive using tools like GPG or 7-Zip with a strong password.

A common mistake is using a weak password or reusing the same password across backups. Generate a unique, complex password for each backup. Store passwords in a password manager, not in the backup file itself. Also consider encrypting the database dump before packaging it with files.

5. Forgetting Hidden Files and Critical Directories

Standard file backups often miss hidden files like .htaccess, wp-config.php, or .env configuration files. They also may exclude certain directories including uploads, themes, or plugins if your backup setup is incomplete.

These hidden files control your site’s routing, security, and core settings. Without them, your migration will fail. Before starting a migration, review your backup source carefully. Make sure all critical directories and hidden files are included. For WordPress sites, the How to Backup Your WordPress Site Before Migration guide has a complete checklist.

Beyond WordPress, check for files like .gitignore, robots.txt, or any custom configuration files your application depends on. A good test is to spin up a local copy of your site from the backup and verify everything works: pages load, forms submit, login works, and media is accessible.

How to Handle Backup Failures During Migration

Even with careful planning, backups can fail. Maybe the server runs out of disk space mid-export, or the backup process times out for large sites. Here’s what to do.

First, never force restart a backup without cleaning up partial files. A failed backup often leaves incomplete or corrupted files behind. Delete those before retrying. Check your server error logs for clues: insufficient memory, timeout limits, or permission issues are common causes.

For large sites, consider incremental backups rather than full ones. Some plugins support splitting backups into chunks. If timeouts are the issue, increase the PHP execution time limit or use command-line tools like mysqldump which are more reliable for large datasets.

If a backup repeatedly fails, test your server resources. Run a disk space check (df -h) and memory usage (free -m). Low resources can cause quiet failures. In that case, temporarily increase limits or schedule backups during off-peak hours.

Automating Backup Verification to Save Time

Manually verifying each backup is tedious. Automate it with scripts or tools that check file integrity. For example, you can write a cron job that runs a checksum (SHA256) on your backup files after creation and compares it to a known good value. If they don’t match, the script sends an alert.

Many hosting control panels offer automated backup verification as part of their backup solutions. Or you can use a backup plugin that includes a “test restore” feature — it simulates restoration without actually overwriting files. This catches issues early without manual effort.

If you’re using command-line backups, consider piping the output through a validation step. For MySQL dumps, run mysqlcheck on the restored database. For file archives, use tar -tzf to list contents without extracting — if it errors, the archive is corrupt.

Automation doesn’t replace occasional manual checks, but it drastically reduces the risk of storing a bad backup for weeks without noticing.

How to Prevent These Mistakes: A Quick Checklist

Here’s a step-by-step checklist to follow before every migration:

1. Back up both files and database in a single operation.
2. Verify the backup file opens and is not truncated.
3. Create two copies on separate storage mediums.
4. Encrypt the backup if it contains sensitive data.
5. Confirm hidden files and all directories are included.
6. Test a restore on a staging site before touching the live environment.
7. Document your backup process so anyone on your team can follow it.

Test your backup process on a non-critical site first. That way you learn the ropes without risking your live site. A little preparation now saves hours of recovery later.

Frequently asked questions

What should I do if my backup file is corrupted?

If your backup is corrupted, try to restore it to a staging environment to confirm. If it fails, create a fresh backup from the live site. Use a different backup method, such as a plugin if you used manual before. Always verify the new backup before starting any migration.

How can I verify a backup file’s integrity without restoring it?

Many backup plugins include a verification feature that checks the archive file format and compares checksums. For manual backups, you can open the archive (e.g., .zip or .tar.gz) in an archive manager and confirm it contains the expected files. Database exports can be reviewed in a text editor to ensure they end with a complete SQL statement.

Do I need to encrypt my backup if my site has no customer data?

Even without customer data, your backup may contain admin credentials, API keys, or configuration details that could be used for attacks. Encrypting your backup is a good security practice regardless of data type. It requires minimal effort and adds a strong layer of protection.

What are the most commonly missed hidden files in WordPress backups?

The most commonly missed hidden files include .htaccess, wp-config.php, .user.ini, .env, and the entire wp-content/uploads folder. These files control important settings and content. Always confirm your backup includes the root directory and all subdirectories.

Should I use a plugin or manual method for backing up before a migration?

Both work, but plugins simplify the process and often include verification and encryption options. Manual methods give you more control but require more technical knowledge. For beginners, a plugin is usually the safer choice. If you prefer manual, test it on a staging site first.