Migrating WordPress to a modern edge stack: a 12-step playbook (2026)
Migrating off WordPress is the most-requested project we receive. The pitch is everywhere — faster sites, better developer experience, lower hosting costs, fewer plugin explosions. The pitches are usually honest about the upside. They skip the part where the migration itself is harder than the new site. We do 30–40 of these a year. This is the 12-step playbook we actually run, the cost-and-timing reality check we open every engagement with, and the five mistakes we see in every botched migration.
When migration is worth it
Three cases where we recommend moving:
- Your site has under 500 pages and content changes less than weekly. The "non-technical author needs a WYSIWYG" problem mostly evaporates when posting is infrequent enough that a developer-handled deploy is fine.
- You have real developers on staff who will maintain it. Not contractors hired for the migration and then released — actual ongoing engineering capacity. The new stack needs an owner.
- Performance is a conversion-critical metric. E-commerce, SaaS marketing, anything where a 200ms LCP improvement moves measurable revenue. Core Web Vitals work pays back fastest here.
When to stay on WordPress
Three cases where WordPress remains the right answer:
- Your content team publishes multiple times a week and depends on the editor. Gutenberg is good. Your authors are fluent in it. The marginal speed gain of a static site rarely outweighs the friction of a new authoring workflow.
- You rely heavily on plugins (LMS, membership, forum, complex e-commerce) without headless equivalents. If LearnDash or BuddyBoss is core to the business, migration means rebuilding those features from scratch. Budget accordingly.
- Nobody on your team wants to learn a new stack. A site that nobody on the team is excited to maintain becomes a dead site within 18 months. Be honest about who picks it up after the migration consultant leaves.
WordPress vs a modern edge-first stack — at a glance
A side-by-side of the dimensions that actually matter for a marketing-site decision. Most of these comparisons get reduced to "WordPress is slow, Next.js is fast" — that is partly true but undersells the real trade-offs.
How to migrate WordPress to a modern edge stack — the 12-step playbook
Run these in order. Skipping the redirect and form steps is the single biggest cause of post-migration traffic loss we see. Estimated total time for a 200-page site is 4–8 weeks of focused work; longer for sites with significant e-commerce, multilingual, or membership components.
- 01
Inventory everything before you touch anything
Export the full URL list from the WordPress sitemap (Yoast or RankMath generate one at /sitemap.xml or /sitemap_index.xml). Capture every URL the live site responds to — pages, posts, taxonomies, attachments, custom post types. Pair each URL with its current status (200/301/302/404) using a crawler like Screaming Frog. Output: a spreadsheet with every existing URL, its template type, and the page's organic traffic (from Search Console). This is the source of truth for the redirect step. Time: 2–4 hours. - 02
Audit your plugins and decide what each becomes
List every active plugin. For each, write down: is this critical to the site, is there a headless equivalent, can we drop it. The five categories that always come up: SEO (Yoast / RankMath → built-in schema + custom llms.txt), forms (Contact Form 7 → custom endpoint or Formspree), security (Wordfence → edge WAF + dependency scanning), caching (WP Rocket → edge CDN handles this), email (WP Mail SMTP → direct provider integration). Output: a per-plugin decision document with replacement strategy. Time: 4–6 hours. - 03
Pick the new framework and CMS strategy
A server-side rendered framework is the default recommendation for marketing sites that want broad ecosystem support; Astro is a good alternative for content-heavy sites that don't need much interactivity. For CMS: three patterns work. (a) Headless WordPress — keep wp-admin as the authoring tool, query content via the WP REST API or GraphQL. Lowest author-disruption but you're still maintaining WordPress. (b) Markdown in git — content lives in MDX files alongside the code. Highest developer control, real author friction. (c) Dedicated headless CMS — Sanity, Contentful, Strapi, or a custom CMS on your stack. Best for non-technical content teams. We usually pick (c). Time: a half-day decision. - 04
Build the new site against a subset of the content first
Do not migrate everything before you have a working production build. Pick the top 10 pages by traffic, port those, get the design system + routing + schema right on those, then scale. Output: a deployed preview site (on a staging URL) with 10 pages, full schema graph, Lighthouse 95+, no broken assets. This is your reference point — if it works for 10, it scales to 200. Time: 1–2 weeks for the design + routing scaffolding. - 05
Migrate content in batches, not all at once
For markdown-in-git setups: write a one-off Node script that pulls each post from the WP REST API (/wp-json/wp/v2/posts), strips Gutenberg block markup back to clean HTML/Markdown, downloads the embedded images to your assets folder, and writes the result as MDX. For dedicated-CMS setups: similar approach but POST to the new CMS's API. Critical: preserve the date, author, categories, and slug fields. Slug stability is what keeps URL redirects from being needed everywhere. Time: 1–3 days of script-writing for the migrator, then 4–8 hours of running it in batches and spot-checking output. - 06
Build the URL redirect map (this is the part that breaks SEO if you skip it)
Every URL on the inventory from step 1 needs one of three fates: stays at the same path (no redirect needed), moves to a new path (301 redirect required), or disappears entirely (410 Gone, NOT 404). Build the redirect map as a JSON file or _redirects file. Test EVERY redirect with a script before shipping. Half-day exercise; saves you from the 30-60% traffic loss we see on migrations that skip this. Time: 4–8 hours for a 500-page site. - 07
Rebuild the forms (this is the second part that breaks)
Contact Form 7 and Gravity Forms are usually invisible to the migration plan because they appear simple. They are not. Each form has: a frontend (rendered HTML), a backend (form processing + database write), a notification (email to the admin), an auto-responder (email to the submitter), and probably a CAPTCHA. You are replacing all five. Two patterns: ship a custom serverless function that accepts the POST, validates, writes to your database (or third-party like Airtable/Notion), and fires emails via your transactional email provider; or use a third-party form service like Formspree or Tally that handles the whole stack. We usually pick custom for SaaS marketing sites (full control over the lead-routing logic) and third-party for simple contact forms. Time: 2–4 hours per form. - 08
Set up transactional email cleanly
WordPress sites usually send email through whatever SMTP plugin the admin happened to configure — and that plugin is a single point of failure. After migration, send transactional email via a dedicated provider (SendGrid, Postmark, Mailgun, Resend) with proper authentication. SPF, DKIM, and DMARC need to be configured correctly or your emails will go to spam in Gmail and Outlook. This is its own multi-step project — we cover it in detail in a separate post. - 09
Move the DNS
Lower TTL to 60 seconds the day before. Cut DNS over to point at the new edge platform. Watch for issues with email MX records — they should stay on whatever mail provider you already use, not move with the website. Roll back is a single DNS revert. Time: 10 minutes of work, 24 hours of observation. - 10
Run the redirect verification + Search Console resubmission
After the DNS cut, run your redirect-test script against the live site (not staging). Every URL from step 1 should resolve to a 200 or 301 — zero 404s, zero 500s. Submit the new sitemap to Google Search Console and Bing Webmaster Tools. Ping IndexNow with the full URL list so Bing (and ChatGPT search) re-crawl quickly. Watch the Search Console coverage report daily for the first two weeks — that's where any missed redirects show up. Time: 1 hour of work, 2 weeks of monitoring. - 11
Decommission WordPress carefully
Do not delete the WordPress install for at least 30 days. Keep it running on a subdomain (wp.example.com) or an IP-only URL so you can: (a) verify any missed content paths against the original; (b) run search-engine alerts against archive.org for cached old URLs that 404 in the new site; (c) reference any plugin-specific data structures (custom fields, ACF blocks) that you may have missed. After 30 days of clean coverage in Search Console, you can tear down the WordPress install and cancel the old hosting. Time: passive, 30 days. - 12
Ship the post-migration GEO audit
A migration is the right moment to upgrade SEO and AI-search readiness — the new stack supports it natively. Our 20-item GEO audit checklist covers the items to ship in the first week post-launch: full schema graph, llms.txt + llms-full.txt, dynamic robots.txt with AI-crawler allow-list, named author bylines, /pledge URL, IndexNow integration, markdown content negotiation. None of these were practical on WordPress without custom plugin work. All become trivial on a modern server-side-rendered framework. Time: 1 day of focused work.
The cost-and-timing reality check
The pitches are honest about the destination. They lie about the journey. Three numbers to ground the planning conversation.
One: budget twice as much time for the migration as for the rebuild itself. If a developer estimates 4 weeks to build the new site, the migration around it is another 4 weeks minimum. URL inventory, redirect map, content port, form rebuilds, email setup, DNS testing, monitoring — it adds up. The agencies that quote a flat "site rebuild including migration" usually skip steps 6, 7, and 10 above and you find out after launch.
Two: plan for a 10–20% organic traffic dip in the first 2–4 weeks. Even a perfect migration disturbs the search-engine index. Google re-crawls your URLs at its own pace; Bing re-crawls faster (especially if you ping IndexNow) but feeds ChatGPT search downstream, so AI-search citations also blip. The dip recovers fully within 4–8 weeks if the redirects are clean. If they aren't, the dip becomes permanent.
Three: don't migrate in Q4. Or any quarter where you're running a major campaign. The right time is a quiet period where 2–4 weeks of organic-traffic instability is acceptable. We've done emergency Q4 migrations; they always cost twice as much in lost revenue as the engineering time saved by not waiting.
Five mistakes we see in every botched migration
Across the 30–40 migrations we run per year, the same five mistakes appear repeatedly.
One: shipping without a complete URL redirect map. The single biggest mistake. The team builds the new site, ships it, and assumes "Search Console will tell us what is broken." It does — but it tells you a month after the traffic loss is already locked in. Build the redirect map in step 6 of the playbook, test every entry before DNS cutover.
Two: not migrating the image URLs. Every WordPress install stores images at /wp-content/uploads/2024/03/file.jpg. When you move off WordPress, those URLs break. You either (a) keep the /wp-content/uploads/ path alive on the new site as a redirect or asset proxy, or (b) update every reference in every post to the new asset path. Skipping this gives you a site full of broken images that you discover via customer email.
Three: forgetting RSS feeds, comment feeds, and trackback URLs. WordPress generates /feed/, /post-slug/feed/, /comments/feed/, /post-slug/trackback/ for every post. Most of these are useless in 2026. A few are critical — your RSS feed has subscribers who depend on the URL. Audit feeds in step 1, preserve the main /feed/ URL with a 301 to your new RSS endpoint, 410 the rest.
Four: leaving the WordPress login URL live and findable. If you keep WordPress around for 30 days post-migration (per step 11), make sure wp-admin and wp-login.php are not publicly accessible. Botnets scan for those URLs constantly. We've seen migrations where the "we left it up for 30 days" WordPress got compromised within 48 hours of the DNS cut because nobody firewalled the admin paths.
Five: not testing form submissions in production. Forms work fine in staging because the test mailbox you used got 100% of submissions. In production, real users submit through Gmail, Outlook, Apple Mail, with different referrer headers and different unicode characters. The first week post-launch, monitor every form submission manually. Half the migrations we audit have at least one form that silently fails for a specific email-client combination.
Related reading on Jorbox
Three earlier posts cover adjacent ground: GEO audit checklist: 20 things to ship on a new marketing site for the AI-search readiness work that pairs naturally with a migration, Core Web Vitals in 2026: which one actually moves the needle for the performance side, and Why we still answer our own support tickets in 2026 for how we operate post-launch. The web development service page covers what working with us on a migration looks like end-to-end.
- How long does a WordPress to modern-stack migration take?
- For a typical 200-page marketing site with simple forms and standard plugins, plan on 6–10 weeks of focused engineering work — split roughly 50/50 between rebuilding the site on the new stack and running the migration steps (URL redirects, content port, form rebuilds, email setup, DNS cutover, post-launch monitoring). E-commerce, multilingual, and membership-heavy sites take 12–20 weeks. The biggest variable is not the rebuild — it is the number of plugins to replace and the depth of the URL redirect map.
- Will my SEO drop after migrating off WordPress?
- A clean migration causes a 10–20% organic traffic dip in the first 2–4 weeks, recovering fully within 8 weeks. A botched migration (missing redirects, broken images, lost meta descriptions) can cause a permanent 30–60% loss. The single highest-leverage thing you can do to protect SEO is build a complete URL redirect map before DNS cutover and test every entry. Step 6 of the playbook above covers the process.
- Can I keep using WordPress as a headless CMS after the migration?
- Yes — this is the "headless WordPress" pattern. You keep wp-admin running for content authoring, but the frontend renders from a Next.js (or similar) site that queries content via the WP REST API or WPGraphQL. The advantage: lowest author-disruption — your team keeps using the editor they know. The disadvantage: you are still maintaining a WordPress install with its security and update overhead. For sites where authors strongly prefer Gutenberg, this is the right trade-off. For sites where the authoring team is willing to learn a new CMS, going fully headless with a dedicated CMS (Sanity, Contentful, custom) tends to be the cleaner long-term choice.
- How do I migrate Contact Form 7 forms to a static site?
- Each form needs to be rebuilt as a custom endpoint or replaced with a third-party form service. For custom: write a serverless function that accepts the POST, validates with Zod or similar, writes to a database or third-party API (Airtable, Notion, your CRM), and fires notification emails via your transactional email provider. For third-party: services like Formspree, Tally, or Web3Forms accept form submissions and handle the email forwarding for you. We typically pick custom for forms that feed lead-routing logic and third-party for simple contact-us forms.
- What happens to my WordPress URLs after migration?
- Every URL needs one of three fates: (a) stays at the same path on the new site (no redirect needed — preserve the slug during content migration); (b) moves to a new path (301 redirect from old to new); (c) is no longer relevant (410 Gone status, not 404). The redirects can be served by your edge platform (Vercel _redirects file, Cloudflare Pages redirects, Netlify _redirects) or by Next.js middleware. Whichever, every entry must be tested before DNS cutover.
- Do I need to keep my WordPress images at /wp-content/uploads/?
- Either yes (preserve the path as an alias or redirect to your new asset URL) or update every reference in every post to the new asset path. Do not skip this — it is one of the most common migration failures. We typically migrate images to /assets/blog///.jpg with a CDN in front, and add a server-side redirect rule for any inbound /wp-content/uploads/ request to the new equivalent. That handles old links from third-party sites, social shares, and search results that still point at the WP path.
- What about WordPress comments?
- Three options. (a) Disqus — drops in as an embed, imports the WordPress comments via their tool. Free for low-traffic sites. (b) Giscus — Disqus alternative backed by GitHub Discussions, free, no ads. (c) Remove comments entirely — for most marketing sites, comments generate more spam than engagement. We usually pick (c). If keeping comments matters, (b) is the cleanest.
- How much does it cost to host a site on a modern edge platform?
- Cloudflare's free tier covers most marketing sites entirely — unlimited bandwidth, automatic SSL, global CDN, 500 builds per month. Paid tiers start at $5/month for higher build limits and start adding $0.30 per million requests for serverless functions. A 200-page marketing site with moderate traffic typically costs $0–$10/month total infrastructure. Compare against a typical WordPress managed-hosting plan at $25–$100/month and the savings pay back the migration engineering in 6–18 months.
- Should I migrate during a redesign?
- Generally no. Doing both simultaneously means you can't separate "the new site is slower than the old site" (a redesign problem) from "the new framework is slower" (a migration problem). We recommend: migrate first to a faithful design replica (same look, new stack), wait 4–8 weeks for the SEO dust to settle, then redesign. The migration becomes invisible from the user perspective; the redesign becomes a separate, scoped project.
- What about WooCommerce stores?
- WooCommerce migrations are a substantially different project from marketing-site migrations and need their own planning. You are replacing not just the storefront but the cart, the checkout, the payment integration, the order management, the customer accounts, the inventory sync. Most successful WooCommerce migrations go to a dedicated e-commerce platform (Shopify, Medusa, custom) rather than trying to recreate WooCommerce features on a static stack. If commerce is incidental (a few products on an otherwise content-heavy site), Stripe Checkout or Stripe Payment Links can replace WooCommerce for that subset without a full platform migration.
- Can ChatGPT help with a WordPress migration?
- Yes for tasks like generating the redirect map from a URL list, drafting migration scripts in Node, writing the form-replacement code, and reviewing edge cases. No for the strategy and scoping work — the "should we migrate," "which framework," and "what are the risks" questions depend on context AI models cannot reliably assess (your team, your traffic, your customer behavior). Use ChatGPT as an accelerator on the well-defined engineering subtasks, not as the project lead.
- Do you do WordPress migrations as a service?
- Yes — see our web development service page. We have done 30–40 WordPress migrations per year for the past several years across e-commerce, SaaS marketing, publisher, and indie product company sites. Typical engagement is 8–14 weeks end-to-end at a fixed price quoted after a free 60-minute discovery call.