How to Move a Website to a New Host Without Downtime

A website move has two risks. The first is that the new server is not ready, so visitors reach a broken site. The second is that visitors reach the old server after you think you have switched, so changes made on the new server are lost. A careful plan handles both. It keeps the old server answering until the new one has been checked, it switches DNS in a window you chose, and it keeps a way back if the new server fails.

Test the new server before you change DNS. Open the free preview tool

This guide covers the whole move, from the inventory to the day after the switch. The steps are the same whether you move a site from one shared host to another, from a cPanel account to a VPS, or from a DirectAdmin reseller account to a new server. The detailed checks for the preview step are in the preview guide.

"Without downtime" describes the plan you aim for. No plan can promise that a visitor never sees a problem. What you can control is the number of things that can go wrong at the switch, and how fast you can reverse the switch if one does.

Step 1: Inventory what the site needs

Write down everything the site uses. A missed item is the most common cause of a failed move.

Files. The web root, uploads, and any folder outside the web root that the site reads.
Databases. Each database and each database user, with the name and host of the server they connect to.
Email. Mailboxes, forwarders, autoresponders, and the MX, SPF, DKIM and DMARC records.
Scheduled jobs. Cron jobs and any task that sends mail or writes files.
Certificates. Each domain and subdomain that needs HTTPS, and how the certificate is issued and renewed.
Third-party services. Payment providers, webhooks, analytics tags and login providers that store your domain name or callback address.
DNS records. Every A, AAAA, CNAME, MX and TXT record in the zone.

The migration checklist generator builds a list like this for your hosts and panels. Use it as a starting point, then check the list against your own site.

Step 2: Lower the DNS TTL in advance

The TTL controls how long resolvers keep the old answer. Set a short TTL on the records you will change, and wait for the old, longer TTL to run out before the switch. The TTL field is "the time interval that the resource record may be cached before the source of the information should again be consulted" (RFC 1035, section 3.2.1). A resolver that fetched the record with the old TTL keeps it until that TTL expires, so the lowered TTL only helps after every resolver has fetched the short one.

The sequence is:

Note the current TTL on each record you will change.
Lower the TTL to a short value, for example 300 seconds, at least as early as the old TTL.
Wait at least as long as the old TTL.
Make the change on the switch day.

This step makes the switch faster and makes a rollback faster. The DNS side of the timing is explained in what DNS propagation is and why the change takes time. A short TTL cannot shorten the wait for a resolver that already holds a long one, so start early.

Step 3: Copy the site to the new server

Copy the files and the databases. Check the new server's PHP or application versions, database versions and file permissions before you copy, and fix mismatches before the first test. A copy that works on the old server can still fail on the new one because of a missing extension, a different database setting or a path that points to the old host.

Test the copy against the new server's IP address before you change DNS. The preview method keeps the domain name in the request, so the server answers as it would after the switch. The preview guide describes the three ways to do this: a preview URL, a hosts-file entry, and curl --resolve.

Set the site's configuration to use the domain name, and check that it does not still point to the old host. Some applications store the site address in a settings table, and a copy of that table carries the old address with it.

Step 4: Preview and test the new server

Run the checks on the preview before you move anything live. Group them by type.

Technical checks

HTTPS. Check the certificate on the new server. It must cover the domain, and the chain must be complete. The SSL checker shows the certificate details for a domain.
Redirects. Check that http:// goes to https://, that www and the bare domain go to one address, and that old URLs return the right codes. The server diff tool compares the old and new servers for these checks in one scan.
Caching. Check that the new server sends cache headers similar to the old server. The cache checker shows the headers for a URL.
Mixed content. A page on HTTPS that loads a resource over HTTP shows a warning in the browser.

Functional checks

Sign-in. Log in, log out and reset a password on the preview.
Forms. Send a test form and check that the message arrives.
Payments and callbacks. Check each callback address in the payment and webhook settings. These are often set to the old domain, and they need a change on the provider's side as well as on your server.
Background jobs. Run each cron job once on the new server, and check that it does what it should without sending duplicate messages.

Write down each failure, fix it, and run the check again on the preview. Do not switch DNS while a check fails, unless you know why it fails and you have a plan for it.

Step 5: Plan certificates for the switch

