How Long Does a Website Migration Actually Take?

Ask three agencies how long a migration takes and you will hear "overnight", "two weeks" and "it depends". All three are describing different jobs. Break the timeline into its parts and you can tell a realistic schedule from a reckless one.

What the days are actually spent on#

A migration is five distinct phases, and only one of them is the rebuild everyone pictures.

Audit (day 1–2). Crawling the site, exporting Search Console, inventorying every URL, drafting the redirect map, finding the things that cannot transfer. This phase determines whether the rest goes smoothly; skipping it does not save time, it defers the time with interest.

Rebuild (day 2–5). Recreating pages on the new platform, migrating blog archives, rebuilding forms, carrying over titles and metadata. Scales with page count more than anything else.

Review (day 5–6). You, looking at the staging site, requesting changes. This phase belongs to the client, it takes as long as your availability allows, which is worth knowing when you plan around a deadline.

Cutover (hours). DNS change at a quiet hour. The famous part, and the shortest. How a site moves without downtime explains why both sites are live during the changeover, and why your email is untouched.

Verification (day 7, then ongoing). Re-crawling the old URL list, confirming every redirect resolves, submitting sitemaps, checking robots.txt and noindex, then watching Search Console. The unglamorous phase that decides whether your rankings survive.

Realistic timelines by site type#

Brochure site, up to 10 pages: about a week. The audit and verification take nearly as long as the rebuild, which is correct, because they carry most of the risk.

Content site, 10–30 pages with a blog: 7–10 days. Blog archives move faster per-page than hand-built pages (Wix exports posts), but URL mapping for dated blog paths needs care.

E-commerce, up to ~500 products: 10–14 days. Stores add catalog reshaping, customer and order imports, payment and shipping configuration, and checkout testing, each its own failure domain.

Larger or unusual sites: quoted individually. An 80-page site with three languages and a members area is not a tier, it is a project.

What stretches a timeline (legitimately)#

• Content volume, obviously, but less than linearly, since setup costs amortise.
• App complexity. Every Wix app is a question: does its data export, and what replaces it? Some questions take a vendor support ticket to answer.
• Client review speed. The most common real-world delay is the staging site sitting unreviewed for a week. Block an hour for review the day it arrives and you have shortened your migration.
• DNS TTL. Not the propagation myth, modern DNS moves in minutes if TTLs were lowered ahead of time. But if nobody lowered them, the old values can linger for a day or two. A competent plan handles this before cutover, not during.
• Domain access archaeology. "Who has the registrar login" has delayed more migrations than any technical factor. Find out on day one.

About the overnight offers#

You can absolutely move a site overnight. What you cannot do overnight is the audit before it and the verification after it, the two phases that exist purely to protect your traffic.

An overnight migration is a rebuild with the protective phases amputated. Nothing looks wrong the next morning; the damage surfaces over the following six weeks as unmapped URLs 404 and rankings quietly reassign. By then the person who did the overnight job is gone.

When we take genuine rush jobs (it happens, expiring subscriptions, legal deadlines), the compression comes from working the phases in parallel and overnight, not from deleting them. That is why rush work costs more rather than the same: the protective steps still happen, just under pressure.

The part of the timeline nobody bills for#

Full ranking stabilisation takes four to eight weeks after launch. Google re-crawls every URL on its own schedule, and nothing accelerates it much. This is not project time (nobody is working during it), but it is calendar time you should expect: the migration is not "proven" the day it ships, it is proven when Search Console has been quiet for a month.

Plan accordingly: do not schedule a migration to land three weeks before your peak season. Land it three months before, or after.

Two things that follow from this#

The settling period is the part nobody schedules. The four to eight weeks after cutover are when search engines re-crawl and re-evaluate every redirected address, and knowing the shape of a normal recovery is what stops a routine dip being mistaken for a disaster. That is covered in how long SEO takes to recover after a migration.

The launch date matters as much as the schedule. Because of that settling period, landing a migration three weeks before your peak season is the most expensive timing mistake available. When to migrate a website covers the quiet window by industry and the deadlines that force bad timing.

The short version#

About a week for most sites, two for stores, longer only for genuinely larger jobs. The schedule is audit → rebuild → review → cutover → verification, and the phases that look skippable are the ones protecting your traffic. Distrust "overnight" for anything whose rankings you value, the speed comes from skipping the steps you cannot see.