Zero downtime for small business sites: Move your site to a new host

Yes, you can move your website to a new host without any downtime, provided you follow a controlled process rather than just pointing your domain at the new server and hoping. The three actions that matter most: back up everything before you touch a thing, build and test the new site on a staging or temporary URL, and keep the old host active until you’ve verified the new one properly works. If any of that feels beyond your comfort zone, a managed migration is the sensible fallback.

TL;DR:

Lowering DNS TTL to around 300 seconds at least one day before the move ensures faster propagation and minimises downtime risks.

Using control-panel transfer tools is most effective when both hosts run the same management panel, enabling a quick, seamless migration.

Testing the new site via a temporary URL or local hosts file before DNS switching prevents unnoticed errors from affecting visitors.

Keeping the old host active for 48 to 72 hours after switching allows monitoring for issues and facilitates a smooth rollback if necessary.

A managed migration is recommended for ecommerce or booking sites to reduce operational risk and handle complex configurations, especially when time or technical expertise is limited.

TTOY Digital

Move Your Website With Confidence

TTOY Digital creates mobile first websites and provides ongoing support for small businesses improving their online presence.

Explore TTOY Digital

Pre-move checklist: what to capture before you touch anything
Which migration method should you use?
The day-of migration playbook
Getting DNS and cutover right
Post-migration checks and how to roll back
Why we recommend a managed migration for certain sites
Managed migration and post-move support
Helpful external guides and tools to consult
Sources
FAQ

Pre-move checklist: what to capture before you touch anything

Most migration disasters trace back to the same cause. Someone skipped the audit stage and only discovered the missing piece, usually a forgotten subdomain or an email account, after the old server had already gone dark.

Before you move website host, document what you’re actually running. This isn’t busywork. It’s the difference between a two-hour job and a two-day fire drill.

List every domain and subdomain pointing at the current server, including staging areas, mail subdomains, and anything a past developer set up and forgot to mention.
Export your full DNS zone file, capturing A, AAAA, CNAME, MX, and TXT records exactly as they stand.
Take complete off-site backups of all files and databases, stored somewhere other than the host you’re leaving.
Export email separately if it’s hosted with the old provider, since a site backup rarely includes mailbox data.
Note the server environment: PHP or Node version, file paths, cron jobs, and file permissions, so the new host can replicate it.
Confirm you have every login you’ll need: control panel, FTP/SFTP, database tools, and crucially, the domain registrar itself.
Lower your DNS TTL to around 300 seconds, ideally 24 to 48 hours before cutover, so any change propagates fast instead of leaving visitors split between two servers.

That last point catches people out constantly. A high TTL set years ago and never revisited can mean your DNS change takes a full day to reach everyone, right when you need it to happen in minutes.

Pro Tip: Screenshot your current DNS records before you change anything. If a support technician on either end makes an error, you want proof of what “before” looked like.

Which migration method should you use?

There’s no single right way to move website host. The right method depends on what your site is built on, how much risk you can tolerate, and how much of this you want to do yourself.

Manual migration (FTP plus database export) gives you complete control over every file and setting. It suits custom-built sites, anything not running WordPress, or moves between hosts that don’t share a control panel. It’s also the slowest and most exacting option.
Control-panel migration works when both the old and new host run the same panel, usually cPanel or DirectAdmin. A full-account transfer tool can move everything, including email and databases, in one pass.
WordPress plugin migration is the quickest route for most WordPress sites. Tools such as Duplicator or All-in-One WP Migration can move a small site in 15 to 45 minutes, though large media libraries or unusual serialised data in the database can trip up the import.
Host-assisted migration means the new provider does the heavy lifting. For anything selling online or running bookings, this cuts operational risk considerably, because the provider can recreate server-specific settings and handle SSL provisioning themselves rather than leaving you to guess at the configuration.

Choosing a WordPress backup plugin properly beforehand also makes the plugin route far less stressful, since a clean, tested backup is your safety net regardless of which method you pick.

Method	Typical time	Best suited to
WordPress plugin	15 to 45 minutes	Small to mid-sized WordPress sites
Control-panel transfer	30 to 60 minutes	Same-panel host-to-host moves
Manual (FTP and database)	1 to 3 hours	Custom builds, non-standard stacks
Host-assisted	Varies by provider	Ecommerce, bookings, complex integrations

If you’re moving website hosting for a shop or a site that takes payments, the small extra cost of a host-assisted move is usually less than the afternoon you’d lose troubleshooting a broken checkout.

The day-of migration playbook

This is where planning turns into action. Work through it in order and resist the temptation to skip the testing stage because “it looked fine on the old server.”

Build the destination first. Create the hosting account, set up the control panel, create the database, and provision SSL before a single file moves.
Copy the files, preserving the exact directory structure, using an SFTP client. FileZilla remains a reliable, free option most site owners can pick up quickly. Export the database, import it into the new server, then update any configuration files that reference the old file paths or database credentials.
Test everything before DNS changes. Edit your local hosts file, or use the temporary URL your new host provides, to load the new site while your domain still points elsewhere. Check SSL, forms, checkout, logins, and media here, because this is the last point where a mistake costs you nothing.
Freeze writes or run a final sync. For a static brochure site this barely matters. For anything dynamic, taking orders or new sign-ups right up to the moment of cutover, schedule a short maintenance window, take a final database export, and import it fresh so no late order gets lost between the two servers.
Update DNS and monitor closely. Switch the A record or nameservers, then watch server logs and site monitoring for the next few hours rather than walking away.

