WordPress to Next.js: when it makes sense (and when it doesn't)

Two enquiries landed in the same week last year. The first was a builder with an eleven-page brochure site who wanted it rebuilt in Next.js because a developer mate in Sydney told him WordPress was finished. The second was an equipment-hire company running WooCommerce with a bolted-on booking plugin, a customer-login plugin, and a spreadsheet where the invoices actually lived.

We talked the builder out of it. We moved the hire company to Next.js, and eighteen months on it was one of the better calls we've made.

That's the whole article in two sentences, honestly. Next.js is an application framework. If your WordPress site has quietly turned into an application, with accounts, dashboards, bookings, personalised pricing, integrations with three other systems, then Next.js is one of the strongest destinations you can pick. If your site is words and pictures that change a few times a month, you're about to buy a truck to do the school run. This piece sits alongside our broader guide to leaving WordPress in 2026, which covers the other destinations too.

What you're actually buying

Next.js is the full-stack framework built on React, and the App Router is the current shape of it: nested layouts, file-based routing, and React Server Components, which render on the server and send far less JavaScript to the browser than the old model did. For an application, this is genuinely good. Data fetching happens next to the component that needs it, authenticated pages render on the server where your secrets are, and the framework handles the plumbing that used to be a week of setup.

The bigger asset is the ecosystem. Whatever you need to integrate, the React version of it exists and is maintained: payment SDKs, auth providers, component libraries, chart kits, form handling. WordPress has plugins for these things too, but a plugin is someone else's opinion bolted onto your site. A React library is code your developer composes into the application, which matters once the requirements get specific.

Then there's hiring, which nobody thinks about until year three. In the 2025 Stack Overflow developer survey, React was used by 46.9% of professional developers and Next.js by 21.5%, which makes it the most-used React framework by a wide margin. When your original developer moves on, and they will, the pool of people who can pick up a Next.js codebase is about as deep as pools get. That's not nothing. We've inherited sites built on obscure frameworks where the honest quote was "cheaper to rebuild than to learn".

The honest costs

Now the ledger's other side, because there is one and it's longer than the fan posts admit.

Next.js is complicated. The server/client component boundary confuses experienced developers, the caching behaviour has been reworked more than once, and there are five ways to fetch data with real consequences for picking the wrong one. For an application team this is manageable complexity with a payoff. For a marketing site it's machinery you're paying to maintain and getting little back from.

Hosting deserves its own paragraph. The default path is Vercel, the company behind the framework, and Vercel's pricing starts at US$20 per seat per month on Pro plus usage-based charges for bandwidth, function invocations and image optimisation. Plenty of sites run there for that flat US$20. But usage pricing means a traffic spike or a misconfigured cache becomes a bill, and the horror-story invoices you've read about are real, if rare. The alternatives: Next.js self-hosts on any Node server if you're happy running a server, or it runs on Cloudflare Workers through the OpenNext adapter, which Cloudflare now documents as a first-class path. We host on Cloudflare and the economics are much kinder, though you should know the adapter occasionally trails the newest Next.js release, and a framework feature can take a little while to work outside Vercel.

And the upgrade churn is real. Next.js 15 made cookies, headers and searchParams asynchronous, a breaking change that touched nearly every page of every app, softened by a codemod but still a day of work and a round of testing. Major versions arrive roughly yearly. The Pages Router to App Router migration before that was a rewrite in all but name for some teams. Budget for this. A Next.js site that nobody upgrades for three years is WordPress with better syntax.

Getting your content out

There are two workable paths, and which one fits depends on how much publishing your business actually does.

The first keeps WordPress alive as a content backend. Every WordPress site already exposes its posts and pages through the REST API, and the WPGraphQL plugin does the same over GraphQL, so your new Next.js front end can pull content from the WordPress admin your editors already know. This is the classic headless setup, and we've written about when headless WordPress makes sense separately. Our view in short: it's a decent interim step and a reasonable permanent home for a genuinely content-heavy operation, but you're still paying WordPress hosting, still patching plugins, and still running the thing you were trying to leave. Treat it as a bridge unless you have a newsroom.

The second path is a full port: content comes out through the REST API or a WXR export, gets converted to MDX files or loaded into a modern headless CMS, and WordPress gets switched off. This is what we do for most sites under a few hundred pages. Markdown files in a git repository turn out to be a surprisingly pleasant CMS: every change is a tracked diff, nothing lives in a database that can corrupt, and the whole site restores from version control.

Either way, the migration risk has nothing to do with the framework. It's the URLs. Every old address needs a 301 to its successor, per Google's site move documentation, or the rankings you spent years earning quietly evaporate. We keep a migration checklist for this, and we've covered why traffic drops after a redesign in detail. Do the redirect map before anything else.

Faster than WordPress, slower than you'd assume

Here's the part the Next.js pitch decks skip. On real-user data, Next.js sites are quicker than WordPress on average, and distinctly slower than the static-first crowd.

The WebVitals.tools framework benchmark, built on Chrome UX Report data from April 2026, has 68% of Next.js origins passing all three Core Web Vitals on mobile, against 84% for Astro. WordPress sits around 50%, per HTTP Archive's technology report. The gap used to be worse: Astro's 2023 framework performance report measured barely a quarter of real-world Next.js sites passing, back before Server Components did the heavy lifting.

Why does a framework this sophisticated sit sixteen points behind? Because it makes slow easy. Ship a few too many client components, hydrate a marketing page that never needed JavaScript, let the bundle creep, and you've built something that scores worse than the WordPress site it replaced. We've audited exactly that. The framework rewards discipline; it doesn't supply it.

So if performance is your main reason for leaving WordPress, Next.js is the wrong answer to the right question.

When a simpler stack wins

Which brings us back to the builder with the eleven-page site. What he needed was WordPress to Astro: static pages, near-zero JavaScript, hosting that costs almost nothing, and the best pass rates in the CWV data above. That's our default recommendation for brochure sites, service businesses and blogs.

There's also a newer option we increasingly reach for when a site needs some application behaviour but not the whole Next.js apparatus: TanStack Start, a lighter full-stack React framework that we now build on ourselves, including this site.

The test we actually use is boring. Does the site have logins? Dashboards? Per-user content? Bookings or quoting logic that talks to other systems? If yes, Next.js earns its complexity. If the honest answer is "no, but it might someday", build the simple version now; a rebuild later, funded by a business that grew, is a good problem.

Where AI tooling changes the maths

One shift since 2024 has changed our quotes more than any framework release: most of our code is now written with AI assistance, tools like Claude Code and Cursor, and the two platforms are not equally suited to it.

A Next.js site is plain typed files in a git repository. An AI agent can read the whole codebase, make a change, and open a pull request a human reviews before anything ships. Content as MDX gets the same treatment: a price update or a new service page arrives as a reviewable diff. WordPress offers no equivalent surface. Its state is smeared across a MySQL database, plugin option tables and a themed PHP runtime, and there's no safe way to point an agent at that and review what it did afterwards.

Training data compounds the advantage. Next.js is probably the single best-represented web framework in the code these models learned from, so the assistance is unusually good, and TypeScript catches the model's mistakes at build time. There's no type-check safety net under a stack of PHP plugins.

The practical effect on cost is blunt: changes that were a $150-an-hour developer ticket become a ten-minute reviewed diff, and the rebuild itself now costs a fraction of the quotes people remember from 2022, with controlled studies showing the speed-up is real. One caveat we'd put in writing: AI accelerates a clean codebase. It does not rescue a mess, and it cannot operate the mess WordPress becomes.

Where we fit

We do these migrations end to end: content export, redirect map, redesign, and Cloudflare hosting on the other side, whether the right destination turns out to be Next.js, Astro or TanStack Start. We'll tell you which one before we quote, and we've talked more than one client out of the expensive option. If you're weighing it up, here's how we approach the build work, or tell us about your site and we'll give you the honest version of this article for your specific case.