A standard WordPress site moves to a new host in 1 to 3 working days. A WooCommerce store or a large, content-heavy site needs a few more days of checks, not more downtime. That distinction is the whole answer: the total project time and the time visitors actually notice are two different numbers, and a migration planned properly keeps the second one at zero.
Below is what determines the total, the step that removes the downtime rather than just shortening it, a table matching site type to a realistic timeframe, and the process end to end. If your store is mid-sale and you are reading this because someone mentioned a “maintenance window”, skip to when it is not worth doing yourself.
What determines how long it takes
A migration has three parts, and only the last one carries any risk of visitors noticing: copying the site (files, database, and email if it is hosted with the site), verifying the copy on a staging environment until it behaves identically to the original, and switching the domain to point at the new host. According to WordPress’s own migration documentation, the platform does not need to be reinstalled or rebuilt to move — it is designed to be copied wholesale, database included, which is why the copy itself is rarely the slow part.
What actually stretches the total is the size and complexity of what you are copying and verifying: a brochure site with a handful of pages can be copied and checked in hours; a WooCommerce store with thousands of products, orders and a payment gateway needs a slower, more deliberate check before anyone trusts it with real transactions.
The step that removes downtime: staging plus a lowered DNS TTL
Downtime during a migration is a planning failure, not a technical necessity. The site does not need to go offline to move — it needs a copy verified somewhere visitors cannot see it, and a domain switch short enough that almost nobody catches it mid-flight. Two things do that.
The first is a staging copy: the whole site duplicated on the new host, reachable only by you, checked against the live original until every page, form and — for a store — the checkout itself behaves the same. The old site keeps serving every visitor while this happens; nothing is switched yet.
The second is the domain’s DNS TTL (time to live) — the number of seconds a record is cached before resolvers re-check it. According to Cloudflare’s DNS documentation (verified August 2026), a longer TTL speeds up everyday lookups but slows down how fast an update reaches visitors, while lowering it to around 300 seconds and waiting out the old TTL window first shrinks that same update to a few minutes almost everywhere. Lower it 24-48 hours before the switch, point the domain at the new host once the staging copy has passed every check, and restore the TTL to a normal value once the move has settled. If a migration instead announces a maintenance window, that is usually the sign nobody lowered the TTL in advance.
How long your type of site typically needs
Total project time by site type, and the risk that actually drives it — not the copy itself, which is fast regardless of size.
| Site type | Typical total time | Main risk if rushed |
|---|---|---|
| Blog or brochure site (a few dozen pages, no store) | Same day to 1 working day | Forgotten redirects on old URLs, or a contact form pointed at the wrong mailbox |
| Business site with forms, bookings or a members area | 1-2 working days | Third-party integrations (email service, booking calendar) still pointed at the old server |
| WooCommerce store | 2-3 working days | Orders or stock changes placed during the copy window not carried over in the final sync |
| Large or content-heavy site (thousands of pages, high traffic) | 3-5 working days | A partial database export truncated by a host’s size or time limit, silently missing rows |
Notice what does not appear in that table: downtime as a line item. In every row, the days are spent copying and verifying — not offline. The visitor-facing switch is the same few minutes regardless of which row you are in, because it is the DNS step, not the size of the site, that determines it.
The migration, step by step
- Copy and staging. Duplicate the site — files, database, email if needed — onto the new host and confirm it is identical to the original before anyone relies on it.
- Lower the DNS TTL. 24-48 hours before the planned switch, drop it to around 300 seconds so the eventual change reaches resolvers in minutes instead of the old TTL’s full window.
- Final sync. Right before the cutover, bring over the latest orders, posts and comments made since the copy was taken, so nothing created in that gap is lost.
- Switch the domain. Point DNS at the new host. With the TTL already lowered, this is the only step with any visitor-facing exposure, and it is measured in minutes.
- Verify and stay on standby. Check SSL, redirects, forms and checkout on the live domain, then keep the old host untouched for 48-72 hours in case anything needs a fallback.
This is the same sequence — copy, staging, controlled DNS switch, verification — behind our WordPress migration service, run the same way whether the site is a blog or a store.
When it is not worth doing yourself
The honest part. A small brochure site with no store and time to spare is a reasonable weekend project for anyone comfortable with FTP and a hosting panel — the steps above are not secret, just easy to skip under time pressure.
What is worth being careful about is the reason people migrate in the first place. Changing host rarely fixes a slow site — it fixes an unreliable one. If the site is slow because of plugins, uncompressed images or a bloated database, moving it to a faster server carries the same bottleneck to a new address; the speed problem travels with the site, it does not stay behind. Migrate because the current host is unreliable, undersized, or you need better support — optimise if the goal is speed, and know which one you actually have before booking either.
And where DIY gets expensive is exactly the case with the least room for error: a live WooCommerce store with orders coming in, or a migration where “we’ll do it over a weekend and hope for the best” is the plan instead of a staging copy and a lowered TTL. We have moved stores at 3am specifically so nobody noticed — the planning is the hard part, the migration itself is routine once it is prepared. That is what our WordPress migration service is for. If the reason you are moving is actually that the current site feels slow rather than unreliable, read about WordPress speed optimisation first — it may be the fix you need before, or instead of, a move.
Frequently asked questions
Will visitors notice the migration happening?
Not if it is planned. The site stays live on the old host, fully working, while it is copied and tested on the new one. The only moment anything could go wrong is the DNS switch, and lowering the TTL 24-48 hours in advance shrinks that window to a few minutes at most.
Does moving host affect my Google rankings?
No, as long as the URLs stay identical. Google indexes URLs, not servers. If the domain does not change, there is nothing for search engines to re-crawl or re-rank — the site simply starts loading from a different address.
What happens to orders placed while the migration is in progress?
They stay on the old host, because the old host keeps taking traffic until the DNS switch. A final database sync right before the cutover carries over any order, comment or post made during the copy-and-test phase, so nothing placed in that window is lost.
Can a migration be done outside office hours to be extra safe?
It is not necessary if the staging and DNS work is done properly, but there is no downside to scheduling the DNS switch itself for a quiet hour — it takes minutes either way, and doing it off-peak simply reduces the number of requests that could theoretically land during the switch.
Why would a migration ever need a maintenance window?
It does not, technically — but a maintenance window is what a rushed migration falls back on. If there is no staging copy to verify against and no lowered TTL to shorten the DNS switch, blocking visitors is the only way to avoid them seeing a half-moved site. That is a planning gap, not a requirement of the process.
How far in advance should I start preparing?
For a standard site, start the TTL change 48 hours before the planned switch and build the staging copy any time before that — the copy itself does not have a deadline, only the DNS preparation does. For a WooCommerce store, add a day for the order and stock sync check.
Sources (verified August 2026): Cloudflare — TTL (time to live) for DNS records; WordPress Developer — Migrating WordPress.