How to Migrate a Website with Minimal Downtime

The safest hosting move is one you can test before visitors depend on it. Build a working copy on the new host, decide how to handle changes made during the move and keep a way back.

Some sites can move with no visible interruption. An active shop or membership site may need a short pause in writes or a more advanced replication plan. Keeping two independent copies online does not, by itself, prevent lost orders or conflicting updates.

Define what is changing

This guide focuses on moving to another host while keeping the same public domain and URLs. A domain change, a new URL structure or a new content-management system introduces additional work. Record those changes separately rather than combining them casually with a hosting transfer.

List the website files, database, email service, scheduled jobs, DNS records, external integrations and certificates. Agree who will perform the move and who will decide whether to roll back.

Prepare a recoverable starting point

Take a complete backup and keep it outside the hosting account you are moving. Confirm that you can restore it, not merely download a backup file. Save the current DNS configuration and the details needed to operate the old service.

Check the new environment’s compatibility with your application. Avoid combining the move with unrelated theme, plugin or runtime upgrades unless they are necessary and tested. Changing several things at once makes a failure harder to diagnose.

WordPress publishes an official migration guide. Its instructions distinguish keeping the same URLs from changing them. Use a method appropriate to your installation, especially for multisite or a custom setup.

Build the copy before changing DNS

Use the new host’s supported migration process, a suitable migration tool or an administrator’s file-and-database transfer procedure. Keep credentials out of public files and avoid leaving installation packages accessible after the move.

For WordPress, the files and database must correspond, and the configuration must point to the correct database. If URLs change, use a method that handles WordPress data safely. A blind text replacement across a database can damage serialised settings.

Test using the real hostname where possible

Ask the new host for a supported preview method. A local hosts-file override can route your own computer to the new server while other visitors still use the old one. Remove the override when finished. Confirm which server you are testing, and check HTTPS without dismissing certificate errors.

Test representative pages, media, permalinks, search, logins and forms. For a shop, use the payment gateway’s test mode and verify order processing, callbacks and mail. Keep preview testing from sending duplicate customer messages or running production jobs twice.

Plan the final data transfer

For a largely static publication, a brief editorial freeze may be enough. For a transactional site, agree how writes will be paused, replicated or routed to one authoritative system during cutover. Include uploads, orders, registrations, comments and background tasks.

Take the final consistent copy after the agreed freeze, apply it to the new environment and verify it. Do not allow two independent databases to accept changes unless you have a tested reconciliation design.

Change the necessary DNS records

Lowering the relevant DNS record’s TTL ahead of time can reduce how long an old answer remains cached. It does not instantly clear existing caches, and changing nameservers is different from changing a website’s address records. Follow the DNS provider’s instructions for the planned change.

Preserve records for mail and other services. If the domain uses DNSSEC, coordinate any nameserver or signing changes with the DNS provider. The TTL explanation covers the role of caching; our DNS guide explains the surrounding records.

Verify the public result

• Check the site from more than one network and confirm requests reach the intended server.
• Verify HTTPS, redirects, important URLs, canonical tags and any access restrictions.
• Test incoming and outgoing mail, forms and required third-party integrations.
• Review errors, application health and representative performance.
• Confirm backups and scheduled jobs run in the intended environment.

A host-only move does not automatically require new page URLs or redirects. Google’s guidance for hosting changes explains the checks for that situation. Preserve crawl access and avoid accidentally carrying a preview site’s indexing restrictions into production.

Keep the old service until the move is stable

Retain the old environment for a period appropriate to the DNS change and the site’s risk. Keep it from accepting conflicting writes. Record the exact conditions that would trigger rollback.

If the new site has already accepted orders or other changes, pointing DNS back is not a complete rollback: you must account for that new data. Resolve the data state before reopening the old application.

Once operation and recovery are verified, retire the old service deliberately. For performance comparison after the move, use the same pages and test conditions described in our website speed guide.