Budget your time realistically. A plugin-based WordPress move can be done in under an hour, but full DNS propagation still takes several hours to two days depending on caching further up the chain, so “finished” and “fully propagated everywhere” are two different milestones.

Don’t forget the parts that have nothing to do with servers. Before you flip the switch, confirm your sitemap is ready to resubmit, that redirects are mapped for any URL that’s changing, and that your analytics tracking code has actually made it into the new environment. Preserving SEO signals during a migration is far easier to do proactively than to fix after Google has already noticed something’s wrong.

Getting DNS and cutover right

DNS is where most “the site’s been down for two days” horror stories actually happen, and nearly all of them stem from skipping the TTL step.

Lower TTL to roughly 300 seconds at least one to two days before cutover. This speeds up how fast the change reaches every resolver that’s caching your old records, cutting the window where some visitors see the old site and others see the new one.
Use an A record change for a straightforward hosting move. It’s simpler and faster to reverse than switching nameservers, which requires rebuilding your entire DNS zone from scratch at the new provider.
Reserve nameserver changes for when you’re also moving DNS management itself, not just hosting, since it touches every record type at once rather than just the pointer to your web server.
Make the actual switch during a low-traffic window for your business, whatever that looks like for you, after you’ve confirmed everything on the temporary URL.
Keep the old host running for 48 to 72 hours after cutover, watching email flow and server logs for anything that slipped through testing.

If you’re handling a domain transfer at the same time as a host move, treat them as two separate operations with two separate verification steps, not one combined leap. A guide to transferring domains cleanly is worth a proper read if the registrar side confuses you.

Pro Tip: If your email runs through the same host you’re leaving, don’t touch MX records until the web side is confirmed stable. Splitting the email switch from the website switch gives you one less variable if something goes wrong.

Getting DNS and cutover right — overview diagram

Post-migration checks and how to roll back

Once DNS has switched, run through verification methodically rather than just refreshing the homepage and calling it done.

Check SSL, general site health, form submissions, and any ecommerce checkout end to end, not just that the page loads.
Confirm indexing signals: resubmit your sitemap, check Google Search Console for crawl errors, and verify analytics is firing and canonical tags are correct.
Test email delivery specifically, including SPF, DKIM, and DMARC authentication records, since a broken authentication chain often shows up as legitimate emails landing in spam rather than an obvious failure.
Watch for rollback triggers: persistent 5xx server errors, failed payments, or an email outage all mean switching DNS back to the old host and restoring from your pre-migration backup, which is exactly why that old account stays active rather than being cancelled the moment the new site loads.

A thorough migration workflow runs through five stages: full inventory, staging build, migration itself, verification, and handover with documentation. We follow that order because skipping the inventory stage is where most surprises come from later.

For a simple brochure site with no bookings, no payments, and someone comfortable poking around a control panel, doing it yourself is entirely reasonable. Where we push back is with anything running ecommerce, appointment bookings, or a team with no spare time to babysit DNS logs for 48 hours. In those cases, the cost of a managed migration is smaller than the cost of even a few hours of a broken checkout.

— Chris

Managed migration and post-move support

A managed migration covers staging the new environment, provisioning SSL, handling the DNS cutover itself, checking email authentication end to end, and monitoring the site for 48 to 72 hours after the switch, exactly the window where rollback decisions get made.

Managed website migration sequence

Before requesting a quote, have your current hosting login, an idea of your site’s size, and a note of any integrations (payment gateways, booking systems, CRM tools) ready, since these drive both timeline and cost. If your business already runs on customer data that needs to move cleanly too, our SmartFlowCRM team can fold that into the same handover. Get in touch through our services page to talk through your setup and get a straightforward timeline.

Helpful external guides and tools to consult

For the WordPress-specific mechanics, the WordPress Learn migration lesson is worth bookmarking, alongside FileZilla for file transfers and SiteGround Academy’s migration guide for staged testing methodology. If backups are your weak point, our own guide to choosing a WordPress backup plugin covers the practical options.

Sources

FAQ

Can I move my website from one host to another?

Yes. Any website can move to a new host, provided you back up files and databases first, test on the new server before switching DNS, and keep the old host active as a fallback until you’ve verified everything works.

How do I move a website to a different host?

Back up your site, build the destination environment, copy files and the database across, test using a hosts-file override or temporary URL, then update DNS once you’ve confirmed SSL, forms, and logins all work correctly.

How do I change the host of my website?

Changing hosts means moving your files and database to the new provider’s server and then updating your DNS records, either the A record or nameservers, to point your domain there once testing is complete.

Is it free to move website hosting?

Some providers advertise free migrations as a sign-up incentive, but check exactly what’s included, since databases, email, and SSL aren’t always covered automatically, and gaps in that coverage are where most surprises happen.

How long does a website migration take?

A WordPress plugin migration typically takes 15 to 45 minutes for a small site, a control-panel transfer 30 to 60 minutes, and a manual migration one to three hours, though full DNS propagation can still take up to 48 hours afterwards.