Web migration mechanics

Overview

Web migration mechanics describes the technical and operational discipline of moving a website from one platform, CMS, or domain to another without destroying organic search performance, editor workflow, or revenue. The Candid Creative knowledge base treats migration as a discrete failure event: the platform the client lands on gets blamed regardless of whose decision broke the redirects, so the redirect map, the cutover pattern, and the post-launch monitoring window are non-negotiable deliverables. This page consolidates the primary-sourced statistics, the failure-mode catalogue, the pricing bands, the cutover pattern, the content-extraction decision tree, the feature-parity replacement table, the objection-handling map, the redirect-map specification, and the "when not to migrate" counter-cases that govern every Candid migration engagement. Where stats are widely circulated but single-sourced, this page flags them as such; where Google's own documentation provides a primary quote, the quote is preserved verbatim. For the underlying research brief, see Research brief: The Candid Creative WordPress Migration Playbook (piece 19).

The "9 of 10 fail" stat — single-sourced, do not lead with it

The widely repeated industry claim that "Only 1 in 10 website migrations result in improved search engine rankings. Nine out of ten fail." traces to a single source: the numentechnology.co.uk case study published in 2024-2025, citing unnamed analysis. The companion claim that botched migrations produce a 50% traffic loss comes from the same source.

Confidence: single-source. The 9-of-10 figure could not be located in any peer-reviewed or government-published source. Candid Creative does not lead with this statistic in public-facing writing. Where the framing is referenced, it is attributed explicitly to Numen Technology and flagged as single-source — it does not stand in as industry consensus. This is exactly the kind of recycled stat the cite-with-named-source-and-url rule catches.

The defensible replacement statistic is Dan Taylor's Search Engine Journal study, discussed in the next section.

The SEJ 892-migration study — domain-to-domain, not same-domain CMS swaps

The Search Engine Journal study most frequently cited in migration discussions is Dan Taylor's "How Long Should An SEO Migration Take? [Study Updated]" — published January 9, 2025, data collated October 22, 2024, n=892. It is the multi-sample, primary-source benchmark that should be used instead of the Numen 9-of-10 framing.

Verbatim from the study: "On average, it took 523 days for Domain B to show the same level of organic traffic as Domain A. 17% of domain migrations in the sample didn't see organic traffic return to the same levels after 1,000 days."

Methodology: Ahrefs estimated organic traffic, comparing Domain B to Domain A.

The critical scoping detail every advisor must internalize: the SEJ dataset measures domain-to-domain migrations (example.com to example.io). Same-domain CMS swaps are not in this dataset. Citing the 523-day / 17% number to a same-domain client is dishonest; ignoring it for a domain-change client is malpractice.

The earlier n=171 reading of the same study reported 42% of sites never recovering after 1,000 days. The n=892 update brought that figure down to 17%. Taylor verbatim: "17% of migrations did not recover after 1,000 days, though this is an improvement from 42% in the previous study." Industry citations of "42% never recover" are now out of date and should not be used.

Confidence on the methodology scope and the headline number itself: high.

Same-domain CMS migration recovery timeline

For the migration profile Candid Creative does most often — same-domain CMS swap with complete 1:1 redirects — the realistic recovery timeline is far shorter than the 523-day domain-migration average:

• Same-domain CMS swap, complete 1:1 redirects, no URL restructure: plan for 2-4 weeks of crawl turbulence and 4-8 weeks to full stability. Confidence: medium-high.
• Same-domain with URL restructure: 4-12 weeks. Google Search Central's site-move-with-url-changes documentation: "A medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." Confidence: medium.
• Domain change + CMS swap: the 523-day SEJ average applies. Plan for 6-18 months and tell the client explicitly. Confidence: high.

A common framing in agency writing — "weeks not months" — is often attributed to John Mueller. The primary source exists but it is narrow. The verbatim quote ("maybe a week or two, maybe up to three weeks… one, two, three weeks, something around that range") is from a February 19, 2021 Google Search Central Office Hours, reported by Roger Montti at SEJ. It was specifically about AMP URL crawl settlement after a parked-domain move, not a general statement about CMS migration recovery. The widely-circulated "4-12 weeks for a medium site" framing is agency synthesis, not a Mueller primary source.

