Skip to content
Getting Digital
All hosting guides

Migrating a site without downtime

Moving hosts is routine, not surgery — if you respect the one rule: the old site keeps running until the new one is proven. The sequence, step by step.

Affiliate disclosure: this guide mentions hosting partners; the partner links are affiliate links that may earn us a commission at no extra cost to you. The advice stands either way.

Hosting migrations have a scary reputation they no longer deserve. The modern reality: sites move constantly, receiving hosts actively help (free migration is a standard acquisition offer — ask for it), and the whole discipline reduces to one principle. Never turn anything off until its replacement is verified. Everything below is that sentence, unpacked.

The sequence

  1. Inventory first — the site's files and database, yes, but also the easy-to-forget residents: email accounts (MX records are independent of the website — the classic migration casualty), subdomains, cron jobs, TLS needs, forms that send mail.
  2. Build in parallel — set up the complete site on the new host while the old one serves traffic undisturbed. Copy files, import the database, configure the web server and TLS certificate.
  3. Test against the new server directly — before any DNS change, point your own machine at the new host (a hosts-file entry does it) and click through the real site: pages, forms, admin, checkout if you have one. This step is the whole difference between migration and gambling.
  4. Drop the DNS TTL — a day or two ahead, lower the relevant records' TTL so caches expire fast. This shrinks 'propagation' from a feared day to minutes.
  5. Freeze, sync, switch — for dynamic sites: briefly stop content changes (or put the store in maintenance), run a final database sync, then repoint DNS. The old server keeps answering stale caches; the new one takes fresh traffic. Nobody sees an outage.
  6. Verify, then linger — confirm the new site serves on the real domain, certificates valid, forms and email flowing. Keep the old hosting alive for a week or two as the world's cheapest insurance — rollback is one DNS change while it exists.

What actually goes wrong

  • Email dies — the site moved, MX records got 'cleaned up' with it. Web and mail are independent; touch only what's moving.
  • Hardcoded old paths — absolute URLs or server paths baked into config or database. WordPress migration tooling handles this; custom sites need a search.
  • The certificate gap — the new host serving HTTPS without a valid certificate at switch time. Issue it before DNS moves, not after.
  • Nobody dropped the TTL — the switch works, but old caches serve the old server for hours. Harmless if it's still running (rule one!), confusing if it isn't.

Let the receiving host do it

Managed hosts migrate incoming sites as a matter of course — Cloudways and Liquid Web both treat it as onboarding, not a favor. Your job shrinks to the inventory, the testing and the DNS switch: exactly the parts that need your knowledge of the site.

Our picks for this path

Cloudways

Sites that have outgrown shared hosting but don't want to adopt server administration as a hobby.

Liquid Web

Business-critical sites and WooCommerce stores where downtime costs real money and support must answer.

Quick answers

Will migrating hurt my Google rankings?

A same-domain host move is invisible to search engines — same URLs, same content, new IP address, which they handle constantly. Ranking risk lives in domain or URL-structure changes, which are a different project with their own redirect discipline. Keep the domain and structure, and SEO is a non-issue.

How long does a migration take?

Calendar time: a few days, dominated by deliberate waiting (TTL lowering, the verification linger). Working time for a typical site: hours, most of them testing. The visitor-facing downtime, done right: none.

When is downtime actually unavoidable?

Almost never for the visitor-facing site. The honest exception is write-heavy applications during the final data sync — stores and forums briefly freeze new writes so no order or post lands only on the old server. That's minutes of maintenance mode at a chosen quiet hour, not an outage.