← Blog

Migrating off WordPress in 2026: why, where to go, and what it actually costs

The security numbers got worse again, the hosting bill never shrinks, and the cost of rebuilding has collapsed. When to leave WordPress, when to stay, and where each kind of site should go.

We counted the plugins on a prospect's WordPress site a few weeks ago. Thirty-one. A form plugin, two SEO plugins that disagreed with each other, a page builder, a caching plugin working hard to undo the page builder, a security plugin, and twenty-five others nobody could explain. The owner was paying $180 a month for someone to keep this arrangement alive, and the site still took six seconds to load on a phone.

That site is not unusual. It's the median WordPress site we get asked to look at, and it's why "should we just get off WordPress?" has become the most common first question in our enquiries this year. The answer is usually yes, sometimes no, and the difference is worth being precise about. We've written a whole knowledge base cluster on the individual escape routes; this post is the map of the whole thing.

The security numbers got worse again

Patchstack's State of WordPress Security whitepaper logged 11,334 new vulnerabilities across the WordPress ecosystem in 2025. That's up 42% on the year before. Of those, 91% were in plugins, 9% in themes, and exactly six were in WordPress core itself, all rated low risk.

Read that distribution again, because it's the whole story. WordPress core is fine. It's maintained by serious people and it shows. The problem is that a WordPress site is never just core: it's core plus that stack of thirty-one plugins, each one written by someone different, each one a door. Patchstack's data puts the median time from a vulnerability being disclosed to it being exploited in the wild at five hours. Not five days. Your maintenance person checks in monthly.

We're not going to pretend a static site is unhackable. But a site with no database, no admin login and no PHP runtime has almost nothing for those automated attacks to grab. Most of what gets probed simply isn't there.

Speed, and the part of the speed argument people get wrong

The Core Web Vitals Technology Report from HTTP Archive measures how real sites on each platform perform for real Chrome users. In the January to April 2026 data, roughly two-thirds of Astro sites pass Google's Core Web Vitals, and WordPress sits under half, last of the platforms measured. Next.js lands in between, passing on about 68% of origins on mobile, and as recently as 2023 barely a quarter of Next.js sites passed, so a modern framework badge has never guaranteed a fast site on its own.

So no, "modern JavaScript framework" does not automatically mean fast, and anyone selling you a React rebuild purely on speed is skipping a step. What the data actually says is that the default path matters. Astro's defaults ship almost no JavaScript, so the average Astro site is quick even when it was built carelessly. WordPress's defaults load a page builder, a theme and a dozen plugin scripts on every page, so the average WordPress site is slow even when someone cared. You can fight your platform's defaults in either direction. Most sites don't, which is why the aggregates look the way they do.

What standing still costs

Managed WordPress hosting is not cheap and never trends cheaper. WP Engine's entry plan is A$42 a month on annual billing. Kinsta starts at US$35. Add plugin licences, which for a typical small business stack (forms, SEO, backups, a premium theme) run another few hundred dollars a year, and add the human: someone has to apply updates, and either you pay a retainer or you're the retainer.

Our sites run on Cloudflare Workers, where the free tier covers 100,000 requests a day. Nearly every small business site we host costs zero dollars a month to serve, or five if it's busy. That's not a promotional rate. It's what serving pre-built pages costs in 2026 when there's no database and no PHP to run. Over five years, the hosting-and-maintenance gap alone is often bigger than the rebuild quote; we've put real numbers on this in our guide to what a website costs in Australia.

The market has noticed. W3Techs still has WordPress at just under 42% of the web, which is enormous, but the share fell for six consecutive months through the first half of 2026, the first sustained decline in a decade. Nobody's claiming WordPress is dying. It runs a third of everything and will for years. But the direction changed, and the sites leaving are disproportionately the kind we're talking about here: business sites that used WordPress because in 2016 there was no better option.

When staying on WordPress is the right call

Honesty section. There are three situations where we tell people not to migrate.

If your site is making money and nothing is on fire, the migration has to beat "do nothing", and do-nothing is a strong option. A stable WooCommerce store with clean plugins and a competent maintainer doesn't need rescuing just because a blog post said WordPress is insecure.

If your team lives in the WordPress editor, that workflow has real value. Five people who publish daily without asking a developer for anything is worth more than a faster homepage. (There's a middle path here, which we'll get to: keeping the WordPress editor and replacing everything else.)