Per the SEJ study, Numen Technology, and credible practitioner post-mortems, the "migration penalty" is execution, not algorithmic. Reproducible failure modes appear in order of frequency:

1. Incomplete redirect map (missing attachment URLs, pagination, archives).
2. Soft 404s — pages that "exist" on the new site but are empty templates.
3. Schema dropped without replacement.
4. Staging environment accidentally indexed before cutover.
5. Redirects implemented as 302 instead of 301.
6. Redirect chains (old → intermediate → final).

The full catalogue is detailed below.

Web migrations can succeed with discipline

The strongest objection to migration is "migrations always fail." They do not. Documented case studies show 3× and 5× traffic gains when migration is executed with: complete 301 redirect mapping, content preservation, pre-launch redirect testing, and post-launch monitoring.

Sources: BrightEdge migration case studies; Numen Technology 2024-2025 case studies. Confidence: industry-consensus (vendor-published; specific named cases).

This counter-evidence matters because it defangs the strongest objection to migration. The honest framing is: migration is expensive and risky by default, but the risk is recoverable with discipline. This framing also justifies pricing the engagement on the discipline rather than on raw hours — the buyer is paying Candid Creative to execute the failure-prevention checklist, not to type code faster.

Hidden killers catalogue — the seven failure modes in every post-mortem

These reproducible failure modes appear in every credible migration post-mortem. Each is mitigatable; each is catastrophic if missed.

1. The "thousands of attachment URLs" mistake. A photographer's WordPress site with 800 portfolio images can have 5,000+ indexable attachment pages. Per the WordPress.org support forum: "Thousand of attachment urls are automatically indexed, How do I remove them?" Forgetting them is the #1 cause of post-migration crawl errors.

   • Mitigation: audit /wp-json/wp/v2/media and the XML sitemap before scoping.

2. ACF custom-field data silently dropped. ACF fields not exposed via REST (the default for fields registered before the ACF-to-REST plugin was installed) won't appear in the JSON export.

   • Mitigation: WP-CLI dump of postmeta and an explicit ACF audit. Catastrophic if discovered mid-migration.

3. Page-builder pages that "look fine" in staging but are empty templates. Elementor and Divi render via shortcode at request time; a naive REST export returns mostly empty post_content.

   • Mitigation: always render the live page and use that HTML, not the API response.

4. Staging accidentally indexed before launch. A robots.txt disallow does NOT stop indexing if pages are linked from elsewhere. John Carey's post-mortem: "I've seen migrations where the staging site was accidentally indexed by Google before launch, creating duplicate content issues and cannibalising the live site's rankings."

   • Mitigation: HTTP-header-level noindex, IP allowlist, basic auth, and a Vercel/Netlify preview-deployment password. All four, belt-and-suspenders.

5. Schema dropped without replacement. Yoast and Rank Math inject Article, FAQ, and Organization schema invisibly. Post-migration the new site has zero schema and gradually loses rich results in SERPs.

   • Mitigation: schema audit as a separate audit deliverable. Bake equivalents into the new stack's templates.

6. Client editing workflow rejection post-launch. Client logs in to Sanity Studio once, gets confused, asks why they can't "just drag the headline bigger like in Elementor," relationship sours.

   • Mitigation: 2-hour scheduled onboarding session, recorded; client-specific Loom walkthrough; 30-day "ask anything" support window built into the price.

7. Cutting redirects too early. Cutting redirects at 30/60/90 days destroys recovered traffic. Industry standard is 12 months minimum. Detailed under the redirect retention rule below.

Objection-handling map — verbatim answers to the common fears

These are the sourced answers to the questions every client asks before signing a migration contract. They are intended for use verbatim in sales conversations and in the public-facing Migration Audit article.

