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.

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.

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.
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.
