Pre-Migration Backup Checklist: What to Save Before Moving

Moving a website is risky. One wrong step and you lose data, break functionality, or face downtime. That’s why a solid pre-migration backup checklist is non-negotiable. You need to save everything: files, databases, configurations, and access credentials. This guide walks you through what to backup before any migration, so you’re never caught without a restore point.

1. Full File Backup: What to Include

Your website runs on files. That includes HTML, CSS, JavaScript, images, uploaded media, plugins, themes, and scripts. Don’t assume a simple FTP download is enough. You need a complete copy of your web root directory (usually public_html or www).

Use tar or zip commands on the server, or a plugin if you’re on a CMS. Make sure you capture hidden files like .htaccess, .env, and any configuration files. If your site uses a version control system (like Git), ensure you also pull the latest commit. Store this archive in at least two locations: local drive and cloud storage.

When using tar, a typical command is tar -czf backup-files.tar.gz /path/to/webroot. Verify the archive by listing contents: tar -tzf backup-files.tar.gz. Check that directories like wp-content/uploads or var/www/media are present. If file sizes are much smaller than expected, something is missing. Also confirm hidden files are included — on some systems, tar excludes them by default unless you add .* or use the --exclude= flag carefully.

2. Database Backup: Every Table Matters

Your database holds posts, pages, user accounts, settings, and plugin data. A single missing table can break your site. Use mysqldump or a PHPMyAdmin export. Choose the right format: SQL with DROP TABLE IF EXISTS and CREATE TABLE statements. Include all tables, not just the ones you think are important.

Pay attention to charset and collation. Many migrations fail because the database export uses a different character set than the new server. Set --default-character-set=utf8mb4 if you’re using MySQL. After export, verify the file size is reasonable and you can open it in a text editor. A corrupted export is worse than no backup.

A typical mysqldump command: mysqldump -u username -p --default-character-set=utf8mb4 --complete-insert --no-tablespaces --routines --triggers --events your_database > backup-db.sql. The --routines and --triggers flags save stored procedures and triggers, which are easy to forget. Also include --events if you use scheduled events in MySQL. After the dump, open the SQL file in a text editor and search for CREATE TABLE statements to confirm tables are present.

3. Server Configuration Files

Your web server (Apache, Nginx, LiteSpeed) has settings that control caching, compression, redirects, and security. Save the full configuration files. For Apache, that means httpd.conf and any virtual host files. For Nginx, save nginx.conf and site-specific .conf files.

Don’t forget PHP settings: php.ini or .user.ini files. These control upload limits, memory limits, execution time, and error reporting. If you use a control panel like cPanel or Plesk, export the entire account backup feature, which often includes configs automatically.

Common pitfalls: Nginx configuration files may have symlinks or include directives pointing to other files not in the same directory. Run nginx -T to print the entire compiled configuration to screen — pipe that to a file. For Apache, use httpd -S to list virtual hosts and their config paths. Then copy each referenced file individually.

4. DNS and Domain Settings

DNS records are critical for email and website accessibility. Log into your domain registrar or DNS provider and export your zone file. Most providers allow you to download a text file. Save the A, CNAME, MX, TXT, and any custom records. Also note the nameservers and TTL values.

If you’re changing hosting providers, you’ll need to replicate these records on the new server. A missing MX record can cause email delivery failure for days. Take a screenshot of the DNS management page as a visual backup.

If your provider doesn’t support zone file export, manually copy each record into a spreadsheet. Include the type, name, value, priority (for MX), and TTL. Double-check that no wildcard records (like * A records) are accidentally omitted. Also verify that your domain’s DNSSEC settings are captured — these are security extensions and must be replicated exactly or turned off before migration.

5. SSL Certificates and Security Keys

SSL certificates are tied to your domain and server. If you have a free Let’s Encrypt certificate, note that it may need re-issuance after migration. For paid certificates, export the private key and certificate files (usually .key and .crt). Store them securely — never share via email.

Also save your application secret keys and API tokens. For WordPress, that’s the salts in wp-config.php. For other CMS platforms, check configuration files for encryption keys, authentication keys, and any third-party service API keys. Without them, some features may stop working.

To export Let’s Encrypt files, copy the entire /etc/letsencrypt/live/yourdomain.com/ directory. For Nginx or Apache, also back up any intermediate certificates and certificate chain files. Use a secure method like scp or encrypted cloud storage. Never store private keys in unencrypted form on a shared drive.

