How to move your website to a new host without downtime

What moving a host is, and what it isn’t

Moving a website to a new host means a different service builds and serves the site. The domain stays at the same registrar. DNS stays with the same provider. At the end, one or two DNS records point at the new host instead of the old one, and that is the entire visible change.

It’s worth being precise because hosts often bundle offers into the setup flow: register the domain with us, move your DNS to us, use our nameservers. None of that is required to move hosting, and each one adds risk to what should be a small change. If you do want to transfer the domain or move DNS as well, do them as separate jobs, on separate days, using the transfer guide and the DNS guide.

This guide assumes the site’s code is in a repository you control and that the new host deploys from it. If it isn’t yet, start with putting the code in GitHub. If you’re not sure what the current host even is, the diagnostic finds out.

What “downtime” actually means here

During a host move there are three ways visitors can be let down, and only one of them is unavoidable.

• The site is down. The domain points at a host that isn’t ready, or at nothing. This is entirely avoidable: you don’t change DNS until the new host is serving the site.
• The site is up but wrong. The new host is serving, but a form doesn’t submit, sign-in fails, images are missing, or a page that used to redirect now 404s. This is what “reproduce the configuration” prevents, and it’s the usual failure.
• Some visitors see the old site and some the new. This is DNS caching, it lasts as long as the TTL on the records you changed, and it’s harmless as long as the old host keeps serving the site until it’s over.

So “no downtime” means: both hosts serve a working site during the switch, and the only thing that changes is which one a given visitor lands on.

Step 1: Inventory the current setup

Before creating anything on the new host, write down what the old one does. Open its dashboard and record:

• The repository and branch it deploys from, and the build command and output folder if they’re shown.
• Every environment variable, by name. Values too where they’re readable; where they aren’t, note which service issued them. The environment variables guide explains how to trace each one.
• The domains attached to the project: the bare domain, www, and any subdomains.
• Redirects and rewrites configured in the host’s dashboard rather than in the code. Old URLs that still get traffic depend on these.
• Host-specific features the site uses: the host’s own form handling, image optimisation, serverless functions, cron jobs, analytics, a database or file storage the host provides. Each of these has to exist on the new host or be replaced.
• Custom headers, password protection, or geo rules, if any.

Then open the DNS provider and export or screenshot every record, as the DNS guide describes. Note which records point at the old host, because those, and only those, are the ones that will change.

Step 2: Prepare the new host

1. Create the account in your own name, with your email and 2FA. If the site belongs to a business, create a team and make yourself an owner.
2. Create a project and connect it to the repository and branch from your inventory. Vercel, Netlify and Cloudflare all deploy straight from a GitHub repository, and there’s a walkthrough for each: Vercel, Netlify, Cloudflare.
3. Let the first build run and fail if it wants to. A failed build at this stage costs nothing; the domain still points at the old host.

Step 3: Reproduce the configuration

Work through the inventory and recreate each item on the new host:

• Enter every environment variable, in the environment the host calls production. Where a value can’t be read from the old host, generate a new one at the issuing service, or decide that this is the moment to rotate it anyway.
• Recreate redirects and rewrites, or move them into the code so they travel with the site next time.
• Replace host-specific features with the new host’s equivalent or with a third-party service. Forms are the usual one: a form that posted to the old host’s form handler needs a new destination.
• Set the build command and output folder if the host didn’t detect them.

Rebuild until the build succeeds. Then stop: the site exists on the new host, at the host’s own address, and nothing public has changed.

Step 4: Deploy and verify on the host’s own address

Every host gives a project a working address of its own, such as yourproject.vercel.app, yourproject.netlify.app, yourproject.pages.dev or yourproject.workers.dev. Use it to test the whole site before the domain is involved:

Some features can’t be fully tested until the real domain is attached, for example a sign-in provider that only allows callbacks to the real domain, or an email service that only sends from it. Note those; they’re the first things to check after the switch.

