Most WordPress migrations take between two and eight hours of hands-on work, with the site live on its new host the same day. Large or complicated sites — WooCommerce stores, multisite networks, anything above a few gigabytes or with custom server configuration — run from a full day to a couple of weeks of planned work.
The spread is wide because "migration" covers two very different jobs. Copying a small blog to a new host is a routine file-and-database transfer. Moving a transactional site, changing its domain, or rebuilding it on different infrastructure is a project with testing, DNS timing, and a rollback plan attached.
Table of Contents
- What the clock is actually measuring
- Realistic ranges by site type
- Where migrations actually lose time
- How to compress the timeline
- The cutover window, and what it costs you
- When to budget for a longer project
- Frequently Asked Questions
What the clock is actually measuring
Three separate timelines get confused in migration estimates, and conflating them is why quoted numbers disagree so badly. The first is transfer and import time — how long it takes to copy files and the database and get them running elsewhere. This scales roughly with size. A 500 MB site moves in minutes; a 40 GB media library can take hours, and the database import is often slower than the file copy because large tables rebuild indexes as they load.
The second is hands-on technical work: configuring the new server, fixing paths, re-issuing SSL certificates, testing, and resolving whatever breaks. This scales with complexity, not size, and it is usually the biggest number. The third is DNS propagation — the window after you point the domain at the new server. Most resolvers pick up a change within a few hours; the conventional 24-to-48-hour figure is the outer bound, driven by caching at intermediate resolvers and by the TTL (time to live) value on your DNS records. Lowering the TTL to five minutes a day or two before the switch shrinks this window considerably.
Realistic ranges by site type
These are planning figures for the hands-on work, assuming the destination host is already provisioned and you are not redesigning anything. A useful rule: if the site takes money or has logged-in users, assume the work doubles compared with a content-only site of the same size.
- **Small blog or brochure site**, under 1 GB, standard theme, ten or fewer plugins: 1–3 hours.
- **Established content site**, a few gigabytes, custom theme, caching and an SEO plugin: 3–8 hours.
- **WooCommerce or membership site** with live orders, subscriptions, or payment gateways: 1–3 days, because you need a maintenance window and order-data reconciliation.
- **Host-to-host move using the host's own migration plugin**: often 30–90 minutes of your time, with the host's tooling doing the copy in the background.
- **Multisite network, or a move that changes the domain**: several days to two weeks, since every subsite or every stored URL needs attention.
Where migrations actually lose time
Downloads and uploads rarely cause the overruns. Specific, predictable obstacles do. Large media libraries are the most common. Tens of thousands of files transfer far more slowly as individual items over FTP than as a single compressed archive moved server-to-server, and some migration plugins hit PHP execution timeouts or memory limits partway through a big export. Hosts also impose upload size caps that a 3 GB archive will exceed.
Hardcoded URLs are the second. WordPress stores absolute URLs throughout the database, including inside serialized data in plugin options and page-builder content. A naive search-and-replace corrupts serialized arrays by changing string contents without updating their stored length values, which is why tools like WP-CLI's `search-replace` command handle serialization explicitly. Symptoms show up later as broken builder layouts or missing widget settings. Environment mismatches produce the rest: a different PHP version than the old host ran, missing PHP extensions, a licensed plugin bound to the old domain, or a server-level rule from `.htaccess` that the new stack ignores because it runs Nginx instead of Apache. Each is minor alone; three together turn a two-hour job into a day.
How to compress the timeline
Most of the saving comes from sequencing, not speed.
- Use the destination host's migration service first. Managed WordPress hosts generally offer free migrations or a first-party plugin, and their tooling already knows their own stack.
- Audit before you copy. Note the PHP version, the plugin list with licence details, any custom server rules, and the total size of `wp-content/uploads`.
- Lower your DNS TTL 48 hours ahead of the switch, so the cutover window is minutes rather than a day.
- Stage the site on the new host and test it over a temporary URL or a local hosts-file entry while the old site stays live. This removes almost all cutover risk.
- Freeze content. Anything published or ordered after you take the database copy will be lost unless you migrate it again.
The cutover window, and what it costs you
Downtime and migration time are not the same measurement. A well-run migration has a cutover of minutes to zero, because the new site is already built and tested before the domain moves; the hours of work happened while visitors were still being served by the old host. Real downtime appears when the database is copied at the same moment the domain changes, so traffic lands on a half-finished site.
It also appears if SSL is not in place before the switch — browsers will show a security warning, which looks worse to visitors than an outage. For a store, the relevant number is the order gap: the stretch between the final database copy and the moment the new site accepts checkout. Keep it inside a low-traffic hour, and put the site into a holding state rather than letting customers submit orders into a database you are about to discard.
When to budget for a longer project
Some conditions reliably push past the normal ranges, and recognising them early is more valuable than a faster transfer. Expect weeks, not hours, if the site has custom server-level code, a continuous integration pipeline, integrations with external systems keyed to a specific IP or domain, or a dependency on a plugin the new environment cannot run.
The same applies to any migration that changes the URL structure, which brings redirect mapping into scope — every old URL needs a 301 to its new equivalent, or search rankings and inbound links degrade. Always keep a verified rollback: a full backup of files and database taken immediately before cutover, stored somewhere independent of both hosts, plus the old host's account left active for at least a week. The cheapest insurance in a migration is not finishing faster — it is being able to put the old site back in ten minutes.
Frequently Asked Questions
Will my site be offline during a WordPress migration?
It does not have to be. If you build and test the site on the new host first and only then repoint the domain, visitors keep seeing the old server until the switch, and downtime is minutes or none.
Does a migration hurt search rankings?
Not if URLs stay the same and the site returns the same content at the same addresses. Rankings suffer when a migration changes the URL structure without 301 redirects, or when the new server is noticeably slower.
How long should I keep the old hosting account?
At least a week after cutover, and longer if traffic patterns are seasonal. That window covers late-discovered problems and gives you a working original to compare against.
Can a migration plugin handle everything?
For small and mid-sized sites, usually yes. Plugins struggle with multi-gigabyte archives, PHP timeouts on large exports, and anything configured at server level rather than inside WordPress — those parts stay manual.
