What to Back Up Before Switching Hosts A Complete Checklist

Before you switch hosts, back up everything that defines your site: the files, the database, the configuration that ties them together, and the credentials that let you prove you own them. The target search phrase, what to back up before switching hosts, is not a single download. It is a list of artifacts, each with its own export mechanism, and missing any one of them can turn a routine migration into a rebuild from memory.

What to Back Up Before Switching Hosts: The File Layer

Start with the document root, usually something like /var/www/html or ~/public_html. Copy it with rsync so you preserve permissions, timestamps, and symlinks. Do not use a plain cp -r if you can avoid it, because rsync -a handles edge cases like sparse files and hard links better. Run this from your local machine, not from the server, to avoid writing the archive onto the same disk you are reading.

rsync -avz --progress user@old-server:/var/www/html/ ./site-backup/

The output will list every file copied, and the final line will show a summary of bytes transferred. Verify that the local directory has the same file count as the remote one by running find ./site-backup -type f | wc -l on both sides. Pay special attention to hidden files: .htaccess, .env, .git directories, and any wp-config.php or similar application config. These are often excluded by default in FTP clients, so use rsync or tar with explicit includes.

Database Dumps and Their Quirks

Your database is not a file you can copy while the server is running, because writes will corrupt the dump. Use the native export tool for your database engine. For MySQL or MariaDB, that is mysqldump. For PostgreSQL, it is pg_dump. Do not use a web-based admin panel export unless you are certain it locks tables, because a live site will produce inconsistent foreign keys.

mysqldump --single-transaction --quick --lock-tables=false \
  -u dbuser -p dbname > dbname.sql

The --single-transaction flag gives you a consistent snapshot without locking the whole database, but only works with InnoDB tables. If you have MyISAM tables, drop that flag and accept a brief lock. After the dump, check the first few lines of the file for a CREATE TABLE statement and the last lines for a Dump completed comment. Also export the database users and their privileges, not just the data. Run SHOW GRANTS FOR 'youruser'@'localhost'; and save that output. The new host may have a different MySQL version, and privilege syntax can change, so keep the original grants as a reference.

Configuration Files Outside the Document Root

Many sites have settings that live outside the web root. Look for /etc/nginx/sites-available/ or /etc/apache2/sites-available/ for the virtual host definition. That file contains the server name, the document root, the SSL certificate paths, and any rewrite rules. Copy it verbatim. Also grab the PHP configuration, usually /etc/php/8.x/fpm/php.ini or a per-site .user.ini, because memory limits and upload sizes are often tuned for your application. Do not forget cron jobs. Run crontab -l to list them, and save the output to a file. A missed cron job can silently break email sending or scheduled backups for months after the move.

SSL certificates are a special case. The private key and certificate chain are often in /etc/letsencrypt/live/yourdomain/ or a similar path. Copy the full directory, including the privkey.pem and fullchain.pem. You can reissue certificates on the new host, but if you have an extended validation certificate or a custom key, reissuing takes time. Store the key in a secure local file, never in the same backup as your public files, because a leaked private key invalidates the certificate.

Credentials and Endpoint Definitions

You need more than the database password. Write down the SMTP relay host and port, the API keys for any third party services, and the SSH fingerprint of the old server. For a WordPress site, that means the keys in wp-config.php and the salts. For a custom app, look for config.yml, settings.py, or .env. Export the environment variables with env if they are set in the shell profile, but be careful: the output includes the current PATH and shell variables that are not site-specific. Instead, grep for lines that contain DB_HOST, API_KEY, or SECRET.

Also record the DNS records, not just the nameserver settings. Run dig yourdomain.com ANY and save the output, plus dig yourdomain.com MX and dig yourdomain.com TXT. The TXT records may contain SPF or DKIM keys that you will need to replicate exactly. If you use a managed DNS service, log in and export the zone file manually, because some providers do not offer a raw export. The zone file format is standard, and the new host can import it directly.

Verifying the Backup Before You Kill the Old Server

Do not test your backup on the new host. Test it on a local virtual machine or a temporary directory first. Restore the database dump into a fresh database, start the web server with the copied configuration, and check that the site loads. Run a few manual queries, like fetching the latest post or logging in with a test user. If the backup is incomplete, you will find out here, not after you have cancelled the old hosting plan.

One common failure is a missing .htaccess or an nginx rule that rewrites URLs. Your backup will restore files, but the rewrite rules are part of the server configuration. If you copied the virtual host file, test it with nginx -t or apachectl configtest before pointing DNS to the new server. Similarly, check that the PHP version on the new host matches the one your application expects. A PHP upgrade can break deprecated functions, so review the changelog for your specific application framework.

After the Move: What to Keep and What to Discard

Keep the entire backup directory for at least one full billing cycle after you switch. You will likely discover a missing cron job or a custom SMTP header that you forgot to replicate. But do not keep the database dump indefinitely, because it contains user credentials and personal data. Once you have verified the new site works, delete the local copy of the database dump and the private key, or move them to an encrypted archive. The file backup can stay, but compress it with tar -czf to save space.

Finally, update your local documentation. Write down the new SSH port, the new database hostname, and the new control panel URL. The old host may keep your account active for a while, but you should treat it as gone the moment you have confirmed the new site responds to a public request. Your next migration will be easier if you have a single BACKUP_MANIFEST.txt file that lists every artifact you exported and where you stored it. That file is the one thing you cannot generate from the server, so write it now, before you start the move.