How to Move a WordPress Site With a Rollback Plan

Moving a WordPress site to a new host or a new domain is a significant operation, and it deserves a plan for the case where something goes wrong. A WordPress site depends on two synchronized components: the files on the server and the database that holds your content and settings. The steps below follow the sequence documented in the official WordPress guides, and the rollback path relies on one thing only — restoring the backups you make before you begin.

Make Paired Backups Before Anything Else#

According to WordPress backup guidance, a complete backup includes your entire file set — core files, wp-config.php, themes, plugins, and wp-content/uploads — paired with a database export. A file copy without the database, or a database dump without the files, is an incomplete backup that cannot rebuild a working site.

The same guidance recommends keeping at least three recent backups available, since a backup can prove corrupted or inaccessible when you need it. Store copies in more than one physical location, such as a local drive and a remote server, rather than only on the hosting server itself.

For the database half of the pair, WordPress documentation on database backups describes tools including phpMyAdmin, the mysqldump command-line utility, and options in hosting control panels. Generate the file backup and the database export as a matched pair, download both, and only then move on.

Follow the Documented Migration Order#

The WordPress migration guide has separate branches for keeping the same URLs and for changing them. The sequence here follows its single-site domain-or-URL-change branch. Keep the original, pre-change file and database backups together in a separate safe folder: they are the rollback copy, not the export you will import at the destination after changing URLs.

1. Change the WordPress Address and Site Address in the source site's settings and save them. The guide notes you may see 404 errors while routing changes take effect — this step affects the source site.
2. Download the site files again after saving the URL changes. Keep this new download separate from the original rollback files.
3. Export the database again after the URL changes. Pair this fresh export with the newly downloaded files for the destination; do not substitute the original pre-change database backup.
4. Edit wp-config.php in the new file set with the destination database credentials before uploading it.
5. Upload that new file set, including its configured wp-config.php, to the destination.
6. Import the fresh, post-URL-change database export on the destination server.

These steps follow the documented branch of the guide; they are not a claim that every other migration sequence necessarily fails. If your domain and URLs stay the same, use the guide's separate unchanged-URL branch instead.

Check URLs and Configuration Before Cutover#

Two checks matter before you point visitors at the new environment. First, confirm the WordPress Address and Site Address settings were both updated and saved, since, as the WordPress migration guide notes, these settings directly affect the site's routing and references. Second, confirm the wp-config.php values match the destination database credentials, because wp-config.php holds the connection details the site uses to reach the database.

Host-specific details vary, so answer these from your own provider's documentation: Does your host offer phpMyAdmin, an equivalent database tool, or SSH access for importing the export? What are the exact database name, username, password, and hostname assigned to your account? Does the host support SFTP, FTPS, or a web-based file manager for uploading files? Is a temporary or preview URL available for testing before DNS changes? Does the destination plan meet the PHP and MySQL or MariaDB requirements of your WordPress version?

Test the Destination Before Changing DNS#

Before changing public DNS records, verify the destination environment: the database connection works, the directory structure is intact, and the URL mappings resolve correctly. Ask your host which supported testing method is available before cutover; a preview or staging URL is a provider-specific question, not a capability promised by these sources. Proceed with the DNS change only when the destination behaves as expected.

Roll Back by Restoring the Paired Backups#

If the migration fails, the rollback in this plan is restoring the original pre-change file and database pair to return the site to its known working state, not reusing the newer destination export. As the WordPress backup guidance describes, restoring means deploying the paired file backup and re-importing the paired database backup; one half without the other is not a restoration.

DNS reversion is not a substitute for this and is not a guaranteed recovery path, so treat backup restoration, not DNS changes, as the recovery step in this plan. The recommendation to keep at least three recent backups exists for this moment: if a copy proves corrupted during restoration, you have further matched pairs to try.