Fear: "I'll lose my Google rankings." For a same-domain migration with a proper 1:1 redirect map, recovery is measured in weeks, not months. The 523-day / 17%-never-recover stat is from a January 2025 SEJ study measuring domain migrations (example.com → example.io) — not same-domain CMS swaps. Taylor's verbatim line: "On average, it took 523 days for Domain B to show the same level of organic traffic as Domain A." That is not what is happening in a same-domain CMS swap. Candid keeps the domain, keeps the URLs, and 301s the few that need to change. Numen's analysis: 9 out of 10 failed migrations failed because of execution mistakes, not algorithmic punishment.

Fear: "My editor won't know how to update the site." Candid matches the editing experience to the client's actual workflow. Weekly editing with multiple people → Sanity Studio + Presentation tool (click on any block on a live preview and edit it). Monthly solo edits → Keystatic (clean form interface). Either way: 2-hour onboarding session, recorded walkthrough specific to the site, 30 days of "ask anything" support. The few clients who struggle usually had unrealistic expectations of a Gutenberg-style page builder, which is set straight upfront. See [[cms-workflow-decision-matrix]].

Fear: "What about my 200 blog posts?" 200 posts is a 1-2 day migration. Candid pulls them out of WP via its REST API (built in since WP 4.7, late 2016), converts to markdown in Git or structured content in Sanity, rewrites every internal link, re-uploads every image, and URLs stay identical. The hard part is not the 200 posts — it is the thousands of attachment URLs WordPress quietly created for each image uploaded. Candid handles those too, and that is exactly what the audit catches before the client signs the build contract.

Fear: "I won't be able to add new pages without calling a developer." For 95% of new pages the client will ever want — a new service page, case study, team member, location — the CMS interface handles it without code. Cases where a developer is needed: changing global navigation, adding a new page template (not a page), integrating a new third-party tool. Those are bigger asks on WordPress too.

Fear: "What if I want to go back to WordPress later?" The content lives in markdown files in a Git repo, or in Sanity's structured JSON. Both are exportable, portable, and far easier to migrate into a new system than WordPress's HTML-plus-shortcode soup is to migrate out of. WordPress's own importer accepts markdown and structured content.

Fear: "My site looks fine. Why am I doing this at all?" This is the most important question. If the site is performing well, editors are happy, and the only complaint is "WordPress feels old," Candid will tell the client to spend $50/month on better hosting and call it done. Migration is worth it when: (a) CWV are failing and costing rankings, (b) the client is paying $200+/month in plugin licenses they don't use, (c) editor experience is actually broken (Elementor crashes, plugin conflicts), or (d) the client wants something WordPress fundamentally cannot do (same content delivered to a mobile app). If none of those apply, Candid refers the client to a good WP maintenance shop. That is what the audit is for: telling the truth.

Fear: "What about downtime during cutover?" With DNS TTL pre-lowered to 300 seconds and a Cloudflare-in-front pattern, real downtime is typically under 60 seconds globally and zero seconds for cached pages. Cutover happens at the client business's lowest-traffic hour (verified in GA4). WordPress stays alive behind a firewall for 30 days as the rollback target — if anything goes wrong, DNS reverts and the world sees the old site within 5 minutes.

Candid migration pricing bands — 2026

Realistic fixed-fee bands for WordPress → modern-stack migrations, 2026:

Site profile	Fixed-fee range	Timeline	Notes
10-page brochure, no blog, Astro + Keystatic	$3,500 – $7,000	2-4 weeks	High-margin if templated
50-page site + 100-post blog, Astro + Sanity	$8,000 – $18,000	4-8 weeks	The sweet spot for productization
200-page content-heavy site, Next.js + Sanity, multilingual-capable	$20,000 – $45,000	8-16 weeks	Often needs a content audit phase first
Headless WordPress (keep WP, replace frontend with Next.js)	$12,000 – $28,000	5-10 weeks	Cheaper content migration; more expensive ongoing infra

