Will my site be down during the move?

For a static or brochure site, the cutover can be unnoticeable — the old host serves visitors until the tested copy takes over. For a site that accepts orders, bookings or uploads, a short read-only or maintenance window during the final data sync is often the honest price of not losing anything; what you're avoiding isn't a pause, it's two systems accepting different data at once.

Do I need to move my email at the same time?

If the mailboxes are hosted elsewhere, leave the MX records unchanged and incoming mail never notices. But still test the email your website sends — contact forms, order and account notifications may depend on a local mail service, SMTP credentials, firewall rules or an authorized sending IP that changed with the host. If mailboxes are bundled with the old host, treat mail as its own migration with an overlap period.

When can I cancel the old hosting?

Only after the new host has served real traffic for a few days with clean logs, verified forms, email and functions — and after taking a fresh backup of the new site plus an archival copy of the old environment. Don't rely on the old access log alone: a CDN can hide visitor traffic from origin logs, and some resolvers serve stale DNS answers past the TTL. Canceling on switch day is the classic way to lose data and serve errors at the same time.

How do you move a website to another host with little or no downtime?

Moving hosts is a copy, a parallel test, and a controlled cutover — of traffic and data. The old host keeps serving visitors while you build and prove the new one, and for a static site the switch can pass unnoticed. A site that accepts orders, bookings, uploads or comments needs one extra plan the static site doesn't: how live changes stay consistent while two copies exist. Skip that plan and you get the migration's ugliest failure — some visitors writing to the old database while others write to the new, with no clean way to merge them afterwards.

Inventory before you copy

List what actually has to move — the surprises live in the second half:

Website files and databases (engine, version, character set), with sizes; the runtime the site needs (language version, extensions, settings).
Server rules and layout: .htaccess/rewrites and redirects, document root, file ownership and permissions.
Moving parts: scheduled jobs, queues and workers, sessions, object caches, temporary storage.
Outbound email: does the site send via a local mail service or SMTP — and will the new host's IP still be authorized by your SPF record and reverse DNS?
Integrations pointing in: webhooks and payment/login callback URLs, external services with IP allowlists, CDN/proxy/WAF configuration.
Search and measurement: Search Console verification, robots.txt and any crawl or index blocks, analytics and error-reporting configuration.
TLS: exactly how certificates will be issued on the new host (below).
Email hosting: mailboxes with the same provider, or elsewhere? This answer sets much of your risk.
Where DNS is managed — a host move does not require moving DNS or the domain (that's a different move).

Take a fresh verified backup before you start, and record the current DNS values — they're your rollback.

Build and test the copy — before DNS changes

Transfer the files, import the database from a consistent export, and test without touching public DNS:

Hosts-file trick: point only your own computer at the new server by adding its IP for your domain — the application sees its real hostname, which keeps cookies, redirects and absolute URLs honest. Know its limits: it doesn't reproduce public DNS, CDN routing, certificate issuance, or third-party callbacks.
Temporary hostnames work too, but they change what the site sees — cookie domains, canonical URLs, payment and login callbacks, CMS-generated absolute URLs — so some failures (and some successes) are artifacts of the test name. CMSs that store their URL in the database may need application-specific handling either way.
Click through pages, forms, logins, uploads; watch the browser console for errors; check the deployment traps — paths, case, permissions.

Sort out HTTPS before the switch, deliberately. How depends on the host's validation method: DNS-based validation can usually issue the certificate in advance; HTTP-based validation may only succeed once the domain actually reaches the new host. Don't assume issuance is instant — agree on the procedure with the new host, cover every hostname (apex, www, subdomains), and check automatic renewal works after the move.

Decide how live data is handled

For a static or brochure site with no visitor-generated data, a final file sync shortly before the switch is enough. For anything that takes writes — orders, bookings, form submissions, accounts, comments, stock, uploads — pick a strategy before cutover:

A brief read-only or maintenance window: freeze writes on the old site, run the final database-and-uploads sync, then switch. Simple, honest, and usually short.
Replication or a shared backend: keep the new copy's data continuously in sync, or let both frontends write to one database until the move completes.
A provider-supported migration, where the host's tooling handles the consistent handover.

What you must not do is let two independent copies both accept live changes — there is no reliable way to reconcile them afterwards. The same rule shapes the overlap period: keep the old host reachable while cached DNS drains, but not a second production system — read-only mode, a redirect, or proxying to the new backend all work; silently accepting orders into the old database does not.

The switch

Lower the TTL on the records that will change — only those — at least one old-TTL period ahead, respecting any provider minimums (how TTL works).
Final sync under your chosen data strategy (for a dynamic site, that's where the read-only window goes).
Change what actually routes web traffic. Depending on the setup that's A/AAAA records, a CNAME, an apex-alias, or just the origin setting at your CDN or proxy — don't convert record types unnecessarily, and don't touch MX or unrelated TXT records.
Keep the rollback real: old DNS values recorded, old environment unchanged, and a pre-agreed trigger for going back. Remember rollback isn't instant either — cached answers flow both ways, and once the new system has accepted real orders, reverting to the old database loses them. Roll back early or not at all.

Verify, then decommission

Query several independent resolvers (IPv4 and IPv6 where configured); crawl the live site and check statuses, redirects and canonical URLs; submit the forms and confirm delivery; test login, checkout, uploads and scheduled jobs; verify outbound email still authenticates (SPF/DKIM in the received headers); watch Search Console and your monitoring; and read both hosts' logs — remembering a CDN can hide visitor traffic from the origin log, so its silence proves less than it seems. Then take a fresh backup of the working new site, keep an archival copy of the old environment, and only then cancel. Restore normal TTLs and update your account inventory.

The old and new environments should overlap — but they must never become two independent places accepting different data. Build first, test thoroughly, synchronize the final changes, switch deliberately, and retire the old host only after the new system and the way back have both been proven.

What to do

Inventory the full environment — files, database, runtime, server rules, jobs, outbound email, callbacks, TLS plan — and back it all up.
Build the copy and test it via your hosts file or a temporary hostname, knowing what each method can't show.
Decide the live-data strategy: final-sync-only for static sites; read-only window, replication or shared backend for anything that takes writes.
Lower only the relevant TTLs ahead of time; agree on the HTTPS issuance procedure with the new host.
Switch what routes web traffic, leave MX alone, and keep the old environment reachable but not writable.
Verify function, email authentication and search access; back up the new site; archive the old one; then cancel.