6. Email Accounts and Mail Configuration

Email is often overlooked. If you have email accounts on your current hosting, you need to back up the maildir or IMAP folders. Use an email client to export each account to a .pst or .mbox file. Then, on the new server, you’ll set up mailboxes and import the data.

Also document your mail server settings: SMTP/IMAP/POP3 hostnames, ports, authentication methods, and any spam filtering rules. If you use a third-party email service (like Google Workspace), ensure your DNS MX records are correct after the move.

For server-based email (like cPanel’s mail), the mail data is often stored in /home/username/mail/. Use a command like tar -czf backup-mail.tar.gz /home/username/mail/. Be aware that large mail directories can take time to compress. Also, note any forwarders, auto-responders, and spam filter whitelist/blacklist settings — these are usually manageable via the control panel interface and may need manual recreation.

7. Cron Jobs and Scheduled Tasks

Many sites rely on cron jobs for backups, cache clearing, email digests, and database maintenance. Log into your control panel and list all cron jobs. Note the commands, schedule, and any script paths. A missing cron job can cause your site to stop performing routine tasks.

If you have shell access, run crontab -l to view current jobs. Save the output. On the new server, recreate each cron job with the same timing and command. Double-check that file paths are absolute and point to the correct directories on the new server.

Some cron jobs use environment variables or rely on specific shell settings. When recreating, consider adding SHELL=/bin/bash and PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin at the top of the crontab to avoid path issues. Also note if any jobs use relative paths — they should be converted to absolute paths.

8. Test Your Backups Before Migrating

A backup is worthless unless you can restore it. Before you start the migration, restore your backup to a staging environment. This could be a subdomain or a local server. Check that pages load, forms submit, emails send, and admin login works.

If you find issues, fix the backup process before moving. Common problems include missing files, incorrect database prefix, or file permission errors. Testing also gives you a practice run of the restore procedure, so you know exactly what to do on migration day.

9. Verify File Permissions and Ownership

File permissions and ownership differ between servers. A backup that preserves exact permissions may break on a new system if the web server user differs. Record the current ownership (user and group) for critical directories like uploads or cache. On Linux, use ls -la to see permissions and stat for ownership details.

During restore, you may need to adjust: set directories to 755, files to 644, and the web server user (e.g., www-data) as owner. Scripts that require write access (like file uploads) should belong to the web server group. Document any custom permission schemes, such as sticky bits or setgid directories.

10. Document Third-Party Service Integrations

Your site likely connects to external services: CDN, payment gateway, analytics, email marketing, social media APIs. List every integration, its API endpoint, and any IP whitelisting needed. After migration, server IPs change — update these in the service dashboards.

For example, if you use Cloudflare, note your original server IP and update the DNS records to point to the new server. For payment gateways like Stripe, check if webhook URLs need updating. Create a spreadsheet with each service, the API key or token, and any configuration URL. Store this securely alongside your backups.

Remember: the goal of a pre-migration backup checklist is not just to have copies. It’s to have complete, restorable backups that let you sleep at night. Take the time to verify everything, and your migration will go smoothly.

Frequently asked questions

What is the most important thing to backup before a website migration?

The most critical backups are your website files (including .htaccess and config files) and your database. Without both, you cannot restore the site to its current state. Always export the database in SQL format with all tables and use a reliable file archive tool.

How do I backup my website database before migration?

Use phpMyAdmin to export all tables as an SQL file, or use the command line with mysqldump. Ensure you select the correct charset (utf8mb4) and include DROP TABLE statements. Store the export file securely. For CMS sites, plugins like UpdraftPlus can automate this.

Do I need to backup DNS records before migrating?

Yes. Export your DNS zone file from your registrar or DNS provider. This includes A, CNAME, MX, and TXT records. Without this, you may lose email functionality and domain resolution. Save a plain text copy for reference during migration.

Should I backup SSL certificates before moving my site?

Absolutely. SSL certificates are domain-specific and may need to be re-issued if not backed up. Export the private key, certificate file, and any intermediate certificates. If you use Let’s Encrypt, you can always re-issue, but it’s safer to have a copy.

How do I verify my backups are usable before migration?

Restore the backup to a staging environment (local server or subdomain). Verify that the site displays correctly, all pages load, forms work, and you can log in. Also check that file permissions and database connections are intact. This confirms your backup is complete.