These bands align with published industry benchmarks:

• Multidots (published WP agency pricing): "Basic business sites, i.e., informational pages built with premium themes and standard plugins, typically cost $3,000-7,000."
• Seahawk Media entry point: "$499 and fully customizable" for content-only migrations.
• Enterprise multi-thousand-article migrations: $80K-$150K.

Multipliers that blow up the timeline and the budget:

• Elementor / Divi / Bricks page-builder content: ×1.5-1.8
• ACF-heavy custom layouts (>20 custom field groups): ×1.3
• WooCommerce of any complexity: ×1.5-2.0
• Multilingual (WPML/Polylang): ×1.5-2.0
• Membership / gated content: ×1.4
• LearnDash / Tutor LMS courses: ×2+ (genuinely consider not migrating)
• 1,000+ blog posts with image-heavy bodies: ×1.3 for image-rewrite scripting alone

Every migration engagement begins with a paid Migration Audit before any fixed-price build quote is issued — see the next section.

Rule — lead with the $1,250 paid Migration Audit

Rule: Every Candid Creative WordPress migration engagement begins with a paid Migration Audit & Risk Register at $1,250 fixed.

Audit deliverables (one document):

1. Full URL inventory with GSC traffic + Ahrefs/Semrush backlink overlay.
2. Redirect map skeleton — CSV: old URL → new URL → notes. Includes attachment pages, pagination, archives, feeds.
3. Page-builder / ACF complexity scorecard — count of Elementor/Divi/WPBakery pages, ACF field groups, custom post types, custom plugins.
4. Recommended target stack with rationale, anchored on [[rule-prefer-astro-cloudflare-default-marketing-site]] unless a flip condition applies.
5. Fixed-fee quote for the build.
6. "Do not migrate" verdict where appropriate.

The audit is the marketing wedge. It is the artifact prospective clients can show their stakeholders. It converts hand-wavy fear into a one-page risk register and gives Candid a profitable, low-risk entry point.

T&M is appropriate only when the source site is a known black box (acquired site, no original developer, undocumented custom plugins).

Threshold to standardize further: once 5 paid audits are closed, normalize the template and offer at the same price.

Cutover pattern — low-risk same-domain CMS migration

The standard low-risk cutover for a CMS-only migration on the same domain:

1. Build on staging.example.com with noindex enforced at the HTTP-header level (NOT just robots.txt — robots.txt does not stop indexing if pages are linked from elsewhere). Pair with IP allowlist + basic auth + framework preview-deployment password.

2. Two weeks before cutover: crawl staging with Screaming Frog, diff against production crawl, resolve every 404/3xx.

3. One week before cutover: lower DNS TTL on apex and www records to 300 seconds.

4. Cutover window (low-traffic time, never Friday):

   • Take a fresh DB snapshot of WordPress.
   • Swap the DNS A/CNAME record(s).
   • Watch traffic shift in Cloudflare/Vercel/Netlify analytics in real time.
   • Verify 50 random URLs return 200 on the new stack.
   • Verify 50 random old URLs that should be redirected actually redirect.

5. First 48 hours: monitor Google Search Console Coverage report. Set up host-platform alerts on 5xx and 4xx spikes.

6. Keep WordPress alive (firewalled, on a subdomain like wp.example.com accessible only by IP allowlist) for at least 30 days as the rollback target.

7. Rollback plan: DNS revert. With TTL at 300s, the world sees the old site within 5 minutes.

