Abstract illustration of website files and database migrating between two server racks

How to Migrate a Website to a New Host Without Losing Anything

This page contains affiliate links. If you make a purchase through one, we may earn a commission at no extra cost to you.

Moving a website to a new host is a different problem from transferring a domain — this is about copying the actual site (files, database, email) to new hosting infrastructure while keeping the domain pointed correctly the whole time. See Netart’s hosting migration options.

What Actually Needs to Move

Three separate things make up a website migration: the site files themselves, the database (if the site uses one, like WordPress), and any email accounts hosted on the domain. Missing any one of these is the most common reason a “completed” migration turns up broken pages or missing email a few days later — the migration needs to move all three, not just the visible website files.

Abstract illustration of website files and database migrating between two server racks

The DNS Propagation Window Is the Actual Risk

Once DNS is updated to point at the new host, that change doesn’t take effect everywhere instantly — propagation can take anywhere from minutes to 48 hours depending on cached DNS records around the internet. Keeping both the old and new hosting live during this window, rather than canceling the old host immediately, means visitors hitting either version see a working site instead of a broken one during the transition.

Set up your new hosting with Netart before canceling anything at your old provider.

Shrinking the Propagation Window Before You Migrate

The up-to-48-hour propagation window isn’t fixed — it’s controlled by a DNS setting called TTL (time to live), which tells other servers around the internet how long to cache a DNS record before checking for updates again. Most domains run a default TTL of an hour or more, which is fine for everyday stability but works against you specifically during a migration. Lowering the TTL to something short (5-15 minutes) 24-48 hours before the actual migration, then switching it back to a normal value afterward, dramatically shrinks the real-world propagation window from the worst-case 48 hours down to something closer to the TTL value itself.

This is a genuinely underused step — most beginner migration guides skip it entirely — but it’s a five-minute DNS setting change that meaningfully reduces how long you need to keep both hosts running simultaneously and how long visitors might see inconsistent versions of the site during the switch.

Testing Before the Switch, Not After

Most hosts let you preview a migrated site using a temporary URL or a modified local hosts file, letting you verify the site actually works on the new host before DNS is switched over. Testing this way — rather than switching DNS first and hoping it works — catches problems while the old site is still live and unaffected, instead of after visitors are already being routed to a broken new one.

Laptop showing a website preview with a pre-launch testing checklist

Email Migration Deserves Its Own Checklist

Email tied to a domain is easy to forget during a website-focused migration, and losing access to business email even briefly is often more disruptive than a few hours of website downtime. Setting up mailboxes on the new host and testing send/receive before switching DNS — the same principle as testing the website — prevents an email outage riding along with the site migration.

Platform-Specific Gotchas That Trip Up Migrations

For WordPress specifically, a migration commonly runs into a handful of predictable problems that aren’t obvious from just copying files: the site URL is often stored directly in the database rather than derived automatically, so a straight file/database copy to a new domain or URL structure can leave internal links pointing at the old address until the database is specifically updated. File permissions frequently reset incorrectly during a transfer between different hosting environments, which can cause a site to load with broken styling or throw permission errors even though every file technically made it across. A PHP version mismatch between the old and new host is another common, easy-to-miss cause of a site that looks fine on file inspection but throws errors or renders incorrectly once live — checking that the new host runs a PHP version your site’s theme and plugins actually support avoids this specific class of post-migration troubleshooting.

The Backup That Makes the Whole Thing Reversible

A full backup of the old site and database, taken immediately before migrating, means the entire process can be undone if something goes wrong on the new host — point DNS back, and the old site is exactly as it was. Skipping this step turns a routine migration into a one-way decision with no fallback if the new host has an unexpected problem.

Bottom Line

Move files, database, and email together, test on a preview URL before switching DNS, keep both hosts live through the propagation window, and take a full backup first — doing all four turns a migration into a reversible, low-risk process instead of a stressful one-shot switch.

Migrate your site to Netart

Frequently Asked Questions

How long should I keep my old hosting active during a migration?

At least through the full DNS propagation window, typically up to 48 hours after the switch, so visitors still being routed to the old server during propagation see a working site rather than a canceled account.

Will my email stop working during a migration?

Only if email migration isn’t planned alongside the website migration. Setting up and testing mailboxes on the new host before switching DNS prevents an email outage from riding along with the site move.

Can I preview my migrated site before switching DNS?

Yes — most hosts support a temporary preview URL or a local hosts-file override that lets you verify the new site works correctly before any visitor-facing DNS change happens.

Should I lower my DNS TTL before migrating?

Yes — lowering TTL to 5-15 minutes a day or two before the migration meaningfully shrinks the propagation window from a worst-case 48 hours down to close to the TTL value itself. Set it back to a normal value once the migration is confirmed stable.

Why does my migrated WordPress site show broken links or missing styling?

Usually one of two things: the site URL stored in the database still points at the old address, or file permissions reset incorrectly during the transfer. Both are common, well-documented migration issues rather than signs of a failed migration overall.