A website hosting migration usually gets put off for years. The current host is slow or expensive or run by someone who left the company, but the site works, and nobody wants to be the person who took it down. The good news is that a well-run move does not require downtime at all. The site keeps serving from the old host until the new one is proven, and the switch itself is a DNS change that visitors never notice.

We recently moved our own site, shiptronix.com, from an older static host to Cloudflare, along with the DNS and a set of old domain redirects that had been sitting on a third-party redirect service. This article lays out the approach we use for ourselves and for clients, in the order we do it.

The core idea: build in parallel, switch with DNS

The single most important principle is that you never take the old site down to build the new one. You stand up the new hosting next to the old, get it fully working on a temporary address, and only then point the domain at it. Until that last step, the public sees the old site. After it, they see the new one. If something goes wrong, you point the domain back.

That means a migration has three phases:

  1. Prepare: inventory what exists today and decide what the new setup looks like.
  2. Build and test: get the site running on the new host, on a staging address, and test it properly.
  3. Cut over: change DNS, watch closely, and keep the old host alive until traffic has fully moved.

Phase 1: Know what you are moving

Before touching anything, write down what the current site actually depends on.

  • Pages and URLs. Export a full list from your sitemap, your analytics and Search Console. Every URL that gets traffic or has inbound links needs to exist on the new site or redirect to its replacement.
  • Forms. Where does each form send its data? Many older sites rely on a host-provided form handler or a PHP mail script that will not exist on the new host.
  • Redirects. Check for redirect rules in the host's control panel, an .htaccess file, a plugin, or a separate redirect service. Old campaign URLs and retired domains often live here.
  • Other domains. Many businesses own several domains that point at the main site. Each one needs a plan.
  • Tracking and scripts. Analytics, tag manager, ad pixels, chat widgets and verification files.
  • SSL certificates. Who issues them today, and how will the new host issue them?
  • DNS. Who hosts it, and what records exist besides the website? Mail records live in the same zone and are easy to damage in a move. Our guide to DNS migration to Cloudflare covers this part in detail.

Phase 2: Build and test on staging

Get the new site running on a temporary address first. Most modern hosts give you one automatically, and on Cloudflare we run a separate staging Worker for this purpose.

Two things matter here.

First, keep staging out of search engines. A staging copy that gets indexed competes with your real site and can leak unfinished content. Our staging Worker sends an X-Robots-Tag: noindex header on every response until launch. Password protection works too. Whatever you use, make sure it is removed from production. Google's site move guidance specifically calls out removing noindex rules or crawl blocks that were only meant for the migration.

Second, test like a visitor, not like a developer. Click through every main page. Submit every form and confirm the message arrives where it should. Check the site on a phone. Load a few old URLs and confirm they redirect to the right place with a single permanent redirect, not a chain.

A short test list we run on every move:

  • Every page in the URL inventory returns a 200 or a single 301 to its replacement
  • Every form submits and delivers
  • Analytics and tag manager fire on the new host
  • Images, downloads and PDFs load
  • The site renders correctly on mobile
  • Page titles, meta descriptions and canonical tags carried over
  • The robots.txt file allows what it should

Phase 3: Prepare DNS for a fast switch

The cutover is a DNS change: the record for your domain (and www) moves from the old host's address to the new one. How fast visitors follow depends on the record's TTL (time to live), which tells resolvers how long they can cache the old answer.

If your website record has a TTL of a day, some visitors could keep reaching the old host for up to a day after you make the change. So a day or two before cutover, lower the TTL on the records you plan to change to something short, such as 300 seconds (five minutes). Wait at least as long as the old TTL so caches pick up the new, shorter value. Then, when you switch, most of the world follows within minutes.

One caution: if the move also involves changing nameservers (moving your whole DNS to a new provider), that is a separate and slower change controlled by your registrar and the domain's top-level registry. We recommend doing the DNS provider move first, letting it settle, and then switching the website as a second step. Changing both at once makes it hard to tell which change caused a problem.

Cut over, then watch

On launch day, make the DNS change during a quiet period and stay at the keyboard for the next hour.

  1. Update the A, AAAA or CNAME records for the root domain and www to point at the new host.
  2. Confirm the new host has issued a valid SSL certificate for both. Some hosts cannot issue a certificate until DNS points at them, so expect a short window here and check it immediately.
  3. Load the site from a few networks, including a phone off Wi-Fi, to see the change from outside your office.
  4. Submit each form one more time on the live domain.
  5. Watch for 404 errors in your host's logs or analytics over the next few days and add redirects for anything you missed.
  6. In Google Search Console, submit the new sitemap and keep an eye on the coverage and page indexing reports.

Do not cancel the old host yet. Keep it running and unchanged for at least a couple of weeks. If something serious turns up, you can point DNS back to it within minutes because your TTL is still low. Once things are stable, raise the TTL back to a normal value and then retire the old host.

Redirects and old domains

Redirects deserve their own attention because they protect both visitors and search rankings. Google recommends server-side permanent redirects (301 or 308) from each old URL directly to its final destination, avoiding chains, and keeping them in place for as long as possible, generally at least a year.

For retired or secondary domains, we prefer handling redirects at the edge rather than through a separate redirect service. In our own move, we replaced a third-party redirect service with redirect rules in Cloudflare, so all the domains are managed in one place and nobody has to remember a separate login. If you are moving a site to a new domain entirely, Google's Change of Address tool in Search Console helps signal the move. It applies to domain and subdomain changes, not to moves within the same domain.

Where people get caught out

The problems we see most often are not exotic:

  • Email stops working because mail records were not recreated when DNS moved.
  • A contact form silently stops delivering because it depended on the old host's mail function.
  • The staging noindex header ships to production and the site drops out of search.
  • Old URLs return 404 because nobody built redirects.
  • A secondary domain still points at the old host and breaks when the old host is cancelled.
  • Domain or DNS verification records for tools like Search Console or Microsoft 365 were not copied over, and a service quietly loses verification.

Every one of these is preventable with the inventory in Phase 1 and the test list in Phase 2. Our website migration checklist turns this into a printable list.

When to bring in help

Plenty of teams can handle a simple brochure site move themselves with the plan above. It is worth getting help when the site has many URLs with search traffic, the domain also carries business email, there are several domains and redirect rules in play, or nobody on staff knows how the current setup was built. That is exactly the work our website hosting and migration service covers, from inventory through cutover and the follow-up week.

Frequently asked questions

How long does a website hosting migration take?

For a small business site, the build and test phase is usually days, not weeks, and the cutover itself takes minutes once TTLs are lowered. Larger sites with many URLs, forms and integrations take longer mainly because of the inventory and testing work, which is where the time should go.

Will moving hosts hurt my search rankings?

A host change on the same domain with the same URLs is usually invisible to search engines. Rankings are at risk when URLs change without redirects, when a staging noindex rule reaches production, or when the site is slower or broken after the move. Plan redirects, remove staging blocks and test before switching.

What TTL should I set before a migration?

A common choice is 300 seconds (five minutes) on the records you will change. Lower it at least one full old-TTL period before the cutover so resolvers have picked up the shorter value. Raise it again once the new setup is stable.

Should I cancel my old hosting right after the switch?

No. Keep the old host running for at least a couple of weeks. It is your rollback path, and it also serves any visitors whose resolvers are still caching the old address. Cancel only after traffic, forms and email have been confirmed on the new setup.

Can I move my website and my DNS at the same time?

You can, but we do not recommend it. Moving DNS providers involves a nameserver change that can take up to a day or more to settle. Move DNS first with the website records still pointing at the old host, confirm everything works, then switch the website records as a separate step.