And if the budget genuinely stops at a few hundred dollars, a well-tended WordPress site beats a half-finished migration every time. An abandoned rebuild is the worst outcome on this entire page.

What doesn't count as a reason to stay: sunk cost. The money already spent on the current site is gone regardless of what you do next.

Where to go, by what your site actually is

There's no single destination, and distrust anyone who says there is. The right target depends on what the site does all day.

If it's a content and marketing site, pages, services, a blog, the thing most businesses actually have, the answer is Astro. It renders everything to static HTML at build time, ships JavaScript only where a page genuinely needs it, and its content-collections model maps almost one-to-one onto WordPress posts and pages, which makes the export surprisingly mechanical. This is the migration with the best effort-to-payoff ratio we know of, and we've written up the full WordPress-to-Astro process separately.

If the site is really an application, logins, dashboards, quoting tools, anything where the page changes per user, you want a full-stack React framework. Next.js is the established choice with the biggest ecosystem and the most hosting options. TanStack Start is the newer one we build on ourselves: lighter, with typed routing end to end, and it deploys beautifully to Cloudflare. We've covered when we reach for it over Next.js in its own article. Just remember the Core Web Vitals numbers above. These frameworks make fast sites possible, not automatic, and for a plain marketing site they're more machinery than the job needs.

If the blocker is that your team won't give up the WordPress editor, headless WordPress keeps wp-admin as a pure writing tool and serves the public site from a static front end via the REST API. You keep the workflow, visitors stop touching the PHP runtime, and the attack surface shrinks to an admin URL you can hide. It's also the option with the most moving parts, so it earns its keep only when the editing workflow is genuinely load-bearing.

If it's a store on WooCommerce, the honest comparison is with Shopify, and Shopify usually wins for the businesses we work with, not on price but on everything that isn't your job to maintain any more: checkout, PCI compliance, payment plugins that update themselves. We've written up the WooCommerce-to-Shopify migration including the redirect work that most store migrations botch, and an Australian cost comparison if you're weighing the fees.

Where AI tooling changes the maths

Here's the part that's genuinely different about writing this in 2026 rather than 2022, and it's not really about WordPress at all. It's about what a rebuild costs.

84% of developers now use or plan to use AI tools, with about half of professionals using them daily. Tools like Claude Code work by reading and editing plain files in a git repository, proposing changes as diffs a human reviews. A site built on Astro or TanStack Start is exactly that: typed TypeScript files and markdown content, all in version control. An agent can add a page, fix a layout bug or update twenty service descriptions, and the type checker catches its mistakes at build time before anything ships.

WordPress is nearly the worst case for this way of working. The site's state is smeared across a MySQL database, plugin option tables and a themed PHP runtime. There's no diff to review, no types to check, and no safe way for an agent to operate on production. The AI boom is real, and it's lopsided: it accelerates the stacks that look like code and largely bypasses the one that looks like a database.

The practical effect is on price. Changes that used to be a dev ticket at agency hourly rates are now a reviewed ten-minute diff, and the rebuild itself costs a fraction of the quotes people remember from five years ago. We should be clear about the limits, because the same survey found half of developers distrust AI output: this only works on a clean codebase with types and version control. AI does not rescue a mess. It widens the gap between clean stacks and messy ones, which is precisely the gap between the destinations above and a thirty-one-plugin WordPress install.

The migration itself is a rankings exercise

Whatever destination you pick, the dangerous part isn't the technology. It's the URLs. Google's documentation on site moves with URL changes is the canonical reference, and the short version is that every old address needs a 301 redirect to its closest new equivalent, mapped page by page before launch, not patched afterwards.

We've seen what skipping this costs: a business that lost most of its enquiries because seventy-eight old URLs were left returning 404s after a rebuild. The design was fine. The map was missing. Our WordPress migration checklist walks through the whole sequence: crawling the old site, exporting Search Console before you lose it, building the redirect map, and the checks to run in the first fortnight after cutover.

Budget for this properly. On a typical small business migration, the redirect and content work is a third of the job.

Where we fit in

Pagecog does these migrations end to end: content export, redirect map, a design refresh rather than a pixel-for-pixel copy of the old site, and Cloudflare hosting that mostly costs nothing to run. If you're weighing it up, we'll audit your current site for free and tell you which of the paths above fits, including, sometimes, that you should stay where you are for now. The rest of how we approach the build is on the services page.