Add the domain to the new host’s project now. The host will show you the exact DNS records it wants, and will say the domain isn’t yet pointing at it. That’s correct; don’t change anything yet.

Step 5: Lower the TTLs

At the DNS provider, find the records that point at the old host, usually an A or AAAA record at the bare domain and a CNAME at www. If their TTL is long, lower it to a few minutes (Vercel suggests 60 seconds, Cloudflare 300) and then wait at least as long as the old TTL was. That drains the caches that remembered the long value, so that when you change the records, most visitors switch within minutes. Skip the wait if the TTL was already short.

Step 6: Change the website records

This step has its own guide, connecting a domain without breaking email, which covers each host’s domain screen and the conflicts they throw up. The short version:

1. Edit the A or AAAA record at the bare domain to the value the new host gave you. If the host asks for an ALIAS or flattened CNAME at the root instead, use that only if your DNS provider supports it; otherwise use the A record.
2. Edit the CNAME at www to the new host’s value.
3. Edit any subdomain records that belong to the site being moved. Leave subdomains that belong to other services alone.
4. Save. Don’t change nameservers, and decline any offer to “use our DNS”.

Step 7: Verify the apex, www and HTTPS

Within a few minutes, the new host’s dashboard should show the domain as verified or valid. It then requests an HTTPS certificate for it. Vercel, Netlify and Cloudflare all issue certificates automatically, and all of them can only do so once they can see that DNS points at them. Cloudflare says to allow between 15 minutes and 24 hours; Vercel and Netlify don’t give a figure. Until it’s issued, some visitors may see a certificate warning, which is the one part of the switch you can’t make instant, so don’t announce anything until it has cleared.

If the certificate stays pending for hours, check for a CAA record in your DNS. A CAA record restricts which authorities may issue certificates for the domain, and if one exists it must include the authority the new host uses. Vercel, for example, uses Let’s Encrypt and documents the exact CAA record to add. Also check that no leftover record at the old host is still answering for the name.

If any of those checks fails, don’t roll back yet; the cause is usually one of a short list. See website not showing after a DNS change, www works but the bare domain doesn’t and HTTPS not working.

Step 8: Keep the rollback open, then close it

Rolling back is the same two-record edit in reverse: set the A and CNAME back to the old host’s values. With the TTL still at a few minutes, that takes effect almost as fast as the switch did. This works only while the old host is still serving the site, so leave it running for a week or two, with its domain settings intact.

Hosts also let you roll back within the new host, to a previous deployment, which covers the other kind of problem: a bad build rather than a bad move. Vercel calls this Instant Rollback, and on its free plan it reaches only the immediately previous deployment; Netlify lets you publish any earlier deploy; Cloudflare Workers keeps the last hundred versions. Find the button before you need it, and read what it does to automatic deploys afterwards: Vercel stops assigning new deployments to the production domain until you undo the rollback, and Netlify’s next Git-triggered deploy overwrites the rolled-back version.

When you’re satisfied, close the move out:

1. Raise the TTLs on the changed records back to something normal, such as an hour.
2. Remove the domain from the old host’s project, then the project itself, then close the account or remove its payment method.
3. Update your record of where the site is hosted, and the list of environment variables, to point at the new host.

Checklist

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Adding a custom domain · Vercel
• A record and CAA with Vercel · Vercel
• Managing DNS records · Vercel
• Working with SSL · Vercel
• Domains troubleshooting · Vercel
• Deploying and redirecting domains · Vercel
• Instant Rollback · Vercel
• Configure external DNS for a custom domain · Netlify
• HTTPS (SSL) · Netlify
• Manage deploys · Netlify
• Custom domains for Workers · Cloudflare
• Rollbacks · Cloudflare
• Enable Universal SSL · Cloudflare
• Record TTL · Cloudflare
• DNS best practices: lower TTLs before a migration · Cloudflare