Originally posted on April 17, 2024 @ 5:42 am
A website migration could take anywhere from a few weeks to over a year, depending on site size and migration scope. Smaller brochure websites with fewer than 100 pages can typically be migrated within 2–6 weeks, while mid-sized sites ranging from 100 to 10,000 pages may require 6–16 weeks to ensure proper structure, SEO continuity, and phased deployment. Ecommerce migrations, where every URL directly impacts revenue, often span 3–9 months due to the need for careful SKU-level redirects, staging validation, and traffic protection. At the enterprise level, migrations involving more than 10,000 URLs can extend to 6–12 months or longer, requiring large-scale SEO signal mapping, risk mitigation, and prolonged indexation recovery.
Key Takeaways
- Site complexity drives duration. Architecture depth, content interdependencies, redirect volume, and cross-functional coordination move the migration timeline.
- Compression transfers cost; it does not save time. Time pulled out of planning surfaces later as silent organic traffic loss.
- The most expensive errors are operational, not technical. A residual Disallow: / or sitewide noindex shipped from staging will outweigh every efficiency gained by compressing the schedule.
- Three disciplines determine survival: complete redirect mapping with no chain depth greater than one hop, controlled DNS cutover with TTLs lowered in advance, and post-launch stabilization measured in months, not days.
- Old infrastructure must stay live longer than most teams plan for. Google’s published guidance is to keep 301s in place for at least one year, and indefinitely from the user-experience perspective.
The Hidden Clock: Why Website Migration Duration Is Never One-Size-Fits-All
The ranges above are the output of a complexity equation that most organizations underestimate until the website migration process is already underway, and by then, the site migration risks have moved from theoretical to operational.
Site Complexity Is the True Timeline Driver, Not Just Page Count
URL count is one variable. Architecture depth, content interdependencies, accumulated technical debt, and platform legacy code multiply the timeline in ways no spreadsheet captures upfront.
A 5,000-page site on a modern headless CMS will migrate in roughly half the time of a 5,000-page site on a 12-year-old custom platform with hardcoded URLs and a redirect history accumulated through multiple prior CMS changes. Identical page count. Different complexity profile.
What Consistently Causes Migrations to Run Over Schedule
Five timeline-killers show up on nearly every project that misses its date:
- Incomplete redirect mapping discovered mid-execution rather than during planning. The largest source of post-launch organic traffic loss, almost always preventable.
- Underestimated team bandwidth across IT, marketing, and development. Migrations consume specialized hours that are rarely backfilled.
- Hosting provider limitations that throttle data transfer speeds. Particularly acute on ecommerce migrations with large media libraries.
- Scope creep from mid-migration design or structural changes. The “while we’re at it” problem — well-intentioned, always expensive.
- DNS propagation delays. Especially when TTL values were not lowered in advance of cutover.
Realistic Timelines Broken Down by Site Size and Migration Scope
Each profile below follows the same internal pattern: definition, phased timeline, common bottlenecks, and why the minimum cannot be safely compressed.
Brochure and Small Business Websites: 2 to 6 Weeks
A brochure site is typically under 100 pages with minimal dynamic content and a single content owner, usually a marketing manager handling other priorities.
Phased timeline:
- Weeks 1–2: Discovery audit, redirect mapping, staging environment configuration
- Weeks 3–4: DNS cutover, content migration verification, initial crawl testing
- Weeks 5–6: Indexation confirmation, early performance tracking
Common bottlenecks:
- Single-person team bandwidth, with one marketing manager often owning the project end to end
- Overlooked canonical tag errors during template migration
- Underestimated content review and approval cycles
Why the 2-week minimum buffer is non-negotiable: Google’s published guidance notes that even medium-sized sites take “a few weeks for most pages” to move through the index after a site move. Practitioner experience puts the small-site cycle at roughly two weeks. Anything shorter is a launch date, not a verified migration.
Mid-Size Business Websites: 6 to 16 Weeks
Mid-size sites range from 100 to 10,000 pages with moderate taxonomy and some dynamic functionality — filtered listings, blog architecture, basic personalization. Many run on hybrid stacks: modern frontend over a legacy CMS, or vice versa.
Phased timeline:
- Weeks 1–3: Site structure audit, full redirect mapping, platform migration scoping
- Weeks 4–8: Staging build, internal link integrity testing, SEO migration protocol implementation
- Weeks 9–12: Phased deployment, DNS propagation monitoring, real-time crawl error resolution
- Weeks 13–16: Post-migration monitoring, traffic recovery assessment, indexation gap analysis
Common bottlenecks:
- Hidden content dependencies — legacy pages internally linked from places no one remembers building
- Cross-team coordination between marketing, development, and external partners
- Mid-project scope creep at organizational scale
Why mid-size carries the highest risk of underestimation: This is the bracket where leadership most often assumes the project is “not that big.” The page count looks manageable and the timeline gets compressed. By week four, the operational complexity has surfaced and the deadline has been committed to externally. This is where a structured migration planning template earns its weight.
Ecommerce Websites: 3 to 9 Months
Ecommerce migrations have one defining characteristic that brochure and mid-size projects do not: every page in the catalog generates revenue, and every hour of degraded performance is measurable in dollars.
Phased timeline:
- Months 1–2: SKU-level redirect mapping, structured data audit, hosting provider evaluation
- Months 2–4: Staging stress testing, data transfer validation, platform configuration
- Months 4–6: Phased execution to protect revenue-generating pages during deployment
- Months 6–9: Extended stabilization — crawl budget reallocation, seasonal traffic recovery
Common bottlenecks:
- SKU-level redirect mapping volume, often tens of thousands of URLs
- Structured data preservation across product pages
- Coordinating execution windows around peak revenue periods
The structured data point deserves a sharper look. Product schema, breadcrumb schema, and review schema all need to migrate intact — and on platform migrations they almost never do without manual intervention. Review counts and aggregate ratings are particularly fragile: they’re often pulled from a third-party platform via tags rebuilt during migration. Google’s own structured data documentation cites case-study CTR uplifts of 25% (Rotten Tomatoes) and 82% (Nestlé) for pages with rich-results markup — the inverse holds when that markup breaks. A site that ships with broken review schema can drop product page click-through rate by double-digit percentages within weeks. That damage is invisible in traffic data and devastating in revenue data.
Compressed timeline savings vs. revenue-at-risk during a botched cutover: The math almost never favors compression. A two-week traffic dip on a high-revenue site can outweigh the entire cost of a properly scoped project.
Enterprise and Large-Scale Websites: 6 Months to Over 1 Year
Enterprise migrations move tens of thousands to millions of URLs across multinational domains and deeply integrated martech stacks. The work is no longer about a website — it’s a coordinated technical program with implications across multiple business units.
Phased timeline:
- Months 1–3: International SEO signal mapping, domain migration risk assessment
- Months 3–6: Redirect mapping at scale, cross-functional coordination, full staging replication
- Months 6–9: Controlled execution with phased deployment milestones
- Months 9–12+: Long-tail indexation recovery, authority signal consolidation
Common bottlenecks:
- Cross-functional coordination across marketing, IT, security, legal, and regional teams
- International SEO signal preservation
- Project governance — dedicated PMO infrastructure separate from day-to-day IT operations
On multinational migrations, hreflang preservation is table stakes. The hard problem is return-tag reciprocity validation: every language and region pair must declare its counterpart, and counterparts must declare back. Google’s guidance is explicit — if two pages don’t both point to each other, the tags will be ignored. Validating this across tens of thousands of URL pairs takes weeks post-cutover, and a single broken reciprocal tag can cause search engines to ignore the affected hreflang annotations and, on tightly-coupled clusters, undermine the broader cluster’s reliability. This is why multinational migrations add 2–4 months — not because hreflang is hard to implement, but because validating it at scale is a discipline of its own. Organizations running this scope often need domain migration expertise alongside enterprise SEO support.
Site size sets the baseline. The disciplines that protect SEO performance through every phase determine whether the timeline holds.
The SEO Survival Framework: Protecting Search Visibility Across Every Migration Phase
Three operational disciplines determine whether an SEO migration timeline survives execution: redirects, DNS, and the weeks after launch.
Redirect Mapping as the Single Most Time-Intensive Pre-Migration Task
Redirect mapping volume directly correlates with project timeline length. The discipline isn’t writing redirects — that part is mechanical. The discipline is discovery: a crawl-first methodology that uses pre-migration crawl data to build an exhaustive map before deployment, including every URL the site has historically returned a 200 response on, plus every URL still linked from external sites.
Redirect to the final destination directly, with no chain depth greater than one hop. Google’s documented baseline is more permissive — Googlebot can follow chains, with a tolerance of “no more than 3 and fewer than 5” — but each hop in a migration of this scale bleeds equity and increases the probability of a 404 mid-chain when the old infrastructure is decommissioned. On enterprise migrations, discovery routinely surfaces existing chains four to six hops deep that have to be flattened before the new map can be written cleanly. This is the most common reason redirect mapping takes months at enterprise scale, not weeks.
Redirect Map vs. Implemented Redirects: The redirect map is the planning artifact: every old URL, its new destination, and the redirect type. The implemented redirects are the live infrastructure on the new server. The map must be complete, reviewed, and approved before any redirects go live.
Treat the map as a deliverable in its own right with its own sign-off. A complete website migration checklist prevents the most common compression error — treating the map as something the development team will “handle during build.”
DNS Propagation and Server Migration: The Invisible Timeline Extender
The standard 24–72 hour propagation window is a floor, not a ceiling. Actual propagation depends on TTL values configured before cutover, downstream resolver caching across ISPs, and audience geography.
One discipline turns DNS propagation from a guessing game into a predictable event: lower the TTL value to 300 seconds — five minutes — at least 24 to 48 hours before cutover. Resolver caches refresh quickly and propagation behavior becomes observable in near real time. Skipping this step is the most common cause of phantom downtime reports following launch: traffic is finding the new server, but stale resolver caches are still routing some users to the old one. The fix is trivial in advance and impossible after the fact. Google’s documentation on site moves and URL changes reinforces the principle: predictability matters more than speed.
Post-Migration Stabilization: The Phase Most Teams Abandon Too Early
Stabilization is where the project plan ends but the work does not. Premature closure causes delayed ranking losses that surface weeks later, when the team that ran the migration has moved on. The cost is borne by the marketing director who signed off on launch.
The standard cadence — daily indexation checks for the first two weeks, weekly through month three — is the right shape but the wrong tool. Google Search Console’s page indexing report typically updates on a several-day lag. That makes daily GSC monitoring useful for trend-spotting but useless for catching active crawl problems. The professional cadence for the first two weeks is daily server log-file analysis: watching how Googlebot is crawling the new site in real time, what status codes it’s hitting, and whether redirect chains are resolving cleanly.
A second discipline almost never makes it into a project plan, and it should. Decommissioning the old infrastructure too early is one of the highest-cost post-launch errors. Search engines may take 30 to 90 days at enterprise scale to fully transfer authority signals through redirects. Google’s published guidance is to keep redirects in place “as long as possible, generally at least 1 year,” and indefinitely from the user-experience perspective. At enterprise scale, twelve months is the operational floor.
Five Signals That Should Trigger Immediate Post-Migration Investigation
- Crawl rate drops by more than 30% in the first 14 days. Redirect signals or sitemap submissions aren’t being processed cleanly.
- Index coverage shows new “Excluded” or “Crawled — currently not indexed” pages in volume. Especially on pages with stable indexation pre-migration.
- Organic traffic to specific page templates drops disproportionately. Sitewide dips usually indicate DNS or redirect issues; template-specific dips usually point to canonical, hreflang, or structured data problems.
- Server logs show 404s on URLs that were supposed to be redirected. A clear sign the redirect map was incomplete or implementation diverged from the plan.
- Branded search rankings drop. Branded queries are the slowest to lose rankings, so when they move it almost always means a deeper problem — title tag corruption, robots.txt errors, or a retained noindex directive.
Building a Migration Timeline That Accounts for Real-World Constraints
How Resource Availability Reshapes Every Timeline Estimate
Internal team bandwidth is the most underestimated variable in a website migration project plan, and it’s rarely a function of headcount. It’s a function of available hours, which is always smaller than total hours. A six-person SEO team running a migration doesn’t stop running paid search support, content production, and reporting cycles. Two scheduling constraints follow. First, business calendar conflicts — peak revenue windows, fiscal year-end, product launches — create hard exclusion zones for cutover. Second, contingency buffers belong in each phase rather than appended to the end; end-of-project buffers always get consumed by mid-project slips.
Milestones, Go/No-Go Gates, and the Decision Framework That Prevents Premature Launch
Every phase should end at a non-negotiable go/no-go gate with criteria defined in advance. Milestone-based project management prevents scope creep from quietly extending the timeline, and gives the marketing director a defensible reason to delay launch when the gate isn’t met. A delayed launch is always less costly than a botched migration that erases years of organic search authority.
The most expensive single-line error in migration history deserves emphasis: shipping a Disallow: / in robots.txt, or a sitewide noindex meta tag, from staging to production. Google’s documentation is blunt about the consequence — when Googlebot extracts a noindex rule, “Google will drop that page entirely from Google Search results.” Senior leads make this the first item verified at the staging sign-off gate, not the last — via a direct manual fetch of the live robots.txt file. They then re-verify with a view-source on three randomly selected production URLs immediately after cutover. Verify by hand.
Staging Environment Sign-Off Checklist
- Production robots.txt fetched and verified — no Disallow: / carried forward from staging.
- Sitewide meta robots verified on a random sample of templates — no residual noindex directives.
- Redirect map fully implemented — every old URL returns a 301 to the correct new URL with no chain depth greater than one hop.
- XML sitemap regenerated against the new URL structure and submitted via Google Search Console.
- Canonical tags verified on all template types — self-referencing where appropriate, no cross-domain canonicals carried over from staging.
- Hreflang tags (where applicable) validated for return-tag reciprocity across all language and region pairs.
- Analytics tracking reconfigured and firing correctly on a representative URL set.
- Google Search Console property verified for the new domain or URL structure, with a Change of Address request submitted where applicable.
- Structured data validated on representative pages of every template type.
- Internal linking integrity confirmed — no internal links pointing to old URLs creating unnecessary redirect hops.
Treating Migration Timelines as a Risk Management Decision, Not a Deadline
The honest answer to how long does website migration take is the same answer as how much risk are you willing to absorb. Compression doesn’t save time. It transfers cost from the project plan onto post-launch organic performance, where it surfaces as silent traffic loss and lost revenue, usually one quarter after the project was declared complete.
Three questions belong on the agenda of every leadership meeting where a migration launch date is being signed off:
- Has every URL on the current site been crawled, mapped, and assigned a destination on the new architecture, with no chain depth greater than one hop?
- Is the staging environment verifiably blocked from indexation, and has the production environment been spot-checked manually for residual noindex or Disallow: / directives within the first hour of cutover?
- Is the post-launch stabilization budget — including daily log-file analysis for the first two weeks and old-infrastructure retention for at least twelve months — already approved and resourced, or is it the first thing leadership will try to cut?
If your answers feel less certain than the launch date already committed to publicly, the conservative move is to plan and execute your migration with experienced practitioners. Site complexity drives timeline. Defensible ranges, complete redirect maps, controlled cutovers, and stabilization measured in months are the four things that separate migrations the marketing director gets to take credit for from the ones that quietly cost the company a quarter of its organic revenue.
