Most WordPress migrations start with a crisis.
A security breach that makes the board ask uncomfortable questions. A redesign that burns nine months and never launches. The senior developer quits and nobody else can maintain the site, so the company scrambles, picks the first alternative that looks viable, and migrates under pressure, overpaying and under-planning the entire time.
The companies that migrate well make the decision before the crisis arrives. They bring a scored recommendation to a planning meeting, not a vague “we should probably look at this” to a Slack thread.
That’s what this framework delivers. Six factors, each scored against your own infrastructure, producing a stay/modernize/migrate recommendation you can defend with data. We built this genre of evaluation before for a different platform. The WordPress version follows the same structure because the decision logic is identical, even if the numbers differ.
How do you know when it’s time to leave WordPress?
It’s time when four or more of the six factors below (performance, cost, security, governance, talent, and content velocity) score as migration drivers against your actual infrastructure. One bad metric isn’t enough. A slow site that’s cheap, secure, and staffed is a site to optimize. A slow site that’s also expensive, understaffed, and running 30 plugins with unpatched vulnerabilities is a different proposition, because the cost of staying is measurable and it’s growing.
The six factors below capture the full evaluation surface. Score each one honestly against your actual infrastructure, not against WordPress in the abstract. A WordPress site on managed hosting with 12 well-maintained plugins is a fundamentally different risk profile than one on shared hosting running 47 plugins maintained by a single freelancer.
What should you evaluate before migrating from WordPress?
Six factors: performance against your pipeline, total cost of ownership across every vendor, security exposure relative to your regulatory environment, governance dependency on WordPress.org, talent availability in your market, and content velocity against your campaign calendar.
Each factor scores 1 to 5. A 1 means WordPress is performing fine in that dimension. A 5 means the data clearly points toward migration. Add the six scores for your total.
Read the six factors below, then score them in the tool at the end of the section. Nothing is gated: your total and its verdict appear the moment the sixth factor is rated.
Factor 1: Performance and pipeline impact
WordPress’s performance problem shows up directly in your pipeline. In field data, 49% of WordPress origins pass Core Web Vitals on mobile against 53% for the web overall, and the median WordPress page weighs 3 MB against 2 MB across all technologies. 1 Source 1 HTTP Archive Core Web Vitals Technology Report, July 2026 data, read August 20, 2026. WordPress, mobile, all geographies and ranks: 49% good Core Web Vitals, 56% good LCP, median page weight 3 MB. All technologies, mobile: 53% good Core Web Vitals, 65% good LCP, median page weight 2 MB. Field data from the Chrome UX Report at the 75th percentile. The gap sits in loading rather than interactivity: WordPress beats the web average on responsiveness and layout stability, and loses on how quickly the main content appears.
Put that in pipeline terms: 53% of mobile visits are abandoned if a page takes longer than three seconds to load (Google, The Need for Mobile Speed, 2016, the finding that still anchors Google’s own speed guidance). Nearly half of WordPress origins miss the good-LCP threshold on mobile, so on a large share of WordPress sites the majority of mobile visitors leave before they read a word, and that’s a conversion loss you can put a number on.
A real example of the cost: Lattice, the HR platform, spent a full year fighting WordPress to launch a rebrand, then shipped it on a new platform in two weeks once they moved off. The year on WordPress was lost to poor responsiveness, content jumping across screen sizes, and mobile performance below their brand standards. Their Director of Brand Design said the caliber of design “had to be much more simplistic than we wanted.” After migrating, Lattice recorded a 20% lift in site-wide conversion and cut its publishing cycle from two weeks to two days. 2 Source 2 Webflow Lattice customer story: 20% increase in site-wide conversion, 20% increase in organic traffic, publishing cycle from two weeks to two days. The case study credits the organic traffic lift to un-gating content resources rather than to the platform itself. The case study also reports a 20% increase in organic traffic, though it credits that to un-gating content resources rather than to the platform, which is a useful reminder that a replatform enables experiments rather than causing traffic on its own. These are vendor-published case studies, Webflow’s and Sanity’s, so apply the usual discount to the exact percentages, and note that both companies moved to platforms with ceilings of their own. Read them as evidence of the pattern, a year stuck and then weeks out, which is the part we see repeated in real migrations, not as a recommendation of the destination.
How to score this factor: Pull your Core Web Vitals from Google Search Console. Compare your mobile LCP and INP against your competitive set. If you’re below the 75th percentile of your competitors, that’s a migration driver.
| Performance score | Meaning |
|---|---|
| 1 | Core Web Vitals pass on mobile. Load times competitive with your market. |
| 3 | Passing on desktop, failing on mobile. Page weight growing annually. |
| 5 | Failing Core Web Vitals on both surfaces. Load times 3x or more slower than competitors. |
Factor 2: Total cost of ownership
The number that catches most companies off guard is the real WordPress cost, not the hosting invoice. The everything-included number.
The real total cost of ownership, meaning every WordPress line item added together rather than just hosting, runs $44,400 to $148,500 per year for a mid-market company. 3 Source 3 Mid-market WordPress TCO components: managed hosting $4,800 to $24,000/year; premium plugins $2,000 to $6,000/year; security tooling $400 to $1,500/year; developer maintenance $7,200 to $27,000/year; agency and contractor support $30,000 to $90,000/year. The spend hides across five separate buckets:
- Hosting: $4,800 to $24,000/year for managed hosting at production tier.
- Premium plugins: $2,000 to $6,000/year for a typical stack.
- Security tooling: $400 to $1,500/year.
- Developer maintenance: $7,200 to $27,000/year, meaning 60 to 180 hours a year no invoice itemizes.
- Agency retainers: $30,000 to $90,000/year, often the largest line, and the one filed under a different budget.
The cost is invisible because it’s distributed. Eight to twelve vendors, each sending a separate invoice: hosting, plugin marketplace, security scanner, CDN, backup service, staging environment, theme developer, freelance PHP developer. Nobody aggregates the total, so the line item finance would fight hardest is the one no invoice ever shows.
Compare that against the alternative: a modern static-site architecture on managed hosting costs $0 to $600 per year in hosting with near-zero security maintenance. Getting there is a one-time cost. On our own price list, a straightforward single-site move starts at $10,000, a redesign starts at $25,000, and a multi-site estate like the one modeled here runs $50,000 to $120,000, phased. Divide that by what the move takes off your annual bill and you have your payback period, before counting performance and velocity gains. For the full line-by-line analysis, see our WordPress cost breakdown.
The methodology mirrors what we’ve done for HubSpot’s real cost. The pattern is identical: the headline price understates actual cost by 2 to 3x.
How to score this factor: Pull every WordPress-related invoice and internal labor allocation for the past 12 months. Aggregate. Compare against 3x the cost of alternatives at equivalent scale.
| Cost score | Meaning |
|---|---|
| 1 | Total WordPress cost under $30,000/year and stable. |
| 3 | Total cost $30,000 to $80,000/year, or growing faster than revenue. |
| 5 | Total cost exceeds $80,000/year and rising. Cost of alternatives is 3x or more lower at equivalent scale. |
Factor 3: Security exposure
The WordPress security surface is large and growing fast, and the window to patch is shrinking. The ecosystem produced 11,334 new vulnerabilities in 2025, a 42% year-over-year increase (Patchstack, 2026), and attackers move on the ones they target within hours of disclosure. 4 Source 4 Patchstack State of WordPress Security in 2026. 91% of vulnerabilities are in plugins and 9% in themes; only 6 were in WordPress core. Weighted median time to first exploit: 5 hours for heavily exploited vulnerabilities. 46% did not receive a developer fix in time for public disclosure.
WordPress accounts for 95.5% of all detected CMS infections (Sucuri, 2023 Hacked Website Threat Report). 5 Source 5 Sucuri 2023 Hacked Website & Malware Threat Report, published June 2024. 39,594 sites cleaned; WordPress 95.5% of CMS infections. Still the most recent edition in this series. Not because WordPress core is uniquely insecure, since that 91% plugin attribution is the real story. Each plugin is a dependency you didn’t write, maintained by a developer you don’t control, updated on a schedule you can’t enforce: your security posture is only as current as the least-diligent developer in your plugin list.
WordPress accounts for 95.5% of all detected CMS infections, not because the core is broken, but because 30 plugins mean 30 separate attack surfaces.
A regulatory deadline compounds the pressure. EU Cyber Resilience Act reporting obligations under Article 14 have applied since September 11, 2026, imposing 24-hour exploit notification requirements on commercial plugin developers, well ahead of the regulation’s main application date of December 11, 2027. If a plugin in your stack hasn’t published a CRA compliance plan, their regulatory exposure becomes your operational risk. For the compound vulnerability analysis, see our WordPress security deep-dive.
How to score this factor: Count your active plugins. Check how many have published security patches in the last 90 days. If you’re running 20 or more plugins with 5 or more from developers who haven’t addressed CRA compliance, score this factor 4 or 5.
| Security score | Meaning |
|---|---|
| 1 | Under 15 plugins, all from established vendors with recent patches. No prior incidents. |
| 3 | 15 to 30 plugins, mixed vendor quality, patching is reactive rather than proactive. |
| 5 | 30 or more plugins, multiple from solo developers, patch lag measured in weeks. Prior security incident. |
Factor 4: Governance risk
This factor didn’t exist in the WordPress evaluation two years ago. It does now.
WordPress.org is controlled by a single individual who has already shown he will seize plugins and block hosting providers in a commercial dispute, and the consequences priced into both the company and its workforce were severe. 6 Source 6 WP Engine v. Automattic litigation, 2024 to 2026. 159 employees (8.4% of the company) took Automattic’s severance buyout offer in October 2024. BlackRock marked Automattic down 10%, to $37.50 per share from $41.70, per TechCrunch, December 2, 2024. A February 2026 WP Engine filing alleges royalty demands were planned against 10 further companies; Automattic disputes the characterization.
None of this is hypothetical. The Advanced Custom Fields plugin, installed on millions of sites, was seized and republished under the same slug through WordPress.org. Hosting providers were threatened with directory delisting. The update infrastructure that delivers your security patches is the same infrastructure that was used as leverage during the dispute.
Ask your CTO this: if WordPress.org blocked your hosting provider tomorrow, what’s your recovery time? If nobody has modeled it, your organization is carrying unpriced risk on core infrastructure, an outage whose length no one can even estimate.
How to score this factor: Does your organization have a contingency plan for WordPress.org governance disruption? Can you update plugins and core independently of WordPress.org?
| Governance score | Meaning |
|---|---|
| 1 | Self-hosted update infrastructure, no dependency on WordPress.org for critical operations. |
| 3 | Standard WordPress.org dependency but diversified hosting and plugin sources. Contingency exists but is informal. |
| 5 | Fully dependent on WordPress.org for updates, plugins, and hosting compatibility. No contingency modeled. |
Factor 5: Talent availability
WordPress developers are not scarce; the platform runs two in five websites. The risk in this factor is the shape of the pool, which is drifting away from professional use, and how much of your site’s knowledge sits with one or two people.
Stack Overflow’s 2024 Developer Survey shows WordPress used by 11.1% of professional developers against 17.8% of non-professional respondents, the segment the survey calls “Other Coders,” with PHP at 18.2% overall and below its historical peaks. 7 Source 7 Stack Overflow Developer Survey 2024. WordPress: 11.1% of professional developers, 17.8% of the “Other Coders” segment, meaning people who code but not professionally. The gap is the meaningful signal that WordPress is drifting toward non-professional use. PHP at 18.2% overall. The 2025 survey dropped this segment, so 2024 remains the citable comparison. The gap between those two numbers is the signal worth watching, because it says the platform is more common among people who code as a sideline than among the people you would hire to maintain a production estate.
Developer sentiment reinforces the trend. The Jamstack Community Survey (2022) found WordPress had the highest usage of any CMS at 37% alongside the lowest satisfaction score of any CMS: 0.5, on a scale where anything under 1.0 means the users who want to stop using a tool outnumber those who want to use it more. 8 Source 8 Jamstack Community Survey 2022, the final edition of the survey. No equivalent was published in 2023 to 2025, but Stack Overflow and W3Techs trend data point in the same direction. Unenthusiastic WordPress users outnumber enthusiastic ones two to one.
brightonSEO, the world’s largest SEO conference, outgrew their WordPress setup as events grew more complex. Developers “often had to hack the monolithic CMS to manage multiple events” (Sanity/brightonSEO case study). After migrating to a headless architecture, they launched a new US conference site in two days and saw significant Core Web Vitals improvement. The case study expects traffic and ranking gains to follow, but does not report them as measured, so treat the launch speed and the performance improvement as the evidence here.
ClassicPress, a volunteer-run nonprofit fork created to keep WordPress’s classic editor and avoid Gutenberg, exists because a segment of developers rejected the platform’s own roadmap. It is actively maintained, with releases continuing through 2026, though its small scale is a fair measure of how much energy a protest fork can sustain. When developers fork your project to escape its direction, the talent you’re hiring against is splintering into camps that no longer share a common platform.
How to score this factor: Check your average time-to-fill for WordPress developer roles versus other technical positions. Survey your existing WordPress developers on platform satisfaction.
| Talent score | Meaning |
|---|---|
| 1 | WordPress roles fill in under 30 days. Developers report satisfaction and productivity. |
| 3 | Time-to-fill 30 to 60 days. Developers express platform frustration. |
| 5 | Time-to-fill exceeds 60 days. Key-person risk: one or two developers hold all institutional knowledge. |
Factor 6: Content velocity
This is the factor marketing teams feel every day, not once a quarter.
WordPress’s native editor lost its own user base, and most content teams closed the gap by taking on a paid dependency. Despite seven years of Gutenberg development, 41% of WordPress sites run a non-Gutenberg page builder instead (W3Techs, June 2026). Most content teams are on Elementor or Divi, third-party tools layered on WordPress that add page weight, maintenance overhead, and a licensing cost you now can’t remove without breaking every page built on it.
The consequence: new page types, template changes, and layout variations require a developer. Content changes sit in a ticket queue. Publishing velocity is gated by engineering capacity, not editorial readiness.
Lattice saw this resolved after migration, with publishing new experiences going from two weeks to two days on the new platform. brightonSEO gained the ability to reuse content across events and launch entire conference sites in days, opening revenue streams that weren’t possible in their previous architecture.
How to score this factor: How many hours per week does your marketing team wait for developer capacity to publish content? Track how many content requests required a developer ticket last quarter.
| Content velocity score | Meaning |
|---|---|
| 1 | Marketing team publishes independently. No developer bottleneck for content operations. |
| 3 | Some content changes require developer involvement. Publishing cycles measured in days. |
| 5 | Most content changes require a developer ticket. Marketing team is consistently blocked by engineering capacity. |
How to read your score
Add your scores across all six factors. Minimum 6, maximum 30.
The four outcomes in full, so you can see where your score sits against the others:
| Total Score | Recommendation |
|---|---|
| 6 to 12 | Stay. WordPress is serving your needs. Optimize your current deployment. Revisit in 12 months. |
| 13 to 18 | Modernize. Legitimate concerns exist but no urgent pressure. Incremental improvements first, and headless WordPress specifically if Factor 1 is your main driver, since it fixes rendering and leaves the rest in place. Plan a deeper evaluation in the next 6 months. |
| 19 to 24 | Migrate. The evidence is clear across multiple factors. Plan a 6 to 12 month migration to modern architecture. Start by seeing what a move involves before committing to a destination. |
| 25 to 30 | Urgent migrate. Compounding cost, security, and capability constraints. Every quarter of delay adds measurable cost. Accelerate the timeline. |
One pattern repeats: companies scoring 19 or above have usually been deferring the evaluation for 12 to 18 months already. The evidence was there a year ago. What separates companies that migrate well from those that migrate in crisis is whether they ran the evaluation before the forcing function arrived.
A word on execution risk, because it’s the one thing that can turn a good decision into a bad quarter. Search rankings are not inherently at risk in a migration, but they are at risk from sloppy redirects. Every URL needs a 301 to its new equivalent, metadata and canonical tags need to carry across, internal links need updating rather than redirecting in chains, and the new sitemap needs resubmitting. Missed redirects, not the platform change, are the usual cause of a post-migration traffic drop. Budget for that work explicitly rather than assuming it comes free with the build.
Pressure-testing your score
A high score is a reason to price the alternative, not proof that you should take it. Before you take a migration recommendation to your leadership team, put the four strongest arguments for staying against it. Each of them has real weight, and each has a limit.
“Migration is too expensive.” This is true in absolute terms. Moving a multi-site estate runs $50,000 to $120,000 on our price list, and that’s a real number that has to come from somewhere in a year when it wasn’t budgeted. The limit is that it’s a one-time number set against a recurring one. Mid-market WordPress TCO is $44,000 to $149,000 every year. A company paying $90,000 a year that cuts the bill in half repays a $75,000 move in under two years, on cost savings alone. The question isn’t whether migration is expensive; it’s whether it’s more expensive than the alternative over the same horizon.
“Our content team knows WordPress.” Genuine institutional knowledge is worth protecting, and retraining a content team is a real cost that migration plans routinely underestimate. The limit is that the familiarity is often with a page builder rather than with WordPress: 41% of WordPress sites bypass the native editor entirely. If your team’s expertise is Elementor, that expertise doesn’t transfer to a headless WordPress build either. Check what your team actually knows before you price the retraining.
“WordPress still has 40.7% market share.” Scale is a real advantage. It means plugins for everything, developers in every market, and a solved answer to most problems. The limit is that market share is a lagging indicator: WordPress dropped 2.7 percentage points in the twelve months to August 2026, the first sustained decline in its history. Scale today doesn’t tell you what the hiring market or the plugin ecosystem looks like in three years.
“We’ll modernize with headless WordPress.” This is a legitimate path, and for a company whose score is driven by Factor 1 it may be the right one. Headless removes WordPress from the rendering path and fixes the frontend performance problem directly, at a fraction of a full migration’s cost and disruption. The limit is scope: the backend still runs the same plugin ecosystem with the same vulnerability surface, the same WordPress.org governance dependency, and the same talent market. If Factors 3 through 5 are what pushed your score up, headless defers the decision rather than resolving it.
The decision most companies defer
The pattern running through the wave of enterprises replacing SaaS tools is evaluation before the renewal forces the conversation. 35% of the teams Retool surveyed have already replaced at least one SaaS tool with something they built themselves (Retool 2026 Build vs. Buy Report). WordPress, despite its open-source label, behaves like a vendor relationship in the ways that matter: you depend on its ecosystem, its governance, its developer community.
The six-factor framework takes about two weeks of part-time work to score honestly. Pull Core Web Vitals, aggregate invoices, count plugins, survey developers, track content tickets. The evaluation itself is the deliverable, a scored recommendation you can bring to your leadership team.
Sixteen years of platform projects taught us that a migration is worth it not when the platform is annoying but when the score shows the cost of staying compounding faster than anyone has bothered to add up. A slow site you can live with. A slow site that’s also expensive, exposed, and understaffed, you can’t.
The factors here map onto the same lock-in mechanisms we’ve documented across every platform we’ve worked on. Your templates and page-builder markup are a Code Lock; your plugin configuration and content structure are a Data Lock; your undocumented automations and integrations are a Logic Lock; and the organizational muscle memory that makes switching feel existential is the Dependency Lock. Scoring the six factors is how you find out which ones actually apply at your scale.
If four or more factors scored as migration drivers, that’s the threshold where, across the migrations we’ve scoped, the cost of staying overtakes the cost of leaving inside 12 to 18 months. Treat it as a rule of thumb that tells you to run the Factor 2 numbers properly, not as the answer itself.
The difference between companies that migrate well and those that migrate in crisis is two weeks of evaluation done six months early.
The migration itself is consulting you can buy. The decision to look honestly at your infrastructure is yours alone.
The research is free. So is the diagnosis. 60 seconds →