Is It Time to Migrate Your Website Off WordPress?

Two Emergency Releases in Six Days

A WordPress security release is an unscheduled event. On August 6, 2026 the project published one whose most severe fix is described in its own notes as a "Pre-auth reflected cross-site scripting (XSS) on the login screen with potential to lead to PHP code execution." Pre-auth means the attacker needs no account. The login screen is present on every installation.

The national vulnerability record for that flaw, CVE-2026-64638, scores it 8.9 and rates it High. It also carries the honest qualifier that escalation to remote code execution depends on "conditions outside of the attackers control," which is the difference between a serious bug and a catastrophe.

Six days later, on August 12, a second unscheduled release fixed an "Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript." That one needs an account, but only an Author account, which most publishing teams hand out freely.

Neither release is an argument for leaving. A project that patches within days of a report is behaving exactly as a maintained platform should, and the same August 6 notes confirm the fixes were backported "to all branches eligible to receive security fixes (currently through 4.7)." That is a decade of support most software never offers.

What the two releases do measure is obligation. Each one is unplanned work that lands on a team at a moment chosen by somebody else, and the next one arrives on a schedule nobody inside the business controls. The question worth asking is not whether the platform is safe. It is what your particular installation costs per year to keep safe.

The Question Is Not Whether WordPress Is Good

The feature argument is a trap, because both sides can win it. WordPress still runs 59.0% of all websites whose content management system is known, and 40.8% of all websites. No serious person calls that a failing platform.

The share has fallen every year since 2022, from 65.2% to 59.0%. Six points over four years is drift, not collapse, and anybody selling a migration on the strength of that curve is selling you a feeling. The platform is not going anywhere in your planning horizon.

So the decision has to rest on something the business can actually compute. That something is ownership of recurring risk and upkeep. Every platform hands some portion of that burden to the company running the site, absorbing the rest itself. The correct question is whether your split has quietly moved in the wrong direction.

This is the same discipline that governs the decision to replace a site at all, applied one layer down. There, the object of judgement is the site. Here it is the ground the site stands on.

Ownership of upkeep is not an abstraction, and it is worth being precise about what it means. On a fully managed platform the vendor patches the runtime, tests the extensions it permits, and carries the blame when an update breaks a page. On a self-hosted installation every one of those responsibilities sits with the company, whether or not anyone has been assigned to it.

That is why the honest version of this question sounds nothing like a technology debate. It sounds like asking who, by name, is accountable when the next unscheduled release lands, and what that person is not doing while they handle it. Most companies discover they cannot answer the first half, which is itself the finding.

What Staying Costs, Line by Line

Four costs accrue every year you stay, and each one can carry a real number rather than a score. A score invites debate. A number goes on a page next to a migration quote and settles it.

The runtime floor is the most concrete of the four, plus the one finance most often omits. WordPress will still run on PHP 7.4 or MySQL 5.5.5, but its own requirements page warns that "those versions have reached official End Of Life and may expose your site to security vulnerabilities." The software keeps working. The ground underneath it stops being supported.

The dependency surface is the second line, and it is sized by ownership rather than by count. A plugin with a named internal owner, a support contract, and a tested upgrade path is an asset. A plugin nobody has opened since installation is a liability sitting in production with write access to the database.

Scale gives a sense of the pool it is drawn from. A single 120-day window ending on August 7, 2026 carried 1,958 vulnerability records matching WordPress and plugin. That figure is a keyword match on record text rather than a verified product count, so treat it as the shape of the pool, not a census of it.

The first line, patch response, is the one this month makes vivid. Two unscheduled releases in six days is two occasions on which somebody stopped planned work, read release notes, tested against a staging copy, and shipped. Price it the way you would price any interruption: occurrences per year, hours per occurrence, loaded rate.

Most teams already carry that number without recognising it, because it is buried inside the monthly maintenance retainer they already pay. Pulling it out and naming it is what turns a comfortable recurring invoice into a comparable annual figure.

The fourth line, throughput drag, is the one that most often argues for staying. If your marketing team ships pages in hours on the platform you already have, that speed is worth real money, and a migration that turns hours into weeks has destroyed value no security argument recovers.

The DSF Replatform Crossover Curve

The DSF Replatform Crossover Curve is not a scorecard. It is two lines and the year they cross. Line A is the cost of staying, which accrues annually from the four items above. Line B is the cost of moving, paid once, covering the build, the content migration, plus the URL continuity work.

Read it in one sentence. If cumulative Line A overtakes Line B inside three years, the migration is a financing decision and belongs in front of whoever approves capital. If the lines never cross inside five years, staying is correct and the money belongs in governing the plugin surface instead.

Three years is the threshold because it is the horizon a finance function will underwrite. Beyond five the inputs stop being credible, since hosting contracts, team composition, and the platform itself all change. A model that needs a seven-year payback is a model that has been tortured into agreeing with a decision already made.

Keep the moving side honest as well. Deloitte finds that "Infrastructure modernization alone can reduce tech debt by 18% over five years." Eighteen percent over five years is a real gain and it is not a reset. Replatforming shaves the upkeep problem. It does not end it.

