How to Back Up Your Website Before Moving Hosts

Published October 19, 2026

A migration without a backup is a gamble. The backup is your rewind button — if anything breaks mid-move, you restore and nobody ever knows. Here’s how to do it properly.

What “full backup” actually means

A real backup has four parts. Most people grab one or two and call it done.

  1. Website files — everything in public_html: code, themes, plugins, uploads, media.
  2. Database — posts, pages, users, settings, orders. For WordPress, this is the MySQL database.
  3. DNS records — a screenshot or export of your DNS zone. If you fat-finger a record during the move, this is how you put it back.
  4. Email — mailboxes and forwarders, if email is hosted with your web host.

Step 1: Back up the files

cPanel: File Manager → compress public_html to a zip, then download it. Or use FTP (FileZilla) to download everything — slower but you see exactly what you got.

WordPress plugin route: UpdraftPlus or All-in-One WP Migration can package files + database into one downloadable archive. UpdraftPlus can also push the backup straight to Google Drive or Dropbox.

Manual: FTP download of the entire document root. Tedious for large media libraries, but foolproof.

Check the size when it finishes. If your site is 2GB and the backup is 40MB, something didn’t get captured.

Step 2: Back up the database

phpMyAdmin: select the database → Export → Quick → Go. Download the .sql file. For large databases, use the Custom export with compression enabled.

Plugin route: covered automatically by UpdraftPlus / All-in-One WP Migration.

Command line (if you have SSH): mysqldump -u username -p database_name > backup.sql — fastest for big databases.

One database per site. If you run multiple sites, export each one separately and label the files clearly.

Step 3: Save your DNS records

Screenshot your DNS zone editor, or export the zone file if your provider allows it. You need: A records, CNAMEs, MX records, TXT records (SPF, DKIM, DMARC), and any SRV records. DNS mistakes are the most common migration breakage, and a record of the working configuration turns a crisis into a five-minute fix.

Step 4: Don’t forget email

If your host handles email: note every mailbox, forwarder, and autoresponder. Copy important mail via IMAP to a local client (Thunderbird) or to the new host later. At minimum, export anything you couldn’t afford to lose — invoices, contracts, client correspondence.

Step 5: Store it somewhere safe

The backup must live outside both hosting accounts. Your laptop, an external drive, Google Drive, Dropbox — anywhere that’s not the server you’re leaving or the one you’re moving to. A backup stored on the server it backs up isn’t a backup, it’s a copy.

Keep at least two copies in two places for anything business-critical.

What can go wrong with backups (and how to prevent it)

Backups fail in predictable ways. Knowing them in advance is the difference between a safety net and a false sense of security:

Every one of these has bitten someone during a migration. The pattern is always the same: the backup existed, but nobody verified it.

Migration-day backup checklist

Run this the morning of the move:

Thirty minutes of verification buys total confidence for the rest of the migration.

After the migration succeeds: don’t delete the pre-migration backup immediately. Keep it for at least 30 days as your rollback point — if a subtle problem surfaces in week three (a missing redirect, a broken integration), the original backup is the fastest way to compare and recover. After a month of clean operation, fold it into your normal backup rotation and let retention policies handle it.

Step 6: Test the restore

An untested backup is a hope, not a backup. You don’t need to do a full restore drill, but at minimum:

If you have a staging environment or local server, doing one full test restore before migration day is the gold standard. It also rehearses the migration itself.

Quick restore-test for WordPress: spin up a free local WordPress with LocalWP or a cheap staging subdomain on the new host, import your backup there, and click around. If the backup restores cleanly into a fresh environment, it’ll restore anywhere.

How often to back up (beyond migration day)

Migration backups are one-offs, but they should plug into a routine:

Most decent hosts include automated backups. The question to ask isn’t “do you back up?” but “how often, how long do you keep them, and can I restore with one click?” If the answer to the last one is no, run your own with UpdraftPlus on a schedule.

Automating it

Don’t rely on remembering. Set it once:

When to delete the backup

Don’t. Keep the pre-migration backup for at least 30 days after the new site is verified working. Storage is cheap; the one time you’ll need it is the time you deleted it. After a month of smooth operation on the new host, rotate it into your normal backup retention.

Backups are boring right up until they’re the only thing standing between you and rebuilding a site from memory. Take the hour. Future you says thanks.

Disclosure: Registrar Watch earns a commission when you sign up through some links on this page — it keeps the guides free and independent. We recommend registrars we'd trust with our own domains.