Moving a client site to a new host without downtime

A bakery's website has lived for years on a hosting account a previous designer set up. The renewal notice arrives, the price has gone up, and the bakery asks you to move it somewhere better. The owner has one worry: "It won't go down, will it? Saturday is our busiest day for cake orders."

It doesn't have to, and for a one-person AI agency a quiet move is part of the care work. A website goes offline during a move when the old host is switched off before the new one is ready, or when a change reaches the wrong records. Both are avoidable.

Here's the short version. Set the site up on the new host and test it there while the old one keeps running. A day or two before the switch, lower the DNS time-to-live so the change spreads quickly. On the day, change only the records that point to the website, and leave the email records alone. Then check everything, and keep the old host running for at least a week.

How do I move a website without it going offline?

In this order:

1. Get access to the domain, the DNS and both hosting accounts.
2. Write down every DNS record as it is today.
3. Copy the site to the new host.
4. Test it on the new host before anyone else can see it.
5. Lower the TTL on the website's records a day or two ahead.
6. Switch the website records at a quiet time.
7. Check the site, the certificate, the forms and the email.
8. Keep the old host running for a week, then cancel it.

The rest of this guide explains each step and the two places moves usually go wrong: email and the security certificate.

What do I need before I start?

Access, and a record of how things are today.

Access to the domain and DNS. The domain is registered somewhere, and its DNS (the address book that tells the internet where the website and email live) is managed somewhere, often the same place. You need to be able to edit it. Ideally the account is in the bakery's name and you're added as a user, rather than the login being passed around; owner-held accounts explains why that matters most at moments like this.

A copy of every DNS record. Take a screenshot or export of the full list before you touch anything. It's your way back if something goes wrong.

The site itself. All the files, and the database if the site has one. Check the copy opens.

Where the email lives. Find out whether the bakery's email is with the old host, with the domain company, or with a separate provider such as Google or Microsoft. This decides how careful you need to be on switch day.

If the move is part of a bigger change, such as deciding whether to host client websites as an agency or hand hosting to the client, settle that first. Moving twice is twice the risk.

Why does a DNS change take time?

Because computers around the internet remember DNS answers for a while instead of asking every time. How long they keep them is set by each record's time-to-live, or TTL.

Cloudflare's documentation puts it plainly: the TTL controls how long each record is cached, and a longer TTL means updates to your records take longer to reach your visitors. If the bakery's website record has a TTL of a day, some visitors could keep going to the old host for up to a day after you switch.

So lower it first. A day or two before the move, set the TTL on the website's records to a few minutes. Then wait at least as long as the old TTL, so every copy of the old, long setting has expired. When you switch, the change reaches most people quickly. You can raise the TTL again once the move has settled.

How do I test the new site before switching?

While the domain still points at the old host, the public can't see the new copy, which is exactly what you want. Most hosts give a temporary address or preview link for a new site. Use it to check:

• every page opens and looks right, on a phone and a computer;
• images, fonts and downloads load from the new host, not from the old one;
• the contact form and any booking link send to the right place;
• nothing in the site's settings still has the old host's address in it.

If the host doesn't give a preview link, a developer can point their own computer at the new host by editing a small local file (the hosts file). Only your computer sees the change, so you can view the site at its real address before the switch.

The website QA checklist is a good list to work through here, because a move is a kind of relaunch.

What about the client's email?

Leave it alone. Email is controlled by its own DNS records, called MX records, plus a few text records that help mail get delivered. A website move only needs the records that point to the website, usually one or two.

The risk comes when the move also changes who runs the DNS, for example moving the whole domain's DNS to the new host. Then every record has to be recreated at the new provider before the switch, including the email ones. Compare the new list against your screenshot, line by line, before you change anything at the registrar.

If the email was hosted by the old web host, that's a separate move. Do it on a different day, with its own plan.

What happens to the security certificate?

The padlock in the browser comes from a security certificate for the domain, and the new host needs its own. Many hosts get one automatically from a free provider such as Let's Encrypt.

There's a catch worth knowing. Let's Encrypt's most common check, the HTTP-01 challenge, works by placing a file on the web server at the domain's address and looking for it there. That means the new host often can't get the certificate until the domain points to it, which can leave a short window where visitors see a warning. Two ways to avoid it:

• Ask the new host whether it can issue the certificate before the switch. Some can.
• Use a DNS check instead. Let's Encrypt's DNS-01 challenge proves control of the domain with a record in DNS, so it can work before the website moves. It's harder to set up and works best when the DNS provider supports automated updates.

Either way, switch at a quiet time and check the padlock straight after. And while you're setting up the new host, make sure renewals are automatic. Let's Encrypt announced in December 2025 that its certificates will get shorter over the coming years, which makes manual renewal a poor habit; the Let's Encrypt 45-day opt-in covers what that means for a care plan.

What should I check on switch day?

Pick a quiet time. For the bakery, that's a Monday evening, not a Friday.

When	What to do	What you're checking
Before	Confirm the TTL was lowered long enough ago	The change will spread quickly
Switch	Change the website records to the new host's address	Only the website records changed
Straight after	Open the site on a phone using mobile data, not your Wi-Fi	Visitors reach the new host
Straight after	Check the padlock and the certificate	No browser warning
Within the hour	Send a test through every form and booking link	Messages arrive where the client expects
Within the hour	Send an email to the business and ask them to reply	Email still works both ways
Next day	Check again, and check the old host's visitor logs	Traffic has moved across

What do I do after the switch?

Wait before you tidy up. Keep the old host running for at least a week, in case some visitors are still reaching it or something turns out to be missing. Then:

• download a final copy from the old host and keep it;
• cancel the old hosting, and remove any login you no longer need;
• raise the TTL back to a normal value;
• write down the new host, who owns the account, and where the certificate comes from.

That last note belongs in the client's records and in their handover pack. If your agent did the build or the move, the notes you'd give when you hand over website files to the client are the right place for it. Building, reviewing and delivering client websites covers where the site's versions and notes live.

The bakery took cake orders all Saturday. Nobody noticed the move, which is the point.