If you're planning a host move, the question that actually keeps people up at night isn't cost — it's wordpress site downtime. Will the site go dark for an hour, a day, or not at all? The honest answer depends on which parts of a migration you're measuring, because "downtime" and "migration time" are not the same thing. This post breaks down what really happens at each stage, so you can set expectations correctly and plan around them.
What actually causes downtime during a migration
A migration has several phases, and only some of them touch your live, public-facing site. Understanding which is which is the key to estimating real downtime instead of total project time.
DNS propagation isn't the same as your site being down
DNS propagation gets blamed for most perceived "downtime," but it's often a red herring. When you point your domain to a new server, each DNS resolver worldwide keeps its own cached copy of your old record until that record's TTL expires, and only then fetches the update — with a long-lived record that can take the better part of a day, though a short TTL set in advance can bring it down to minutes. Critically, your old site typically stays live and serving visitors during this window, as long as you haven't already shut it down.
The actual site-down window is usually much shorter
True downtime — the site being genuinely unreachable — usually happens only during the final cutover: copying the last database changes, updating configuration, and flipping the switch. For a straightforward WordPress site, this final step is often measured in minutes, not hours, if it's planned properly. It's the unplanned parts — a misconfigured database connection, a missing plugin, a broken permalink structure — that turn a 10-minute cutover into a multi-hour scramble.
How long does a WordPress migration take, by type
The table below separates total project time (planning, transfer, testing) from actual visitor-facing downtime, since they're frequently confused.
| Migration type | Typical total time | Typical visitor-facing downtime |
|---|---|---|
| Host-to-host, simple brochure site | A few hours to a day | Minutes, if timed well |
| Business site with active blog | 1-3 days | Minutes to a couple hours |
| WooCommerce store or large content site | Several days to a couple weeks | Can be minutes with proper technique, hours if rushed |
| DIY migration with no staging environment | Highly variable | Hours, sometimes longer if errors occur |
The pattern is consistent: total project time scales with site complexity, but downtime itself scales more with how the migration is executed than with site size.
How to avoid downtime with a staging-and-swap approach
The most reliable way to minimize wordpress site downtime is to never take the live site offline until the new environment is fully tested and ready. This is the staging-and-swap method, and it's the approach most hosting providers and migration guides recommend.
- Build the new site on a staging URL or temporary domain on the new host, without touching the live site at all.
- Migrate the database and files to that staging environment and fix any path or URL references there.
- Test everything on staging — forms, checkout if applicable, plugins, page speed — while the live site keeps running normally.
- Lower your DNS TTL (time to live) a day or two in advance so that resolvers refresh their cached copy of your record sooner once you do switch.
- Do a final content sync to capture anything published between your initial transfer and cutover (new posts, orders, comments).
- Switch DNS and go live, ideally during a low-traffic window, keeping the old server untouched for a few days as a fallback.
Done this way, actual downtime often shrinks to the few minutes needed for the final sync and DNS cutover — not the full migration timeline.
In short: how long does a WordPress migration take?
A well-planned WordPress migration typically causes only minutes of actual site downtime, even though the full project — transferring files, testing, and DNS cutover — can take anywhere from a few hours to two weeks depending on site size. Using a staging environment and lowering DNS TTL in advance keeps the live site running until the very last step, minimizing visitor-facing disruption.
What drives migration timelines longer
Beyond raw site size, a few factors reliably stretch out both total time and downtime risk: custom plugins or code that need reconfiguration on the new server, large media libraries that take longer to transfer, WooCommerce order and inventory syncing, and any custom integrations (payment gateways, CRMs, email marketing tools) that need re-testing after the move. If your site has several of these, budget extra buffer time and lean even harder on the staging-and-swap approach rather than a direct live-to-live transfer.
What to do if you can't avoid a longer downtime window
Not every migration can use the full staging-and-swap approach — a complex WooCommerce store with live inventory syncing, for instance, may need a genuine maintenance window to avoid data conflicts during the transfer. If that's your situation, there are still ways to limit the damage.
- Schedule the window during your lowest-traffic period, based on your own analytics rather than generic assumptions about "off-peak" hours.
- Put up a clear maintenance page rather than letting visitors hit a raw server error — it's a small trust difference that matters, especially for repeat customers.
- Notify customers or users in advance if the downtime is planned to exceed a few minutes, particularly for stores where checkout will be unavailable.
- Batch as much pre-work as possible outside the window — file transfers, configuration, and testing should all happen before the maintenance page goes up, not during it.
- Set a hard time limit and a fallback plan — if the cutover isn't verified working within your planned window, know in advance whether you'll roll back to the old server or push through with troubleshooting live.
Testing after cutover, before you call it done
Downtime doesn't always end cleanly the moment DNS switches over. Some visitors will still be served the old server for a period depending on their resolver's cache, which can create confusing, inconsistent reports of "it's still down" even after the new site is live and working. Checking from multiple networks and using a DNS propagation checker helps you distinguish between a real ongoing problem and normal, expected propagation lag. Give it a few hours before troubleshooting further based on scattered reports.
Related guides cover a 15-step WordPress migration checklist, migrating WordPress without losing SEO rankings, and how much revenue you lose per minute of downtime.
