A clean WordPress to Next.js migration in 2026 takes 6–14 weeks, costs CA$15,000–CA$80,000 depending on size, and — done right — keeps 90%+ of your organic traffic and rankings intact through the cutover. Done wrong, you lose 40–70% of organic traffic in the first month and spend the next year clawing it back. This guide covers the migration paths, the redirect map that decides everything, and the SEO checks we run on every cutover we ship.
Should you migrate from WordPress to Next.js at all?
WordPress in 2026 is fine. The platform powers ~43% of the web for good reasons: mature CMS, broad ecosystem, easy editing. Migrating to Next.js makes sense when one of these is true:
- Performance is hurting conversions or rankings. Your WP site scores under 50 on Lighthouse mobile and you've already cleared the plugin/host/theme decisions. Next.js routinely scores 95+ for the same content.
- You're a SaaS or marketing-led product. Your front end needs to integrate tightly with a product app. Running marketing on the same codebase as the product saves real engineering time.
- You need a custom interaction layer. Quote calculators, multi- step forms, real-time data, complex personalization. Possible in WP, but at some point Gutenberg fights you.
- Editor maintenance is becoming a tax. Three plugin updates broke the homepage in the last quarter. WP can be tamed, but if you've tried and lost, a clean Next.js + headless CMS rebuild often costs less over three years.
If none of those apply, fix WordPress instead. Switch hosts, drop unused plugins, replace the theme. About a third of the "we need to migrate" calls we take end with us recommending the customer stay on WordPress and address the actual bottleneck.
Two migration paths: full move vs headless WordPress
Full migration: WordPress → Next.js + a new headless CMS
The most common path. You decommission WordPress entirely and replace it with Next.js plus a modern headless CMS — Sanity, Contentful, Storyblok, or Payload are the usual picks for content-heavy sites; for simpler marketing sites, MDX files in the repo or a small custom admin work too. This is the right path for 80% of marketing sites we migrate, because it removes the WP maintenance overhead permanently.
Decoupled: keep WordPress, add Next.js
Use WordPress as a headless CMS via the REST API or WPGraphQL, with Next.js as the front end. You keep the WordPress editor your team already knows. This is the right path when:
- Your editorial team has years of muscle memory in Gutenberg/Classic editor
- You have hundreds of authors and migrating roles + permissions is more pain than the speed gain is worth
- You need a specific WP plugin's editor experience (ACF for complex content models, WPML for translations)
Trade-off: you still maintain WordPress. You've added a Next.js front end on top, so you now have two systems instead of one. Real performance gains still come (the front end is fast even if the editor is WP), but the "reduce maintenance" argument disappears.
The pre-migration audit: inventory before you cut
The single biggest cause of post-migration traffic loss is missed inventory. Before any migration we ship, we collect:
- Every URL with traffic in the last 12 months. Pull from Google Search Console (Performance → Pages → 12-month export) and Google Analytics (Engagement → Pages and screens). Sitemaps lie — they often miss old posts that still rank.
- Every URL with inbound links. Pull from Search Console (Links → Top linked pages) and a backlink tool like Ahrefs or Semrush. Old URLs with good links must redirect to specific new URLs, never to the homepage.
- Every plugin doing meaningful work. Yoast SEO data (canonical overrides, redirects, OG titles), ACF custom fields, contact forms with custom endpoints, lead-flow plugins, e-commerce, gated content. The migration plan needs to handle each one.
- Every piece of structured data the site emits. Article schema, Product, FAQPage, BreadcrumbList, LocalBusiness. Page-by-page if necessary. Check existing rich results in Search Console (Enhancements section) — those need to keep working after cutover.
- The XML sitemap as it stands today. This becomes your initial baseline for the redirect map and the post-launch crawl.
Content migration: moving from WP to your new CMS
The mechanics depend on the destination. The general workflow we use:
- Export from WordPress. Use the built-in WXR export, plus a plugin like WP All Export for custom post types and ACF fields. Export images separately as a media-library archive.
- Transform to the target shape. Convert WXR/JSON to your target CMS's import format. Sanity has
sanity-import; Contentful has a CLI; Storyblok and Payload have REST imports. We usually write a small Node script that walks the export, normalizes HTML to portable text or MDX, and rewrites image URLs to the new CDN. - Import in batches and spot-check. Always start with 50 posts before doing a full import. The errors you find at 50 are the same ones you would have found at 5,000 — but cheaper to fix.
- Migrate images last, with the new CDN ready. Images are usually the slowest part. Tools like
cloudinary-cliorimgix-clihandle bulk upload; Vercel Image Optimization works fine for most marketing sites.
The redirect map: the single biggest SEO decision
Get this right and you keep most of your rankings within two weeks. Get it wrong and you spend a year recovering.
The rules that win
- Every old URL with traffic or links → 301 to the most relevant new URL. Never 302, never to the homepage as a default. A bulk old-URL-→-homepage redirect is a soft 404 in Google's eyes and tanks rankings.
- Preserve URL structure where you can. If your WP slugs are already clean (
/blog/post-slug), keep them. The cleanest migration is the one where most URLs don't change. - Handle WordPress's edge cases. Tag pages, category archives, author archives, attachment URLs, paginated archives (
/page/2/). Decide which to keep, which to merge, which to drop — and redirect every URL with even one inbound link. - Drop trailing slashes consistently. WordPress defaults to trailing slashes; Next.js defaults to no trailing slashes. Pick one and 301 the other. Don't leave both live, ever.
Implementing redirects in Next.js
For up to a few hundred redirects, the cleanest place is next.config.mjs:
| Volume | Where to put redirects |
|---|---|
| < 200 | redirects() in next.config.mjs |
| 200 – 5,000 | JSON file loaded by redirects() |
| 5,000 – 50,000 | Edge middleware reading from a KV store |
| 50,000+ | Edge middleware + cached lookup; consider Cloudflare Workers |
The mistake we see most often: trying to use 50,000 entries inredirects(). Next compiles them into a path-to-regexp table at build time and the build slows to a crawl. Move to middleware once you cross a few thousand.
SEO transfer: titles, meta, schema, sitemaps
Beyond redirects, four things must travel cleanly from WordPress to Next.js.
- Page titles and meta descriptions. If you're using Yoast on WP, export Yoast's overrides and feed them to your new CMS's SEO fields. Don't regenerate from scratch — Google has indexed the existing titles and abrupt rewrites cost CTR.
- Canonical tags. Confirm every page emits a canonical to its own URL. The single most common bug we find on freshly-migrated sites is a homepage canonical sneaking in everywhere because of a layout-level tag.
- Schema markup. Re-emit every schema type the WP site had — Article, BreadcrumbList, Organization, LocalBusiness. The Search Console Enhancements report tells you which schema types you had and how many pages used each.
- Sitemap. Generate a fresh
sitemap.xmlat the new domain (Next.js'sapp/sitemap.tshandles this elegantly), and submit it to Google and Bing on launch day.
Pre-launch testing: the checklist that prevents disasters
Run all of these before you flip DNS:
- Crawl the staging site with Screaming Frog. Confirm 0 broken internal links, 0 redirect chains longer than 1 hop, every page has a unique title and meta description, every page has a self-referencing canonical.
- Run the redirect list against staging. Every old URL should return a single 301 to a 200 — never a chain, never a 404. Automate this with a script — manual spot-checking misses the long tail.
- Check rich results. Google's Rich Results Test and the Schema Markup Validator on every important page type. Fix any errors before launch.
- Run Lighthouse on a representative sample. Homepage, category page, post, contact. Mobile and desktop. Document baseline so you can see the gain post-launch.
- Verify analytics, ad pixels, and tag manager. GA4, Meta Pixel, LinkedIn Insight, GTM. The single fastest way to lose marketing visibility on launch day is forgetting to migrate the tags.
Performance: what gains to actually expect
Most realistic gain on a content-heavy marketing site: Lighthouse mobile score moves from 40–60 on WP to 90+ on Next.js, LCP drops from 4–8s to 1.5–2.5s, and Core Web Vitals pass on most pages. That improves rankings on competitive queries where the WordPress site was held back by Core Web Vitals.
What does not automatically improve: rankings for pages where WordPress was already passing Core Web Vitals. Don't expect a 30% organic traffic lift from the migration alone if the WP site was already fast. The lift comes from removing a ceiling, not adding ground.
Cost and timeline for a 2026 BC migration
| Site shape | Cost (CAD) | Timeline |
|---|---|---|
| Brochure (10–25 pages, no blog) | $15,000 – $28,000 | 6–8 weeks |
| Marketing + blog (50–200 posts) | $25,000 – $48,000 | 8–12 weeks |
| Marketing + heavy blog (500+ posts) | $35,000 – $65,000 | 10–14 weeks |
| WP + WooCommerce → Next.js + Shopify | $45,000 – $90,000 | 12–18 weeks |
| Multi-language, custom roles, complex CMS | $60,000 – $150,000+ | 14–24 weeks |
Half of these budgets is the build; the other half is the migration plumbing — content transformation, redirect mapping, SEO transfer, training. Studios that quote the build cost only and treat "migration" as a small line item are the ones whose customers lose 60% of their traffic on launch day. For more on what BC web design costs in 2026, see our Canadian web design pricing breakdown.
The first 90 days post-launch
The migration isn't done at cutover. The first 90 days are where you protect the gains:
- Days 1–7: Submit the new sitemap. Watch Search Console coverage. Re-validate any indexed-but-not-found URLs by reviewing the redirect map.
- Days 7–30: Daily crawl monitoring. Expect a small dip in impressions in week 2–3 — Google takes a few weeks to fully reindex. A 10–20% temporary impression dip is normal; a 50%+ dip is a real problem.
- Days 30–90: Review the URLs that lost the most rankings. Usually it's a handful where the redirect went to a too-broad new URL, or where the new page is materially less relevant than the old one. Fix individually.
Planning a WordPress to Next.js migration?
Tell us your domain, rough page count, and what plugins you depend on. We'll send a one-page migration plan with cost, timeline, and an SEO-transfer outline — within three working days, no sales call required.
Book a consultation →Frequently asked questions
Will I lose SEO rankings when migrating from WordPress to Next.js?
Done correctly, you keep 90%+ of organic traffic and rankings through the cutover. The keys are: a complete URL inventory from Search Console, every old URL 301-redirected to a specific new URL (never to the homepage), titles/meta/schema preserved, and a clean sitemap submitted on launch day. Plan for a 10–20% temporary impression dip in weeks 2–3 as Google reindexes.
How long does a WordPress to Next.js migration take in 2026?
For a typical 50–200-post marketing site, plan on 8–12 weeks: 2 weeks audit and planning, 4–6 weeks build and content migration, 1–2 weeks SEO transfer and pre-launch testing, plus a 1-week soft launch. Brochure sites can finish in 6–8 weeks; e-commerce migrations or sites with hundreds of plugins take 14+ weeks.
What does a WordPress to Next.js migration cost in Canada?
Most Canadian SMB migrations cost CA$15,000–CA$48,000 in 2026. Brochure sites land at the low end; marketing + heavy blog or WordPress + WooCommerce migrations cost CA$45,000–CA$90,000. About half of the budget is the build, the other half is migration plumbing — content transform, redirects, SEO transfer.
Should I keep WordPress as a headless CMS or replace it entirely?
Replace it for 80% of marketing sites — it removes WordPress maintenance permanently. Keep WP as a headless CMS when your editorial team has years of muscle memory in Gutenberg, when you have hundreds of authors with custom roles, or when you depend on a specific WP plugin's editor experience. Headless WP gives you Next.js performance but you still maintain WordPress.
How do I handle WordPress redirects in Next.js?
For under 200 redirects, use the redirects() function in next.config.mjs. For 200–5,000, load redirects from a JSON file. For 5,000+, move to edge middleware reading from a KV store. Don't put 50,000 entries in next.config — Next compiles them into path-to-regexp at build and the build slows to a crawl.
What headless CMS pairs best with Next.js for a former WordPress site?
Sanity is the most flexible for content-heavy sites; Contentful is best for marketing teams used to a polished editor; Storyblok works well for visually-driven brands; Payload is the right pick when you want a self-hosted, code-first CMS. For simple marketing sites with under 50 pages, MDX files in the repo is often the cleanest answer.