Line B is the easier half to gather, because vendors will quote it. Ask three firms for a fixed price covering the build, the content migration, and plus the redirect map. Require each to state what happens to search position at cutover. The spread between those three quotes tells you as much as the numbers themselves.

Two stop rules override the arithmetic in both directions. Do not move when the plugin surface is small, governed, and owned, however old the platform is. Do not schedule cutover inside your revenue peak, however favourable the curve looks.

The Performance Argument Is Weaker Than the Vendors Say

Speed is the reason most often given for leaving WordPress, and the measured evidence does not support it in the form it is usually offered. Across the web, WordPress sites pass Core Web Vitals 45% of the time against 85% for the best-governed platform measured. That gap is real. Its cause is not what you were told.

The web-wide figure gives that gap its context. As of the July 2026 report, "55.7 % of origins (↑ 0.8%) have good Core Web Vitals." Nearly half of everything on the internet fails the same bar, so failing it is common rather than exotic.

WordPress ships the lightest median page of any major platform at 2,894 KB, lighter than Squarespace at 3,974 KB, and one of the smallest mobile JavaScript payloads at 638 KB. The software as shipped is lean. Whatever is making these sites slow was added after installation.

The year-over-year movement names the mechanism. WordPress gained around 4%, matching Drupal. Meanwhile "Platforms with more tightly managed environments see the largest gains, led by Wix (around +14% year over year) and Duda (+11%)." Governance of the extension surface is what separates them, which is the same variable the cost lines are built from.

It matters commercially because Google states that "Core Web Vitals are used by our ranking systems." And the upside is not theoretical: after a performance programme, T-Mobile reported "the conversion rate of prospect visits with shopping intent improving 60%."

What the Exposure Is Actually Worth

Risk only belongs in this decision if it carries a number, because a migration quote carries one. Three published figures put the exposure on the same page as the invoice, and all three come from organisations that ran the study rather than reported on it.

Verizon reports that "Nearly a third (31%) of all breaches start with vulnerability exploitation", with third parties involved in 48% of them. IBM puts "the global breach average of $4.99 million".

For WordPress specifically the evidence is not hypothetical. The federal catalogue of exploited vulnerabilities added a core flaw on July 21, 2026 and gave agencies until August 4 to remediate it. Its description states that "WordPress Core contains a SQL injection vulnerability when a plugin or theme passes untrusted input."

Read that description carefully, because it is the whole argument in one sentence. The flaw is in core. The thing that triggers it is a plugin or a theme passing untrusted input. The boundary between what the platform owns and what you own is exactly where the money is.

One honest limit. A catalogue listing binds federal agencies, not private companies, so it imposes no deadline on your business. Its value here is different and better: it is evidence that the flaw was being exploited in the wild, not merely reported.

The average cost figure is also moving in the wrong direction for anyone hoping to defer this. IBM reports that breaches involving attacker-side automation now run around a million dollars above the global average, which raises the expected loss attached to every unowned dependency without changing anything about your site.

None of this makes exposure the deciding term. It makes it a term with a number, which is all the curve requires. A company that has read what deferred website maintenance actually costs will recognise the pattern: the expense is invisible right up to the moment it is the only thing anyone is discussing.

When Staying Is the Right Answer

Three conditions make staying correct, and they are conditions rather than preferences. The first is that the site earns its keep through editorial throughput. If the business publishes constantly and the platform lets it, that velocity is the asset. It is also the hardest thing to carry through a migration intact.

The second is a governed plugin surface. Small is good, owned is better, and owned matters more than small. Every plugin in production should have a name attached to it, a support arrangement, and somebody who has tested the next version.

The third is operational competence. A team that patches within days, keeps the runtime above end of life, and knows what every extension does is already absorbing the upkeep well. Moving that team to a new platform buys very little and costs a great deal.

Governance is not free, and the benchmark says so. Well-positioned firms "typically set aside around 15% of their IT budgets for tech debt remediation", against an observed technical debt load of "21% to 40% of an organization's IT spending".

That gap is the uncomfortable part of this article. A company that has never funded the 15% has not yet earned the right to blame its platform, because it has not tested whether the platform is the problem. The cheapest possible first move is to fund governance for a year and re-run the curve.

Two emergency releases in six days is not an argument for leaving WordPress. It is an argument for knowing, to the dollar, what staying costs you per year.

If you want the four annual figures established before you price anything, that is precisely what a Website Health Audit produces: the patch load, the unowned dependencies, the runtime position, and the throughput measurement, in numbers you can put beside a quote.

FAQ — Migrating Off WordPress

Next Steps — Run the Curve

▶ Count the unscheduled security releases your team absorbed in the last twelve months, then multiply by the hours each one cost to test, stage, and deploy.

▶ List every plugin and theme in production beside the name of the person responsible for it. The blank rows are your unowned dependency surface.

▶ Check which PHP and database versions your hosting actually runs. Confirm whether either has passed end of life.

▶ Measure days from written to live on the last ten pages marketing shipped, and decide whether the platform or the approval chain is the constraint.

▶ Put those four annual figures against one migration quote, and find the year the lines cross.

When the numbers say move, the build is the next decision, and it is a larger one. Immersive Web Design & Development is where that work happens.