WordPress to Next.js Migration: What Actually Breaks

WordPress powers a huge share of the web, but it is also the platform businesses most often outgrow: plugin bloat slows every page down, and its theming model gets in the way of a genuinely custom, fast frontend. Moving to Next.js fixes both problems, but only if you go in knowing which parts of a WordPress site do not translate directly. Most migration pain is not the framework switch itself, it is the invisible plumbing that was quietly holding the old site together.

Plugin-dependent functionality has to be rebuilt, not ported

A typical WordPress site leans on a dozen plugins for things that feel core to the business: contact forms, SEO metadata, image galleries, booking widgets, membership gating, WooCommerce checkout, page builders like Elementor or Divi. None of that comes with you. Each plugin's functionality has to be identified, prioritized, and rebuilt as real code or a proper integration in the new stack — a booking widget from a plugin like Amelia or Bookly isn't a design pattern you can eyeball and recreate, it's a database schema, an availability engine, and a payment hook that all need a new home. Skipping this step is the single most common reason a WordPress to Next.js migration quietly loses features nobody realized were plugin-dependent until they were gone. The fix is a full plugin audit before any code gets written: list every active plugin, write down in one sentence what business function it serves, and mark whether that function is rebuilt, replaced, or genuinely no longer needed.

SEO metadata and structured data do not migrate themselves

Most WordPress sites carry years of SEO work inside Yoast or RankMath: hand-tuned title tags, meta descriptions, canonical URLs, Open Graph images, and schema markup for articles, products, or FAQs. That data lives in WordPress's own database tables and post meta, and a Next.js rebuild starts from zero unless someone explicitly exports and re-maps it. A common failure mode is a beautiful new site that quietly ships with generic auto-generated titles on every page, because nobody exported the old Yoast fields before the WordPress database was decommissioned. The safe sequence is to export every page and post's title, description, and canonical URL first, rebuild the equivalent metadata generation in Next.js's Metadata API, and verify the new sitemap.xml covers the exact same URL set as the old one before the old site goes dark.

Forms and lead capture are the easiest thing to silently lose

Contact forms built with a WordPress plugin like Gravity Forms or WPForms usually store submissions in the WordPress database and send email through WordPress's own mail handling, often via an SMTP plugin patched in years ago and long forgotten. Rebuilding the frontend without also rebuilding where that data goes is a common gap, one that leaves a beautiful new form that quietly stops delivering leads to the sales inbox — and because the form still visually works and shows a "thank you" message, nobody notices for weeks. Every form on the old site needs a mapped destination on the new one before launch: a database table, a CRM webhook, a transactional email service, whatever the team actually checks. The only way to catch this before launch, not after, is to submit a real test lead through every form on staging and confirm it lands where a real prospect would expect a response to come from.

Media library and image URLs break in ways that are hard to see

WordPress's media library serves images from predictable, flat URLs under /wp-content/uploads/, and years of blog posts, case studies, and product pages reference those URLs directly inside their content. Next.js has no equivalent folder structure by default, and its image component expects images to be imported or fetched from a defined source, not scattered across a decade of ad-hoc uploads. A lift-and-shift migration that doesn't remap every embedded image URL ships with broken images buried inside old blog posts, missing alt text that took years to write for accessibility and SEO, and none of the responsive srcset or lazy-loading benefits that were the whole point of moving to Next.js in the first place. Treat every image the way you'd treat a URL: inventory it, decide its new home, and verify it actually loads before the redirect for its parent page goes live.

Third-party integrations quietly stop firing

A mature WordPress site usually has Google Analytics, a Meta or LinkedIn pixel, a live chat widget, and maybe a CRM sync all wired in through a mix of theme code, a tag manager plugin, and hand-pasted snippets in the header. None of these are visible in a design review, so they're the easiest thing to forget entirely during a rebuild — and because the site still looks and functions correctly, the gap doesn't show up until someone asks why last month's ad campaign shows zero conversions in Google Ads. Every tracking script and integration needs its own line item in the migration plan, not an assumption that "analytics is analytics" and it'll just carry over. Test each one in staging by triggering the real event it tracks — a page view, a form submit, a chat open — and confirming it shows up on the other end, not just that the script tag is present in the page source.

URL structure and redirects decide whether rankings survive

WordPress permalinks, category archives, tag pages, and paginated URLs all carry indexed search equity built up over months or years. Next.js does not generate any of that automatically, so the redirect map has to be built by hand from a full export of the old site's actual indexed URLs — pulled from Google Search Console and a crawl of the live site, not guessed from the current sitemap.xml, which often lags behind what's genuinely indexed. Pay particular attention to URL patterns WordPress handles invisibly: trailing slashes, paginated archive pages like /page/2/, and query-string-based filtering, all of which need an explicit 301 rule or they'll 404 the moment the old server goes away. A migration that skips 301 redirects for old permalinks trades a faster site for a traffic cliff in Search Console a few weeks after launch — and because search rankings lag real-world changes, the damage is often invisible until it's already done.

The editorial team's daily habits change more than the design does

Non-technical editors are used to specific WordPress conveniences: the block editor, a real media library, scheduled publishing, revision history, and the confidence that clicking "Publish" does what they expect. Whatever CMS or admin panel replaces WordPress needs to cover those same daily habits, not just list equivalent features on a documentation page nobody reads. A migration that nails performance but leaves the content team unable to publish confidently the way they could before just creates a second, quieter project a few months later, when someone finally admits the new system never really got adopted. The cheapest way to avoid this is to put a real editor in front of the new admin panel before launch, not after, and have them publish an actual post end to end.

How long this actually takes, and what determines the timeline

For a marketing site with a few dozen pages, a plugin-light setup, and a small team making decisions, four to eight weeks from technical audit to launch is realistic. A site with WooCommerce, hundreds of blog posts, multiple third-party integrations, and several stakeholders who need to sign off on each stage routinely takes three to four months, and rushing that timeline is exactly what produces the plugin gaps, broken forms, and ranking drops covered above. The two biggest timeline variables are rarely the ones people expect going in: how complete and accurate the plugin and content inventory is at the start, and how many people need to approve each stage before it moves forward. A realistic project plan treats discovery and audit as a real phase with its own timeline, not a formality to rush through before the "real work" of building starts.

None of this is a reason to stay on WordPress if it is genuinely holding a site back, it's a reason to scope the migration properly before writing any code. In practice that means auditing plugins, forms, metadata, media, and integrations up front; building the new site against that inventory in a staging environment; and running the old and new sites side by side long enough to catch what the design review missed, before the DNS cutover makes the new site the only one anyone can see. Our own process starts with exactly this kind of audit, mapping every plugin, form, and indexed URL before a line of the new site gets built; the Services page has more on how that engagement is scoped.