The website migration checklist: move with a rollback plan

Decide exactly what is moving

“Move the website” can mean several different operations: changing the hosting account, changing the domain, changing the DNS provider, moving email or rebuilding the site in different software. Write down which operations are included and avoid combining them unless there is a good reason.

The lower-risk case is moving a conventional site to a new server while keeping the domain and URL structure. A domain or URL change adds redirect and search-indexing work. A move from a proprietary builder to WordPress may be a rebuild rather than a file migration.

Keep this inventory outside the old hosting account. If the old account becomes unavailable, the plan should still be readable.

Take a backup you can actually restore

Copy website files, the database and configuration. For WordPress, a content export alone is not a complete server backup. Preserve uploaded media, themes, plugins and the configuration required to connect to the database.

Check that the archive opens and the database export is nonempty. Restore a private copy if possible. The official WordPress migration documentation explains the special considerations for configuration and changed URLs.

Do not perform a blind text replacement across a WordPress database when changing a domain. Some values use serialized data and can break if lengths are altered incorrectly. Use a method designed for the application, take a backup first and test the result.

Store the recovery copy somewhere independently accessible. A backup left only on the source host does not protect against losing access to that account.

Prepare the destination before changing traffic

Create the destination account, database and application environment. Match a supported runtime rather than copying an obsolete version merely because it was used on the old host. Document any necessary compatibility changes separately from the migration.

Install the site in a private preview environment. Protect it from public access where appropriate and prevent accidental indexing. If you use temporary URLs, record every change so they do not remain in canonical tags, internal links or application settings after launch.

Check HTTPS support, rewrite rules, file permissions, upload paths, email delivery and scheduled tasks. A site can look correct while its enquiry form silently fails or its background import no longer runs.

For a store, make sure the preview cannot send real customer messages or process real payments accidentally. Use the application’s supported test mode and check which external credentials belong to production.

Validate real journeys on the private copy

Create a checklist based on the site’s actual purpose. A brochure site needs contact and navigation checks. A membership site needs registration, login, password reset and access control. A store needs product search, cart and safe checkout validation.

• Open important pages directly, not only through the homepage.
• Check images, downloads, fonts and redirects.
• Submit a form and verify delivery at the receiving end.
• Check a phone-sized layout and the navigation controls.
• Verify administrator access and limited collaborator roles.
• Confirm scheduled tasks and external integrations.

Compare a sample of old and new URLs and content. Record defects and fix them before the DNS cutover. If you are changing URLs, build the old-to-new mapping now rather than discovering missing redirects after launch.

Handle new writes during the final copy

A static site may need only a final file sync. A transactional site is harder because the source can keep receiving new orders, comments or member updates while you copy the database. Two independently writable copies can diverge.

Choose an application-appropriate method: a short maintenance window, a write freeze, a carefully planned synchronization or a managed migration procedure that preserves new data. Name the person who confirms the final source of truth.

DNS changes are observed at different times because of caching. Lowering the relevant TTL in advance can help shorten some cache lifetimes, but it does not make every resolver update instantly. Keep both environments available while the transition is checked.

Write down the final-copy time and the expected handling of traffic that still reaches the old server. A migration should not depend on hoping that every customer arrives through the same resolver.

Change DNS narrowly and keep email intact

If only the website moves, change the necessary web records rather than automatically replacing the entire nameserver configuration. If you do change nameservers, reproduce the required records at the destination first, including mail routing and verification records.

Check both the root domain and the www hostname. Confirm that the chosen canonical address redirects consistently and that HTTPS works without certificate warnings. Remove temporary preview settings from the public site.

Verify email separately. Send to and from an external mailbox and check that the correct provider is handling delivery. Do not assume that a working homepage means the MX records or mail-authentication configuration survived the move.

For URL changes, use the appropriate permanent redirects from each old page to its closest replacement. Redirecting every removed URL to the homepage usually gives visitors an unhelpful result. Follow Google’s site-move guidance for the search-related part of the transition.

Use a rollback decision, not an improvised reversal

Decide in advance which failures require a rollback. Examples include lost transactional data, a broken checkout or an application incompatibility that cannot be resolved within the allowed outage window. Minor spacing differences do not normally justify another traffic switch.

A rollback changes more than DNS. If the new site has accepted writes, the old database may already be stale. Identify how those new records will be preserved before returning visitors to the source.

Keep the old account active until the destination has passed checks over a representative operating period. The appropriate overlap depends on the site, billing cycle and data risk. Avoid cancelling it simply because the first page request succeeded.

Record what changed and the evidence that the new environment is healthy. That record makes later troubleshooting much easier than trying to reconstruct an undocumented cutover.

Close the migration deliberately

Once the new setup is stable, take a fresh independent backup, verify renewal settings and remove unneeded temporary credentials. Check that the business still controls the domain and all relevant accounts.

Retire the old environment only after confirming there are no remaining mailboxes, redirects, files or scheduled tasks depending on it. Preserve any records required for the business and follow the provider’s cancellation process.

Update the maintenance instructions with the new dashboard, backup routine and support path. A successful migration should leave the site easier to operate, not just hosted somewhere else.

Frequently asked questions