Cloudflare-in-front pattern for piecewise migration: put Cloudflare in front of both old and new origins; use Workers or Page Rules to route specific paths (/blog/* → new Astro origin, everything else → WordPress origin). Migrate path-by-path. The right pattern for large sites (200+ pages); the only sane way to do a 1,000+ post blog without a multi-week dark period.

Content extraction decision tree

The decision tree for extracting WordPress content during migration:

• WP REST API (/wp-json/wp/v2/posts, /pages, /media) — default choice for any WP 4.7+ site. Reliable, supports custom post types if show_in_rest => true. Sanity's official migration course documents this end-to-end.
• WXR XML export (Tools → Export) — when REST API is firewalled; one-shot full archive; WordPress.com source sites via OAuth. WXR includes references to attachments but not the binary media files.
• Direct DB query (WP-CLI wp db export or MySQL dump) — only when raw postmeta rows are needed that are not exposed via REST. Typically ACF data or custom post-meta fields registered without REST exposure.

Page-builder content handling:

Source	Storage format	Extraction reality
Gutenberg	HTML + <!-- wp:blockname --> comments	Cleanly parseable. @wordpress/block-serialization-default-parser converts to AST → Portable Text / MDX.
Classic editor	Plain HTML	Trivial. Use turndown to convert to markdown.
ACF fields	Serialized PHP in postmeta; exposed via REST with ACF-to-REST or WPGraphQL-for-ACF	Manageable if planned; catastrophic if discovered mid-migration. Always audit ACF first.
Elementor	JSON blob in postmeta._elementor_data	Essentially un-portable. Rebuild pages from screenshots. No clean Elementor→markdown/Portable Text path exists.
Divi	Shortcodes in post_content	Rebuild, don't convert. Severe lock-in. See Divi 4 stored content as proprietary et_pb_* shortcodes — orphan text on theme deactivation (Divi 5 fixes this).
Bricks	JSON in postmeta._bricks_page_content_2	Rebuild.

Image migration (where projects overrun):

1. Export /wp-content/uploads/ via SFTP or WP-CLI (wp media export).
2. Upload to new host (Cloudflare Images, Sanity CDN, Vercel Blob, or new repo public/).
3. Rewrite every <img src> and every markdown ![alt](path) in migrated content. Regex against old domain + /wp-content/uploads/.
4. Regenerate responsive sizes via new stack's image pipeline.
5. Budget time for this — Outsourcify (7,000-article migration) flagged it as a major engineering challenge.

Internal link rewriting: a one-shot script scanning all body content for https://oldsite.com/... or relative /2019/... patterns and rewriting them.

Comments: for SMB sites with <500 lifetime comments, sunset gracefully — export to JSON, archive, replace with Giscus (GitHub Discussions). For active commenter communities, migrate to Disqus or keep WordPress headless.

Feature-parity replacements — WordPress to modern

The feature-parity replacement table for WP migrations:

WordPress plugin/feature	Replacement	Notes
Contact Form 7 / Gravity Forms	Resend + Next.js server actions, or Web3Forms (no backend), or Formspree, or Netlify Forms	Server actions cleanest for Next.js; Formspree/Web3Forms lowest-friction for Astro
Yoast / Rank Math SEO	Next.js metadata API or Astro <SEO> component + manual schema	Loss of in-editor SEO UI is real; Sanity/Storyblok have third-party SEO plugins
Native WP search	Pagefind (default — free, build-time, sub-300KB index for most SMB sites) or Algolia (typo tolerance / analytics) or Meilisearch (self-hosted, faceted)	Pagefind's docs claim "a full-text search on a 10,000 page site with a total network payload under 300kB"
WP comments / Disqus	Giscus (GitHub Discussions), or no comments	Most SMB sites should just remove comments
WooCommerce (simple)	Stripe Checkout + custom Next.js, or Lemon Squeezy, or Shopify Buy Button on an otherwise static site	Full Shopify migration is overkill for <20 SKUs
Membership plugins	Clerk, Auth.js, Outseta	Plan for $25-99/month recurring cost the client may not be expecting
Newsletter (Mailchimp embed)	Buttondown, ConvertKit, Beehiiv, Resend Broadcasts	Resend Broadcasts most developer-friendly; ConvertKit/Beehiiv if client wants to send sequences themselves
Analytics (Jetpack / GA via plugin)	Plausible, Fathom, Cloudflare Web Analytics, GA4	Plausible/Fathom privacy-friendly defaults; Cloudflare free if already on their CDN

Form submission history: always export and archive separately; never expect to migrate it into the new system. Stripe checkout history, Mailchimp lists, etc. are separate concerns.

Redirect map deliverable specification

The redirect map is the single most consequential deliverable in a same-domain migration.

Format: CSV with columns old_url, new_url, status_code, notes. Default status_code = 301.

Build it by combining four sources:

1. WordPress XML sitemap (/sitemap_index.xml from Yoast/Rank Math/AIOSEO).
2. Screaming Frog crawl of the live site.
3. Google Search Console Performance report — top URLs by impressions over the last 12 months.
4. Ahrefs/Semrush — URLs with external backlinks.

Edge cases that consistently cause traffic loss:

• Attachment pages (WordPress auto-creates one indexable page per uploaded image) — 301 to parent post, or 410 if no parent.
• Author archives (/author/janedoe/) — usually safe to 301 to /about/, or 410.
• Date archives (/2019/03/) — almost never have inbound links; 410 is appropriate.
• Category pagination (/category/news/page/4/) — preserve at least first 2-3 pages.
• Feed URLs (/feed/, /category/news/feed/) — preserve at root level (/rss.xml is modern convention; /feed/ should redirect).

Sitemap continuity: keep the old sitemap.xml resolving (with 301'd URLs) for at least 30 days post-cutover. Submit the new sitemap immediately. Because the domain is unchanged, do not use Search Console's Change of Address tool — Google's docs say explicitly: "Don't use the Change of Address tool for the following moves: Changing address from http to https… Moving some pages from one location to another within your site."

Retention rule: maintain redirects for at least 180 days. Google: "Maintain the redirects for at least 180 days — longer if you still see any traffic to them from Google Search." GreenGeeks puts it more sharply: "Industry standard is 12 months minimum."

Rule — keep migration 301 redirects in place for at least 12 months

Rule: All 301 redirects implemented during a WordPress migration remain in place for at least 12 months. Never less than 180 days under any circumstances.

Why (Google's own framing): "Maintain the redirects for at least 180 days — longer if you still see any traffic to them from Google Search." (Google Search Central, Change of Address documentation.)

Why (operational, GreenGeeks migration checklist): "Cutting redirects after 30 or 60 days. Google can take much longer to reindex external backlinks. Industry standard is 12 months minimum."

How to apply: the migration build includes redirect retention as a contract clause. Redirect maintenance after the 12-month window is charged as a separate line item if the client wants to extend.

Mistake to avoid: "we'll clean up the redirects" as a tidying task at 30/60/90 days. External backlinks survive longer than internal crawl patterns; cutting redirects too early destroys recovered traffic.

UK retailer — ~£3.8M loss in first month after botched migration

A UK retailer with a £7.6M+ redesign budget lost approximately £3.8 million in the first month after IT consultants rejected URL redirect mapping recommendations during the migration.

Source: numentechnology.co.uk case study (2024-2025). Confidence: industry-consensus (vendor-published case study; retailer name omitted; pattern consistent with other documented migration failures).

Lesson: migration is a discrete failure event. The platform the client lands on gets blamed regardless of whose decision broke the redirects. For Candid client work, 301 redirect mapping is non-negotiable and gets sign-off from the SEO lead before launch — not from the IT consultant who didn't budget for the rework. See [[coalition-tech-bigcommerce-28k-to-13.4k-keywords]] for a parallel case in the same failure pattern.

When NOT to migrate — the honest counter-cases

Candid Creative will recommend not migrating in these cases:

1. The site is fine; the client just heard "WordPress is slow" on a podcast. Diagnose. Often the fix is $50/month of better hosting + WP Rocket. Ben Ryan's headless-WordPress agency review: "If your WordPress site is slow, fix the hosting, enable caching, and optimise images. Going headless to solve a performance problem you could fix for $50/month is expensive overkill."

2. Client edits daily with 5+ non-technical editors. WordPress's Gutenberg editor is genuinely best-in-class for this profile.

3. Working WooCommerce store with >50 active SKUs and integrations. Migration cost will dwarf performance gains.

4. Critical functionality depends on a niche plugin with no clear equivalent — LearnDash courses, BuddyPress communities, advanced Gravity Forms with conditional logic and a CRM webhook.

5. Client budget assumes "free updates forever from the developer." Headless setups need ongoing developer involvement that WordPress often doesn't.

6. The client is on a "no-developer-ever-again" budget after launch — they should stay on WordPress with a maintenance contract.

FatLab's honest framing (Candid echoes this): "For most of our clients, headless is the wrong choice."

The audit's job is to tell the truth. If migration is the wrong project, the audit says so and refers the client to a WordPress maintenance shop. That credibility is worth more than the one engagement.

WordPress + Gutenberg on managed hosting can match Astro

A WordPress installation configured with Gutenberg-only (no Elementor/Divi/WPBakery), a lightweight theme (Kadence, GeneratePress, Hello, Blocksy), running on managed hosting (Kinsta, WP Engine, Cloudways, Rocket.net), can reach CWV pass rates comparable to an Astro-on-Cloudflare site in field measurements.

Evidence: DebugBear, rtCamp, and Windmill Strategy case studies all show this configuration in the 90+ Lighthouse mobile range with passing CWV. Combined with HostingStep's independent benchmarks showing managed WP TTFB of 365-470ms (vs Cloudflare ~45-50ms), the gap is real but small.

Confidence: directional. No public head-to-head matched-content benchmark exists; this is a triangulation from multiple agency case studies.

Practical implication: do not recommend a migration on CWV grounds alone if the existing WordPress site is already on managed hosting and uses Gutenberg. Migration only makes sense if there are measured INP issues, integration requirements WP can't serve, or editor-workflow improvements worth the migration cost.

Threshold to revisit: if a head-to-head benchmark publishes showing the gap is >5 pp CWV pass rate at p75, downgrade the equivalence claim.

$5K WordPress refresh vs $20K custom build — SMB decision framework

A decision framework for Kitchener-Waterloo SMB clients deciding between a $5K WordPress refresh and a $20K custom build. Performance alone does not justify the $15K delta.

Stage 1 — do this regardless of which path:

• Measure first. PageSpeed Insights / CrUX for top 5 pages. If already passing all three CWV thresholds on mobile (LCP <2.5s, INP <200ms, CLS <0.1), performance is not the highest-ROI investment. Spend on content, conversion design, GBP work instead.
• Define the business KPI: form submissions, booked appointments, orders, calls.
• Estimate upside. Using Deloitte's ~0.1s → ~1% conversion (calibrated down for non-retail), an SMB doing $150K/year online would gain ~$1,500/year per 100ms shaved.

Choose the $5K WordPress refresh if:

• Current site clears or is close to clearing CWV thresholds.
• Traffic under ~10,000 unique visitors/month.
• Business is professional services, local commerce, or lead-gen — not a complex catalog or proprietary booking flow.
• Modern theme (Kadence, GeneratePress, Blocksy) + quality managed host (Kinsta, WP Engine, Cloudways) + image optimization + plugin discipline + CDN can hit targets.
• Budget split: ~$1.5K theme + setup, ~$1K hosting/CDN year 1, ~$1.5K image/perf/plugin audit, ~$1K content + conversion design.

Choose the $20K custom build if:

• Measured INP issues a WordPress site cannot solve (React-heavy interactive tools, complex configurators, real-time dashboards).
• Transactional flow (multi-step booking, custom commerce, B2B quote builder) where the conversion path is the product.
• Integration requirements (CRM, ERP, custom POS, B2B portals) exceed WP plugins' reliability.

• $500K/year online — at that scale a 5-10% conversion lift is worth tens of thousands per year.

Benchmarks that would change the recommendation:

• Mobile LCP >4s after a $5K refresh attempt → consider custom build or change hosts.
• INP >500ms because of theme/plugin JS bloat → custom build becomes defensible.

• $1M/year online → the $20K delta is rounding error; do the custom build properly.

• Selling to enterprise B2B buyers (Kitchener-Waterloo tech corridor, Communitech-adjacent) → site polish has signaling value beyond pure performance.

Sources and confidence

• Numen Technology 9-of-10 / 50% traffic loss / £3.8M UK retailer: numentechnology.co.uk case studies, 2024-2025. Confidence: single-source for the headline stat; industry-consensus for the UK retailer pattern (vendor-published, name omitted).
• SEJ 892-migration study — 523 days average, 17% never recover after 1,000 days: Dan Taylor, "How Long Should An SEO Migration Take? [Study Updated]", Search Engine Journal, published January 9, 2025, data collated October 22, 2024, n=892, methodology: Ahrefs estimated organic traffic. Confidence: high for the methodology scope and the number itself. Scope: domain-to-domain migrations only.
• SEJ prior reading — 42% never recover (n=171): superseded by the n=892 update; do not cite.
• John Mueller "weeks not months": February 19, 2021 Google Search Central Office Hours, reported by Roger Montti at SEJ. Verbatim: "maybe a week or two, maybe up to three weeks… one, two, three weeks, something around that range." Scope: AMP URL crawl settlement after a parked-domain move, not general CMS migration recovery. Confidence: primary source verified, narrowly scoped.
• Google Search Central — medium-sized site recovery: "A medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." (site-move-with-url-changes documentation.) Confidence: primary.
• Google Search Central — 180-day redirect minimum: "Maintain the redirects for at least 180 days — longer if you still see any traffic to them from Google Search." (Change of Address documentation.) Confidence: primary.
• Google Search Central — Change of Address tool exclusions: "Don't use the Change of Address tool for the following moves: Changing address from http to https… Moving some pages from one location to another within your site." Confidence: primary.
• GreenGeeks — 12-month redirect industry standard: "Cutting redirects after 30 or 60 days. Google can take much longer to reindex external backlinks. Industry standard is 12 months minimum." Confidence: industry-consensus.
• BrightEdge & Numen — 3-5× traffic gains from disciplined migration: vendor-published case studies. Confidence: industry-consensus.
• WordPress.org support forum — attachment URLs: "Thousand of attachment urls are automatically indexed, How do I remove them?" Confidence: primary user report.
• John Carey post-mortem — staging indexation: "I've seen migrations where the staging site was accidentally indexed by Google before launch, creating duplicate content issues and cannibalising the live site's rankings." Confidence: named practitioner.
• Multidots WP agency pricing: "Basic business sites, i.e., informational pages built with premium themes and standard plugins, typically cost $3,000-7,000." Confidence: vendor-published.
• Seahawk Media migration entry point: "$499 and fully customizable" for content-only migrations. Confidence: vendor-published.
• Pagefind search payload claim: "a full-text search on a 10,000 page site with a total network payload under 300kB" (Pagefind documentation). Confidence: primary product documentation.
• Ben Ryan — headless-as-perf-fix critique: "If your WordPress site is slow, fix the hosting, enable caching, and optimise images. Going headless to solve a performance problem you could fix for $50/month is expensive overkill." Confidence: named practitioner.
• FatLab — headless is wrong for most clients: "For most of our clients, headless is the wrong choice." Confidence: named practitioner.
• DebugBear, rtCamp, Windmill Strategy — WP managed-host CWV parity: triangulated agency case studies. Confidence: directional.
• HostingStep — managed WP TTFB benchmarks: 365-470ms managed WP vs ~45-50ms Cloudflare. Confidence: independent benchmark.
• Outsourcify — 7,000-article migration image-rewrite challenge: named project post-mortem. Confidence: named practitioner.
• Deloitte — 0.1s improvement → ~1% conversion: widely cited retail benchmark, calibrated down for non-retail SMB. Confidence: industry-consensus.

Related: Research brief: The Candid Creative WordPress Migration Playbook (piece 19) holds the underlying research brief for this consolidated topic page.