Why the Client Wanted to Leave WordPress
Our client ran a B2B SaaS company with a marketing site that had grown to about 200 pages over five years on WordPress. They had 47 plugins installed (yes, forty-seven), their PageSpeed score was 23 on mobile, and every time they tried to update a plugin, something else broke. The final straw was a security breach through an outdated WPForms plugin that went unpatched for six months. They came to us and said "get us off WordPress."
Fair enough. But in hindsight, there are things we'd do differently.
The Content Migration Was 60% of the Work
We underestimated this massively. WordPress stores content in its own HTML format with shortcodes, Gutenberg blocks, and plugin-specific markup. Converting 200 pages of mixed-format content to clean, portable structured content was tedious, manual work. We wrote custom scripts to handle the common patterns (converting [gallery] shortcodes, Yoast SEO metadata, ACF custom fields), but about 30% of pages needed manual review and cleanup.
What we'd do differently: spend the first two weeks doing a thorough content audit before writing any migration code. We'd categorize every page by content type and complexity, identify which ones can be auto-migrated and which need manual work, and get the client to sign off on a page-by-page migration plan. We skipped this step and paid for it with scope creep.
The SEO Redirect Nightmare
WordPress URL structures are weird. Some pages were at /blog/2022/03/post-name/, others at /post-name/, and others at /category/subcategory/post-name/. The client had 200+ pages indexed by Google, plus hundreds of old URLs that had been 301'd over the years. We built a comprehensive redirect map — 347 entries — and implemented it in Next.js middleware. Then we discovered that some of their inbound links used URL parameters that WordPress had silently handled, and our middleware was stripping them.
We lost about 12% of organic traffic in the first two weeks after launch. It recovered over the next six weeks as the redirects settled in, but those were two very stressful weeks. Our SEO engineer Priya now insists on a minimum four-week redirect monitoring period with daily traffic checks for every migration project.
The CMS Decision
The client needed non-technical marketing people to edit content. Next.js is great for developers, terrible for marketers. We evaluated Sanity, Contentful, Strapi, and WordPress as a headless CMS (yes, really — WordPress as a headless CMS behind Next.js). We went with Sanity because their real-time editing experience is the closest to what the marketing team was used to in WordPress. The visual editor and live preview sold it.
Eight months later, the marketing team is mostly happy but still occasionally complains that Sanity isn't as intuitive as WordPress's block editor. Which is fair. WordPress's editor, for all its faults, is genuinely good for non-technical users. If the client's primary need is a content-heavy marketing site with frequent updates by non-developers, I'd honestly consider keeping WordPress and just optimizing it, rather than migrating to a headless setup.
The Performance Wins Were Real
PageSpeed score went from 23 to 94 on mobile. Time to First Byte dropped from 2.1s to 180ms. Largest Contentful Paint from 8.4s to 1.2s. The site now runs on Vercel's edge network, images are optimized through Next.js Image component, and pages are statically generated with ISR for the blog. These numbers translated to a measurable improvement in bounce rate (down 18%) and pages per session (up 23%) over the following quarter.
Would We Do It Again?
Yes, but with different expectations. The migration took 14 weeks instead of the estimated 8. It cost the client about 40% more than budgeted, mostly due to the content migration complexity. But the result is a fast, secure, maintainable site that doesn't require constant babysitting. For a B2B SaaS company whose website is a core business asset, that's worth it. For a local business blog with 30 pages? Just fix WordPress.