Most website migrations take about one to two weeks from accepted quote to live. A typical brochure or content site moves in around seven days, while large or e-commerce sites take two to four weeks. WPBuildAI commits to a fixed go-live date up front rather than a vague range, because the timeline is driven by countable things: page count, content volume, and the number of URLs that need redirects. Once those are known, the schedule is predictable.
The honest version: the design rebuild is rarely the slow part. Content and redirect verification is.
What actually drives the timeline
Three things set the clock. The first is page and post count, because every page is rebuilt and every post is moved. The second is media volume, since each image and file has to transfer and be re-linked. The third, and the real one, is the number of indexed URLs that need a mapped 301, because that map has to be built and verified before launch.
Design complexity matters less than people expect. A striking ten-page site can be faster than a plain two-hundred-post blog, because the blog carries far more content and far more redirects.
How long each type of site takes
Use this as a planning guide. Your exact date comes from a crawl of the real site, not a category.
| Site type | Typical timeline | What drives it | Verdict |
|---|---|---|---|
| Brochure site, under 10 pages | About 5 to 7 days | Page rebuild, light redirect map | Fastest, fixed date |
| Content site or blog, 50 to 200 posts | About 1 to 2 weeks | Content move, large redirect map | Predictable with a crawl |
| E-commerce, products and members | 2 to 4 weeks | Catalog, checkout, parameter URLs | Plan a staging review window |
| Multi-language or custom app | Scoped per project | Many URL trees, integrations | Quote individually |
The pattern: the more URLs and content, the longer the verify phase, not the design phase. WPBuildAI turns each row into a firm date by crawling the site first, so you plan around a real number.
Why the redirect phase sets the schedule
You can rebuild pages quickly. You cannot safely launch until every old URL maps to its new home, because a missing redirect means a 404 and lost rankings. Google’s site move guidance assumes redirects are in place before the switch, so this phase is non-negotiable. Once the new URLs are live, you resubmit the sitemap so Google rediscovers them fast. On a large site, mapping and verifying thousands of URLs is simply more hours than building the templates.
This is also why a rushed migration is dangerous. Cutting the verify phase to hit a date is exactly how sites lose traffic. For the full sequence around this, see how to migrate a WordPress site to Lovable.
How to make your own migration faster
You can shorten the timeline without cutting corners. Give your migrator full access on day one, so there is no waiting on logins. Clean up obviously dead pages before the crawl, so fewer URLs need mapping. Decide upfront whether your domain is changing, because a domain move adds a Change of Address step. And review the staging link promptly, since the cutover waits on your sign-off.
For example, an owner who hands over access and reviews staging within a day often shaves several days off a two-week estimate. If you are still weighing platforms, Lovable vs WordPress for small business sites covers the decision before the clock starts.
Where does the time actually go?
Not into the design, which is what most people budget for. On a small business site the build is roughly a quarter of the elapsed time, and the rest is protecting what the old site earned.
| Stage | Share of the project | Can it be compressed |
|---|---|---|
| Inventory and exports | 10 to 15 percent | Partly, it is mostly waiting on a crawl |
| URL policy and redirect map | 20 to 30 percent | No, it needs judgment per row |
| Rebuild | 20 to 25 percent | Yes, this is the part that got fast |
| Content parity checks | 15 percent | Partly, with automation |
| Verification and launch | 10 percent | No, and compressing it is where projects fail |
| Post launch monitoring | Two to six weeks, low effort | No, it is calendar time |
The proportions explain why quotes vary so widely for what looks like the same job. A supplier quoting only for the rebuild row is quoting a quarter of the project, and the missing three quarters reappear later as a change request or as lost traffic.
What makes one migration slower than another?
Five factors, roughly in order of how much they move the schedule.
Archive size comes first. A 300 page site with eight years of posts generates thousands of addresses once paginated archives, tag pages, and attachment URLs are counted, and every one of them needs a decision.
Functionality is second. A brochure site has forms. A store has a catalogue, a checkout, tax rules, and a payment gateway with webhooks. A membership site has access logic that is a software project on its own.
Access is third and the most avoidable. Projects stall for days waiting on a registrar login, a hosting password, or DNS control that sits with a developer nobody has spoken to since 2021.
Content decisions are fourth. A migration where somebody also wants to rewrite the service pages is two projects sharing a deadline, and the writing is always the slower one.
Approval speed is fifth. A site cannot launch faster than its slowest reviewer, and one person on holiday during the staging review adds a week that no amount of technical preparation removes.
How do you actually make it faster?
By removing the waiting rather than by rushing the work, because the work is largely fixed and the waiting is not.
Gather access before day one: registrar, host, DNS, WordPress admin, analytics, and Search Console. That single step removes the most common source of dead days.
Export everything early, while the old site is live and nobody is under pressure: metadata from the SEO plugin, two years of analytics pages, and screenshots of every form’s routing. None of it is recoverable later from the public site.
Freeze content changes during the build. Every page edited on the old site after the inventory is captured is a page that has to be recaptured and rechecked.
Name one decision maker. Two people with different opinions about the homepage will cost more days than the entire redirect map.
And separate the rewrite. If the copy needs work, do it before or after, on the site that already exists, so the migration is only moving one variable.
When is a fast migration a bad idea?
When speed is being bought by cutting verification, which is the only stage where compression directly converts into risk.
A supplier who can rebuild a forty page site in three days is telling the truth about the build. If the same quote covers the inventory, the redirect map, parity checks, and launch day verification in that window, something on that list is not happening properly.
It is also a bad idea in a peak trading period, whatever the timeline. A store that makes a third of its revenue in six weeks should not be changing addresses during them, even if the work would technically fit.
And it is a bad idea when the team cannot be present. Launch week needs someone available to act on what the checks find, and a migration that goes live the day before everyone leaves for a fortnight will have its faults discovered by customers rather than by the people who could fix them.
What happens after launch, and how long does that last?
Two to eight weeks of low effort attention, and it is part of the timeline even though nobody is building anything.
The first week is active: verifying redirects, watching coverage in Search Console, and fixing whatever the checks surface. That is a few hours spread across seven days rather than a full time job.
Weeks two and three are quieter. Impressions dip and start recovering, new URLs move into the index, and old ones report as redirected. The correct action during this period is mostly to leave things alone, which is harder than it sounds.
Weeks four to eight are when the long tail returns. Old blog posts and images recrawl on their own slower schedule, so a site can look ninety percent recovered for a fortnight while the remainder works through.
Plan for the project to be genuinely finished around six to eight weeks after go live rather than on launch day. Suppliers who close the file at cutover are gone before the evidence arrives.
Key takeaways: how long a migration takes
Plan on about a week for a small site and one to two weeks for a typical blog, with larger and e-commerce sites running longer. The timeline is set by content volume and the redirect map, not by design. WPBuildAI commits to a fixed go-live date after crawling your site, so you get a real number instead of a range, and the verify phase is never cut to hit it.
What owners ask us most
How long does a website migration take?
Most sites go live in about one to two weeks. A small brochure site takes roughly seven days; a 50 to 200 post blog takes one to two weeks; e-commerce and multi-language sites take longer. WPBuildAI sets a fixed go-live date after crawling your site, because the timeline depends on countable things like page count and the number of URLs that need redirects, not on guesswork.
What makes a migration take longer?
The number of indexed URLs and the volume of content, because each URL needs a verified 301 and each post and image has to move and be re-linked. E-commerce adds product, checkout, and parameter URLs, which multiply the redirect work. Design complexity has surprisingly little effect; a large blog usually takes longer than a visually elaborate ten-page site.
Can a migration be done in a day?
For a very small, simple site with few indexed URLs, a one-day turnaround is sometimes possible, but it is the exception. Rushing a larger site means skipping the redirect verification that protects rankings, which is the one phase you should never cut. A firm short timeline is fine; a short timeline that drops verification is how sites lose traffic.
Does my site go down during the migration?
No. The new site is built and verified on a separate staging environment while your current site stays live. The switch happens only at cutover, when the domain points to the verified new site, so visitors never hit downtime. WPBuildAI cuts over only after the redirect map passes, which keeps the move invisible to your visitors.
Where does the time in a migration actually go?
Not into the design. On a small business site the rebuild is roughly a quarter of the elapsed time, while the redirect map takes twenty to thirty percent, the inventory and exports another ten to fifteen, and content parity checks around fifteen. That distribution is why quotes vary so widely: a price covering only the rebuild is a price for a quarter of the project.
How can I make my migration go faster?
By removing waiting rather than rushing work. Gather every login before day one, since projects stall for days on a missing registrar password. Export metadata, analytics, and form settings while the old site is live. Freeze content changes during the build. Name one decision maker. And keep any copy rewrite as a separate project, before or after.
Is the project finished on launch day?
No, and treating it that way is why some migrations look successful for a fortnight. Launch week is active verification, weeks two and three are a dip that should be left alone, and weeks four to eight are when the long tail of old posts and images recrawls. A project is genuinely finished around six to eight weeks after go live.
