By the HostScope Editorial Team · Updated June 2026 · Researched from authoritative sources. General information, not professional advice.
Moving a website to a new host sounds risky, and done carelessly it is: visitors hit error pages, forms stop sending, email bounces. But the fear is mostly about downtime, and downtime is almost entirely avoidable. The trick is to build the site on the new server completely, test it there in private, and only then flip the switch that the public sees. This guide is a sequenced playbook for a near-zero-downtime move, with the order that keeps your live site online the entire time.
The good reasons to migrate are concrete: chronic slowness or downtime that support can't fix, a renewal price that no longer matches the value, hitting resource limits you can't upgrade past, or outgrowing shared hosting for a VPS or managed plan. The bad reason is a single frustrating week, every host has those. Before you commit, confirm the new host actually fixes your specific problem, and read its renewal pricing so you don't repeat the mistake. Pick a quiet traffic period for the cutover so a hiccup affects as few people as possible.
Most failed migrations fail here, in the part nobody photographs. Do this before touching the new server:
The TTL (time to live) on a DNS record tells resolvers how long to cache it. If your A record's TTL is 86,400 seconds (24 hours), the world can keep pointing at your old server for a full day after you change it. Lower the TTL to 300 seconds (five minutes) at least 24 to 48 hours before the cutover. By the time you switch, the old long TTL has expired everywhere and the new short one is in force, so DNS propagation after the change is measured in minutes, not days. This single step does more for "zero downtime" than anything else.
There are three common ways to move the actual content, and the right one depends on your platform and comfort level.
| Method | Best for | Trade-off |
|---|---|---|
| New host's free migration service | Anyone whose new host offers it; large or complex sites | Easiest and lowest-risk, but you wait on their queue and have less control over timing |
| Migration plugin (e.g. WordPress) | WordPress and similar CMS sites | Bundles files and database into one move, but very large sites can hit upload or memory limits |
| Manual: SFTP + database export/import | Custom sites, or when you want full control | Most reliable and transparent, but you must handle files and database separately and edit config by hand |
If your new host offers free managed migration, use it, it's the lowest-risk path and they've done it thousands of times. Otherwise, plugins suit WordPress and the manual route suits everything else. The steps below describe the manual approach because understanding it makes every other method easier to supervise.
Connect to the old server over SFTP (the encrypted version of FTP) and download the full site directory, or move it server-to-server if both hosts support it. Then export your database, typically a single .sql file via phpMyAdmin or the command line. On the new host, create a fresh empty database and user, then import that .sql file and upload the files into the new web root. Keep file permissions and folder structure identical so nothing breaks on arrival.
The new database almost always has a new name, user and password, so the site's config file must be updated to match. For WordPress that's wp-config.php (database name, user, password, and host). For other apps it's the equivalent connection settings. Also check for hard-coded absolute paths or full URLs that referenced the old server, and update any environment-specific values. A site that loads its homepage but throws a database connection error is almost always a config mismatch here.
This is the step that turns a scary migration into a boring one. Your domain still points at the old host, so you need a private way to view the new copy:
With private access, click through everything: internal links, images, forms, login, checkout, search. Look for broken links, missing assets, mixed-content warnings and any config issues. Fix them now, while the live site is untouched and nobody is watching.
Once the new copy passes testing, make the switch. You either update the A record to the new server's IP, or change your domain's nameservers to the new host's. Because you lowered the TTL earlier, the change propagates in roughly your TTL window (minutes), though some networks can lag a little longer. During the propagation window, some visitors see the new server and some still see the old one, which is exactly why the next step matters.
Do not cancel anything yet. Keep the old hosting running until DNS has fully propagated and you've confirmed the new site works for real visitors. Because both servers are live during propagation, ideally put the old site into read-only mode (or pause new orders and comments) so you don't lose data written to the old database that never made it to the new one. For most brochure sites this isn't an issue; for active stores and forums, plan the cutover for a low-traffic window to minimise the gap.
SSL certificates are tied to a specific server, so your old certificate doesn't travel with the files. Most hosts issue a free certificate through Let's Encrypt automatically once DNS points at them, but it can only validate after propagation. Confirm https:// loads cleanly with no certificate warnings, and that the certificate covers both the bare domain and the www version. Until SSL re-issue completes, expect brief browser warnings, another reason to keep the old host live as a fallback.
Once the new server is serving real traffic, run a verification pass:
If your email is hosted with the web host (rather than a separate provider like a dedicated mail service), it needs its own plan. Recreate every mailbox on the new host before changing the MX records, and migrate existing messages so nothing is lost. Mail sent during the MX propagation window can land on either server, so keep the old mailboxes alive for a few days. If your email lives with a separate provider, leave its MX and SPF/TXT records untouched during the web move.
Only after everything is confirmed and stable, take one final backup of the old server, then cancel it. The old host is your safety net; giving it up early means a problem you discover on day three has no fallback. A week of overlap is cheap insurance against a migration you'd otherwise have to redo from scratch.
The hands-on work for a small site is often an afternoon. The calendar time is longer because of DNS: lowering the TTL a day or two ahead and then keeping both hosts live during propagation and verification stretches the safe version of the process across roughly a week. That overlap is what buys you the near-zero-downtime result.
It shouldn't, if you test on the new server before switching DNS and keep the old host running through propagation. Visitors stay on the old server until DNS points elsewhere, and a lowered TTL keeps that transition to minutes. The common cause of visible downtime is switching DNS before the new site has been tested.
If it's offered and your site is standard, yes. It's the lowest-risk option and the team does migrations daily. Reserve the plugin or manual SFTP and database route for cases where the free service isn't available, your site is unusual, or you want to control the exact cutover time.
A clean migration that preserves your URLs, content and redirects has minimal SEO impact. Keep the same URL structure, carry over your .htaccess redirects, re-verify in Google Search Console, and avoid extended downtime. Rankings usually settle quickly once the new server is stable and fast.
← Back to the HostScope calculator · Read next: Common hosting mistakes to avoid →