A certificate authority checks control of the domain before it issues a certificate. For HTTP-01 validation, "The HTTP-01 challenge can only be done on port 80" (Let's Encrypt, challenge types). The check reaches the server that public DNS points to. Until you switch, that is the old server, so a certificate for the new server may not issue on the preview.

You have two choices:

Issue the certificate after the switch. Until it issues, the new server may serve no valid certificate for the domain. Plan for that gap, or install a certificate you already hold for the domain before the switch.
Use the DNS-01 challenge, which "asks you to prove that you control the DNS for your domain name by putting a specific value in a TXT record under that domain name" (Let's Encrypt, challenge types). It does not depend on which server answers port 80, but it needs a way to change TXT records during the move.

Check which method your panel uses, and plan the switch around it.

Step 6: Move email before you change MX records

Email depends on DNS in a different way from the web. Mail goes to the MX records. If you change the MX records before the mailboxes exist on the new server, mail can bounce or wait.

Copy the mailboxes to the new server, and check the mail login.
Check the SPF, DKIM and DMARC records, and keep them in place. A change that drops the sending servers from SPF can cause mail to fail checks at other servers.
Change the MX records when the mailboxes are ready, and check that mail arrives.

The email DNS checker shows the mail records for a domain. Plan the mail move as a separate change with its own checks.

Step 7: Choose the cutover window

Choose a window when traffic is lowest for your site, and when you can watch the switch. Avoid a time when you cannot reverse the change if something goes wrong. Tell the people who depend on the site, and name the person who makes the call to roll back.

Before the window, make a final copy of the database and files. Plan how changes made on the old server during the copy will reach the new server. Options include a short write freeze, a final incremental sync, or a plan to accept a small amount of data entered in the last minutes. Pick one and write it down.

Step 8: Switch DNS and check the live domain

Change the A record (and the AAAA record, if you use IPv6) to the new server's address. Change the records for each subdomain that serves the site. Then:

Check the records at your DNS host and at the registrar, if the registrar holds the nameservers.
Run the DNS propagation checker at the start, after an hour, and the next day.
Load the live domain from more than one network, and check the home page, the login and a key form.
Read the logs on the new server for errors, and watch for 404s and 500s on the first hour of traffic.

The check on the live domain matters more than the preview check. Some problems only appear when real traffic reaches the server. The server diff tool helps here as well, because it can compare the old and new servers during the change.

Step 9: Keep the old server running

Do not shut down the old server on the day of the switch. Some visitors will reach it during the TTL window, and some resolvers will keep the old answer longer than you expect. Keep the old server serving the site, or a redirect to the new one, until the old address has stopped receiving traffic. Then take the old site down in a planned step, and keep a backup for a set period.

If the old server receives writes during this period, make sure those writes are not lost. A visitor who submits a form on the old server during the window needs that submission on the new server.

Step 10: Plan the rollback

A rollback is a DNS change back to the old address. It is quick if you planned for it. Before the switch, write down:

the old A and AAAA records, and the TTL they carry;
the person who makes the rollback call, and the signal that triggers it, such as a failed login or a broken checkout;
how writes made on the new server during the window would reach the old server, if you roll back after they happen.

The short TTL from step 2 also helps the rollback. A resolver that fetched the new address with a short TTL refreshes quickly after you change the record back.

Control panels: cPanel, WHM and DirectAdmin

Many moves run through a control panel. The cPanel plugin and DirectAdmin plugin add a preview step to the migration workflow, so you can test the new server before the switch from inside the panel. For the panel-specific steps, read these posts:

The cPanel preview URL plugin and the DirectAdmin preview URL plugin have their own pages with the setup steps.

Common mistakes

Changing the TTL on the day of the switch. The old TTL still governs the old answers.
Leaving an AAAA record that points to the old server. IPv6 visitors can keep reaching the old server.
Forgetting a subdomain. A www, mail, api or cdn record may still point to the old address.
Moving the web before the mail. Mailboxes need to exist before the MX records change.
Shutting down the old server too early. Some visitors and resolvers still use the old address.
Losing writes during the copy. Plan the final sync before the switch.
Trusting one network's view. Test the live domain from more than one network.

After the move

Keep watching for a week. Check the error logs each day, check the search console for crawl errors, and check the forms and payments. If a page breaks, fix it on the new server, and check it again on the live domain.

Update your records after the move. Set the TTL back to your normal value once the move is stable, and remove the entries you added to a hosts file or to a test configuration. Keep the migration plan with the date and the outcome, so the next move starts from it.

Related guides

Sources

Both fetched 2026-10-28, HTTP 200.