What happens to your WordPress plugins when you move to Next.js

Twenty eight active plugins is not twenty eight problems. Most of them stop existing.

This is the question that stalls migrations. Somebody opens the plugins screen, counts thirty one active rows, and decides the project is impossible before anyone has looked at what those rows are doing.

They are not doing thirty one things. In every audit I have run, the list breaks into four piles, one of them enormous, and only the smallest pile costs real money. Sorting the list takes about twenty minutes and it is the single most useful thing you can do before asking for a quote.

Sort the list before you price it

One command gets you the list in a form somebody can actually quote against. Run it over SSH, or use the plugin export in your hosting panel if WP-CLI is not available.

# The list itself, which is what a developer needs to scope the workwp plugin list --status=active --fields=name,title,version # Anything that registered its own tables usually owns data you have to movewp db query "SHOW TABLES" --skip-column-names | grep -v '^wp_\(post\|term\|comment\|option\|user\|link\)' # Custom post types, which tells you which plugins shaped your content modelwp post-type list --fields=name,label,public

The second command is the one people skip and the one that matters. A plugin that only reads and renders is cheap to walk away from. A plugin that created its own tables owns data, and that data has to go somewhere before you can turn it off.

The four piles

Every list I have sorted lands in these four, in roughly this proportion.

The first pile is the one nobody believes until they see it. Something close to half of a normal plugin list exists to make PHP run less often, to compress something WordPress should have compressed, or to undo damage another plugin did. None of those jobs survive the move, because none of them exist on a site that was rendered before the visitor arrived.

What replaces what

Three tables, one per pile that matters. The fourth pile gets its own section further down, because it deserves more than a row.

Pile one: gone entirely

Pile two: becomes code you own

Pile three: becomes a service

Forms, in full

Forms are where most of the anxiety sits, so they get a section rather than a row in a table. A form plugin is doing four separate jobs and people usually only replace the first two.

1. 01Rendering the fields. HTML. This part is free.
2. 02Validating what came in. Both in the browser as a courtesy and on the server as a control, because anything can post to your endpoint.
3. 03Delivering it somewhere. An email, usually, and increasingly a webhook into a CRM as well.
4. 04Keeping a record. The one that gets dropped. Your plugin has been quietly storing every submission for years, and if delivery fails on a Next.js site with no storage, that brief is gone.

import { NextResponse } from 'next/server';import { Resend } from 'resend'; export const runtime = 'nodejs'; // A bot fills every field it can find. A field a human never sees is the// cheapest spam filter there is, and it does not ask anyone to read letters.const HONEYPOT = 'company_website'; export async function POST(request: Request) {  const body = await request.json().catch(() => null);  if (!body) return NextResponse.json({ error: 'Malformed request.' }, { status: 400 });   if (typeof body[HONEYPOT] === 'string' && body[HONEYPOT].length > 0) {    // Answer normally. A bot told it failed will simply try again differently.    return NextResponse.json({ ok: true });  }   const name = typeof body.name === 'string' ? body.name.trim() : '';  const email = typeof body.email === 'string' ? body.email.trim() : '';  const message = typeof body.message === 'string' ? body.message.trim() : '';   // The browser already checked these. It is not a control, it is a courtesy.  if (name.length < 2 || !/^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/.test(email) || message.length < 10) {    return NextResponse.json({ error: 'Please check the form.' }, { status: 400 });  }   const resend = new Resend(process.env.RESEND_API_KEY!);  const { error } = await resend.emails.send({    from: 'Website <forms@example.com>',    to: ['you@example.com'],    replyTo: email,    subject: `New enquiry: ${name}`,    text: [`From: ${name} <${email}>`, '', message].join('\n'),  });   // Job four. Without this line, a failed send is a lost customer and  // nobody finds out until they ask why you never replied.  await recordSubmission({ name, email, message, delivered: !error });   if (error) {    return NextResponse.json({ error: 'Could not send. Please email us.' }, { status: 502 });  }  return NextResponse.json({ ok: true });}

