Guide

How to Migrate Your Website to a New Host With Zero Downtime

Moving hosts doesn't have to mean an outage. The trick is to build the new site fully, test it on the new server, and switch DNS only after everything checks out — so visitors never hit a broken page.

June 1, 20266 min readhow to migrate website to new host

Key takeaways

Zero downtime comes from order of operations: build and test on the new host first, switch DNS last.
Lower your DNS TTL to ~300 seconds about 24 hours before cutover so changes propagate in minutes, not days.
Preview the live domain privately with a hosts-file override before anyone else sees the new server.
Match runtime versions (PHP, MySQL, Node) on the new host — mismatches break migrated sites more than anything else.
Keep the old server running 24–48 hours after cutover, then decommission once traffic hits zero.

Why "zero downtime" is really about DNS timing

Most migration horror stories come from one mistake: changing DNS first, then scrambling to move files while the world points at a half-built server. Zero-downtime migration flips that order. You stand up a complete, working copy of your site on the new host, verify it privately, and only then repoint DNS.

Because DNS changes propagate gradually — some visitors see the new host within minutes, others keep hitting the old one for hours — both servers must serve a working site during the overlap window. Plan for both to be live simultaneously, not for an instant hard switch.

Old host and new host both stay online through the cutover
DNS propagation is gradual, not instant — expect a few hours of overlap
Lowering your DNS TTL ahead of time shrinks that window dramatically

Get free migrationOn the fastest servers in the North — free migration, 24/7 human support.Get free migration

Step 1: Inventory and prep before you touch anything

Start by listing everything the site needs to run: web files, the database, email accounts, cron jobs, SSL certificates, environment variables, and any third-party API keys or webhooks tied to your domain. Note your current stack versions (PHP 8.1 vs 8.3, MySQL 8.0, Node version) so the new host matches — version mismatches are the most common cause of a migrated site that loads but breaks.

Take a full backup first: a compressed archive of your files plus a database dump. For a typical small business WordPress site (1–5 GB of files, a few hundred MB database), this takes minutes. Keep that backup untouched as your rollback point.

Files, database, email, cron jobs, SSL, env vars, API keys
Match runtime versions (PHP, MySQL/MariaDB, Node) on the new host
Take and verify a full backup as your rollback safety net

Step 2: Build and test the site on the new host

Upload your files and import the database to the new server, but don't switch DNS yet. Update config (database credentials, file paths, base URLs if needed) to point at the new environment. Install your SSL certificate now — Let's Encrypt issues in seconds once the host can validate ownership, or you can pre-stage a cert before cutover.

Test the new site before it's live by editing your local computer's hosts file to map your domain to the new server's IP. This makes your browser — and only your browser — resolve the domain to the new host so you can click through pages, log in, submit forms, and check checkout flows exactly as real users will, while the public still sees the old site untouched.

Import files + DB, fix credentials and base URLs
Install/validate SSL on the new host before going live
Use a hosts-file override to preview the live domain privately

Step 3: Lower TTL, sync final data, then cut over DNS

A day before migration, lower the TTL on your domain's A/AAAA (or CNAME) records to 300 seconds (5 minutes). TTL tells resolvers how long to cache your records; a low value means the world picks up your change in minutes instead of the default 24–48 hours.

On cutover day, do a final sync of anything that changed since your first copy — recent orders, new blog comments, uploaded media — to avoid losing data created during the migration. Then update the DNS records to the new host's IP. With a 5-minute TTL, most traffic shifts within minutes; leave the old server running for 24–48 hours to catch stragglers, then decommission it once your logs show zero traffic.

Drop TTL to ~300s about 24 hours before cutover
Do a final delta sync of database + new uploads right before the switch
Keep the old host live 24–48h, then decommission after traffic stops

Step 4: Verify, monitor, and handle the edge cases

After cutover, confirm SSL is valid (no certificate warnings), check that www and non-www both resolve, and watch your error logs and uptime monitor for the first hour. Test the things automated checks miss: contact forms actually sending email, payment webhooks firing, and any redirects (especially HTTP→HTTPS and trailing-slash rules) behaving the same as before.

Email is the classic gotcha. If your MX records or mail hosting are changing too, plan that separately — mail can bounce silently during DNS propagation. And don't forget caches: clear your CDN and any app-level cache so visitors aren't served stale assets pointing at the old origin.

Make it boring: let the new host do the migration

Done carefully, a zero-downtime migration is methodical, not risky. But it does require a maintenance window, attention to detail, and someone who's done it before — which is exactly why the smoothest moves are the ones the new provider handles for you.

At NordicVentures, free migration is included with business hosting: our team copies your files and database, stage-tests on the new server, matches your stack versions, and coordinates the DNS cutover so visitors never see downtime. You get NVMe bare-metal and cloud across Stockholm, Frankfurt, and Ashburn, 24/7 human support, and transparent pricing with no renewal shock. If you'd rather skip the checklist entirely, see how it works on our business hosting page and let us move you for free.

Free, hands-on migration handled by our engineers
Stack-version matching so the migrated site works, not just loads
Coordinated DNS cutover with both servers live through the overlap

FAQ

How long does it take to migrate a website to a new host?

The file and database copy for a typical small business site (1–5 GB) takes minutes to a couple of hours. The longer pole is DNS propagation after cutover — usually minutes if you've lowered your TTL to 300 seconds beforehand, but up to 24–48 hours on default TTLs. End to end, most small-site migrations are done within a day.

Will my website go down during migration?

It shouldn't, if done correctly. The zero-downtime approach keeps both the old and new servers live and only switches DNS after the new site is fully built and tested. Because both hosts serve the same working site during propagation, visitors never hit an outage — they just gradually shift to the new server.

What is DNS TTL and why lower it before migrating?

TTL (time to live) is how long DNS resolvers cache your domain's records. The default is often 24–48 hours, meaning a record change can take that long to reach everyone. Lowering TTL to ~300 seconds a day before cutover means resolvers refresh every 5 minutes, so your switch to the new host propagates almost immediately.

Should I migrate my website myself or have the host do it?

If you're comfortable with backups, database imports, config edits, and DNS, a careful self-migration works fine. But many hosts — NordicVentures included — offer free migration where their team handles the copy, stack-version matching, testing, and DNS cutover for you. That's usually the safer, faster choice, especially for ecommerce or sites with email and webhooks.

Ready to launch?Get free migration on NordicVentures — the fastest servers in the North.Get free migration

Keep reading