The owner of a small accounting office told us on the phone that her WordPress site was "as slow as the office internet" and she wanted it replaced. We work in Next.js and no longer take on new WordPress builds. She got a list of fixes instead, and her site is still on WordPress.
WordPress has a point that developers like us tend to skip over. Somebody in the office can log in and post a notice without calling anyone, and for a small company that matters more than it sounds. It also still runs 39.5% of all websites according to W3Techs.
A slider from 2019 and a QR code plugin from one campaign
Her site had 23 plugins in 2025. Nine of them no longer did anything: an old slider from 2019, a QR code plugin left over from a single campaign, and seven more of the same kind.
The JPG images weighed 2 to 3 MB each. Three external scripts loaded on every subpage. Mobile PageSpeed, the Lighthouse mobile test, came out at 41.
We removed the unused plugins, converted the images to WebP and deferred the scripts, which took seven hours in total. The same test then gave 78.
The office stayed on WordPress because the layout suited them, and because one employee posts the tax deadline notices in the panel herself.
The four checks we run before saying "stay"
A site can stay on WordPress when all four of these hold:
- One person in the company logs into the panel at least once a month and runs the updates.
- The site has a dozen or so plugins at most, and each one has a known job.
- The theme is still developed by its author and has had an update within the last year.
- The contact form, the phone number and the key subpages work on a phone without errors.
Our rough line for the opposite case is more than 20 plugins with nobody responsible for updates. At that point the cost of keeping the site running grows faster than whatever the site brings in.
What annoys us most is page builders. Switch one off and every subpage is left with hundreds of shortcodes in square brackets, which the client then sees on the page as plain text.
The form that said "Message sent" for 11 days
The second case was a garden company. In 2025 it went 11 days without a single inquiry, and nobody knew why.
An update to the plugin that sent the mail had disconnected it from the contact form. The form kept showing "Message sent", so customers believed they had written to the company, and the inbox stayed empty the whole time.
The site had 31 plugins. The log in the panel showed about 150 updates during 2024, and mobile PageSpeed was 34.
Each plugin comes with its own author and its own release schedule, and those counts fit the wider picture. Patchstack found 11,334 new WordPress vulnerabilities in 2025, with 91% of them in plugins and only 6 in WordPress core.
89, with the drone video left in
We rebuilt the garden company's site in Next.js and moved all the content over, with redirects from every old URL. Each subpage is generated ahead of time and reaches the browser as finished HTML. Headers, structured data and the sitemap have been in the code since day one.
Mobile PageSpeed after launch was 89. It would be a few points higher without the drone video on the home page, and the video stayed anyway, because the owner shows it to clients at their first meeting.
What the client gives up when we move them
Moving costs the client something. On our Next.js sites the client edits text, images and posts in a panel, and a new section on a page goes through us.
One client calls us about that roughly four times a year. In WordPress she would add the section herself in about fifteen minutes. With us it turns into an hour-long job.
If you want to build new subpages from ready-made blocks every month, WordPress gives you more freedom.
The second cost is who else can touch the site. For a WordPress site you will find someone in every county, freelancers included, while a Next.js site needs a developer who knows React and Next.js.
Upkeep stays too, in a different shape. On WordPress you update the core, the theme and each plugin separately. On our Next.js sites the dependencies get updated once a month.
Before anyone decides either way, we look at the number of plugins, the number of pending updates and the mobile PageSpeed score. All three are easy to check on a site you look after today.
If you maintain client sites, I would like to hear your version. What made you keep a client on WordPress when a rebuild was on the table, or what was the moment you decided one had to move off it?
Top comments (6)
Your accounting-office case is the one I'd point to: the reason to stay wasn't PageSpeed, it was one employee posting the tax deadlines herself. And your "what the client gives up" section names the real price of a move: new sections go through you, and the next developer has to know React.
There's a middle option I've been building for exactly that split (I'm the author, so weigh this accordingly): WordPress keeps serving the request, so the client keeps the editor and their plugins, and a Node.js renderer produces the page. Honest limits: it's an Express renderer, not your Next.js stack; each theme's look is rebuilt in the renderer (Twenty Twenty-Five works out of the box); logged-in users still see normal WordPress; and it doesn't fix a mail plugin that silently fails. 60-second comparison: youtu.be/1qbbvq67eu8
Would a client like the accounting office have been one you'd take on that way, or is keeping WordPress at all the deal-breaker?
Honestly, not for that one. Her problem was nine dead plugins and 3 MB JPGs, and seven hours of cleanup took her from 41 to 78. A Node renderer on top would give a small office a second system to keep alive, and the person keeping it alive would be me.
Where I can see it fitting is a bigger content site with an editorial team that won't leave the WordPress editor, and someone in-house who owns the renderer. Credit for listing the limits up front, that's rarer than it should be.
Fair, and I agree on that one: seven hours of cleanup beat any new system for a small office. A renderer is only worth it when someone owns it.
Your second point is the useful one for me: a content site whose editors won't leave WordPress, with someone in-house to own the renderer. Have you met clients like that? I'm curious whether they went headless in the end or stayed put.
Thanks for the straight answer.
Not among our clients so far. Most of them are small companies where one person edits the site, so the choice ends up being stay or move, nothing in between. If one of those bigger editorial sites lands on my desk, I'll remember this thread.
I usually keep WordPress when the client genuinely needs self-serve edits and someone owns updates; a rebuild only helps if it lowers upkeep without making every routine change depend on a developer. Before changing stacks, I’d test the mobile journey and contact form end-to-end, then fix the biggest image/script bottlenecks—the handoff model often matters more than the CMS.
Agreed on the handoff part. The accounting office stayed mostly because one employee posts the tax deadline notices herself, and no PageSpeed score was going to beat that.
I'd put your end-to-end form test first on the list, too. The garden company's form said "Message sent" for 11 days while the inbox stayed empty.