The SEO plugin

The second biggest worry, and the more reasonable one. Yoast or Rank Math is holding years of titles, descriptions, canonicals, robots rules, social cards and structured data. Losing it is how migrations lose rankings.

The replacement is not a plugin, it is two files and a habit. Metadata is exported per route from the same data the page renders, so the two cannot drift apart.

export async function generateMetadata({ params }): Promise<Metadata> {  const { slug } = await params;  const post = await getPost(slug);  if (!post) return {};   return {    // The value Yoast was storing, carried across rather than regenerated    title: post.seo.title ?? post.title,    description: post.seo.metaDesc ?? post.excerpt,    alternates: { canonical: post.seo.canonical ?? `https://example.com/blog/${slug}` },    robots: post.seo.noindex ? { index: false, follow: true } : undefined,    openGraph: {      type: 'article',      title: post.seo.ogTitle ?? post.title,      description: post.seo.ogDesc ?? post.excerpt,      publishedTime: post.date,      images: post.seo.ogImage ? [post.seo.ogImage] : undefined,    },  };}

Yoast stores all of that in postmeta under keys prefixed with an underscore, which means it does not come out in a normal export. It has to be pulled deliberately, mapped, and then diffed against the live site before launch. That is a real line item and it is the one I would never let anyone cut.

The performance stack

Cache plugin, image plugin, minifier, lazy loader, script deferrer. On a lot of sites this is a third of the plugin list, and all of it disappears at once.

It disappears because each one is compensating for a decision WordPress made in 2003. A cache plugin exists because pages are assembled per request. An image plugin exists because uploads are served at whatever size they were uploaded at. A minifier exists because every plugin enqueues its own assets independently and nobody is coordinating.

Remove the per-request assembly and the compensations have nothing left to compensate for. Pages are rendered when content changes. Images are transformed on demand into modern formats at the size the layout asks for, with width and height set so nothing shifts. JavaScript is split per route and the code a page does not use is not in the bundle.

The ones that are genuinely hard

Everything above was the cheap news. This is the pile that decides whether your migration is a three week job or a three month one.

There is a middle route people forget. You do not have to move everything at once. Serve the marketing pages, the blog and the landing pages from Next.js, where the traffic and the rankings are, and leave the members area or the shop on WordPress at its own path. Two systems, one domain, and the expensive pile stays untouched until you actually want to deal with it.

Auditing your own list

Print your active plugins and put each one in a pile. The rule that decides it is a single question: does this plugin write data on behalf of a visitor?

• No, it only renders. Pile one or two. The job either disappears or becomes a file. Price it in hours.
• It writes, but only for you. Editor tools, custom fields, admin conveniences. These stay if WordPress stays, and become schema if it does not.
• It writes for visitors. Orders, memberships, bookings, course progress, comments. Pile four. Each one is a decision, not a task.

Take that to whoever is quoting you. A developer who reads it and asks about the custom tables is reading it properly. One who quotes off the plugin count is not.

If you want the sorting done rather than described, send me your active plugin list and the site address. You will get it back in the four piles with the hard rows called out, and an honest note on whether the migration is worth doing at all. The migration service page covers how the work runs, the free site check will tell you what your pages are carrying right now, and the contact form reaches me directly.

Resources

• WP-CLI command reference

  Every command used above: plugin list, post-type list and db query.

• Next.js Metadata API

  What replaces the SEO plugin, including per-route metadata and social images.

• Next.js Route Handlers

  The file that takes over from your form plugin, and the runtime options that matter.

• Next.js Image component

  Sizing, formats and layout stability, which is three plugins in one component.

• Pagefind

  Static site search that runs entirely in the browser. Enough to replace a search plugin on most content sites.

• Patchstack vulnerability database

  Worth checking your own plugin list against before you decide any of it is harmless.