Website Migration Backup Checklist: What to Save and How to Test

A useful migration backup is a recoverable copy of the data and configuration your site actually needs. Before switching hosts, inventory those components, export them privately, and test recovery in an isolated destination. A downloaded archive or a matching file count alone does not prove that a website can be restored.

Reviewed October 14, 2026. This checklist separates backup scope, transfer integrity and application recovery. The read-only archive checks below were tested with synthetic fixtures; they are not a claim that your hosting account, database or application has been restored successfully.

Record the scope before exporting

• Website files: document roots, uploads, hidden configuration files and required directories outside the web root. Record external object storage, symlinks and mounted data separately.
• Databases: engine and version, database names, schema and data, required routines/events, extensions and access mappings. Do not assume a database dump includes server-level users.
• Email: identify the actual mail provider. If email is moving, inventory mailboxes, aliases, filters and message folders; otherwise record the routing that must stay in place.
• DNS: retain the current zone records and identify the authoritative provider. Include website, mail, verification and authentication records, and note any DNSSEC configuration.
• HTTPS: decide whether the destination will issue a new certificate or use an authorized transfer of an existing certificate and key. Exporting a private key is not always necessary.
• Application operations: record cron jobs, queues, workers, environment settings, runtime extensions and external integrations. Record dependencies you cannot export yourself so the provider can address them.

Also record the last successful backup time, the expected restore destination, the person responsible for testing, and how to stop writes during the final synchronization. Avoid putting secrets into this inventory if a reference to a password manager or private configuration store will suffice.

Use a backup method that matches your account

For panel-managed hosting, use the tools available at your account’s permission level and confirm what they include. A user-level website backup is not a full server backup, and one panel’s archive is not necessarily importable into another. Our cPanel transfer guide explains full-account versus partial restores.

For a VPS or dedicated server, agree the file and database backup method with the administrator. Do not use a root-level dump of every database as the default for moving one website. Coordinate file changes and database consistency, especially for orders, uploads and background jobs. A database transaction snapshot alone does not synchronize a separately copied uploads directory.

For MySQL, mysqldump --single-transaction has transaction and storage-engine limitations; concurrent schema changes can disrupt the export. Required routines and events need explicit consideration, and application user privileges need a separate plan. Follow the version-matched MySQL dump documentation rather than pasting a generic all-databases command into production.

PostgreSQL’s pg_dump exports one database, not cluster-wide roles or tablespaces. Those global objects need a separate, authorized migration plan. Review the PostgreSQL export documentation, client/server compatibility and destination ownership requirements. Restoring a database dump can execute SQL from its source, so do not restore an untrusted dump on a privileged production system.

If a managed-host snapshot cannot be downloaded, establish how you can recover after cancelling that service. A provider-only restore point is not an independent off-provider copy. Likewise, a WordPress plugin export may cover the application but not mailboxes, DNS or server configuration.

Keep backups private

Store temporary archives outside all public website directories. Use authenticated encrypted transfers and appropriately restricted storage permissions. Encrypt sensitive retained copies and keep recovery keys available through a separate controlled channel. Test that the people responsible for recovery can actually decrypt and access the backup.

Retain independent copies rather than only a backup on the server being replaced. A common planning model is three copies of data, on two storage types, with one offsite. The live dataset can be one of those copies; this does not mean everyone needs three additional cloud accounts. Choose retention and deletion dates that fit the business’s recovery and privacy requirements.

Check integrity without overstating what it proves

Compression changes file size. A compressed archive does not need to match the live directory’s size, and a directory-entry count is not a reliable completeness test. Empty files can be legitimate. Instead, check the backup job’s completion status, inspect the expected paths and compare the same archive’s checksum before and after transfer.

For an existing trusted .tar.gz file, the following Linux shell fragment performs read-only checks. Replace the example path with the private archive you want to examine. It neither extracts files nor changes the archive.

(
    set -eu
    archive="$HOME/private-backups/site-files.tar.gz"
    test -f "$archive"
    test -r "$archive"
    gzip -t -- "$archive"
    tar -tzf "$archive" > /dev/null
    sha256sum -- "$archive"
)

A nonzero exit status means a check failed and you should stop to investigate. If all commands succeed, the final line contains a SHA-256 digest and filename. Compare the digest with the one recorded for the same archive at the source. Hashing two separately generated archives is not a useful equality test, because archive metadata can differ.

Limit: these commands can identify damaged compression or an unreadable tar structure and fingerprint the bytes. They do not prove that required files were included, that SQL will import, that the backup is malware-free, or that the application works. A deliberately incomplete archive can pass all these checks.

Test record: seven fixture checks passed in an isolated Alpine 3.22 container with no network access: a valid archive containing a hidden file and legitimate empty file; a truncated archive; a damaged gzip checksum; compressed data that was not a tar archive; a missing input; two different valid archives with different hashes; and an intentionally incomplete archive that still passed structural checks. No customer files were read or restored.

Perform a controlled restore test

1. Prepare a separate destination. Confirm the hostname, filesystem path and database instance before importing. Do not overwrite production or connect a staging application to the live database.
2. Restrict the test copy. Block public access and prevent real outgoing email, payments, webhooks and background work. Do not install the production crontab and assume it is safe to run.
3. Restore and inspect errors. Check the restore log, required tables and representative records, file permissions, application configuration and missing dependencies. Review archive paths before extracting; do not unpack untrusted archives as root.
4. Test the intended virtual host. Use the application’s actual hostname with an approved preview method or hosts-file override. An IP-only request can miss routing, cookies, redirects and TLS/SNI behavior.
5. Exercise useful workflows. Check login, content, media and application-specific actions with test data. Test mail and scheduled work deliberately in a controlled environment rather than enabling real production actions.
6. Record the result. Note which backup was restored, the software versions, what was checked, failures still open and who accepted the result. Mark untested components explicitly.

Plan cutover and rollback around changing data

Set a migration window and agree how to pause or reconcile writes. The first backup becomes stale as new orders, messages or uploads arrive. Decide when to take the final copy and which host is authoritative afterward. If you roll back, reconcile data created on the new host before sending traffic back to the old one.

If lowering DNS TTL is part of the plan, allow records cached under the previous TTL time to expire before cutover. A five-minute TTL is not a guarantee that every visitor switches within five minutes. Change the records required for your topology: A and AAAA for website addresses, and mail or nameserver-related records only when those services are changing. Preserve required records and coordinate DNSSEC if changing authoritative providers.

Keep the old service available until the migration is accepted and the overlap period is complete. Do not cancel a package that still provides mail or DNS you intend to retain. Monitor application errors, incoming traffic and mail routing after cutover, then remove temporary transfer access and redundant backup copies according to your retention plan.

Final go/no-go checklist

• The inventory identifies every required component, including anything outside the main website directory.
• The source export finished successfully, and private copies are accessible independently of the old host.
• Transfer checksums match where applicable, and a separate restore test covers the important application workflows.
• Mail, HTTPS, scheduled jobs, DNS changes and remaining untested components have named owners.
• The final synchronization, write controls, rollback procedure and source-service overlap are agreed.

If a required check fails, postpone the cutover rather than replacing verification with a file-size comparison. For an InterServer-assisted move, put the unresolved item in your migration support ticket before DNS is changed.