Three Legacy Platforms, 8.2 Million Sites
WebPulse's Common Crawl scan of 10 million domains detected 7,427,780 WordPress sites, 444,706 Drupal sites, and 352,042 Joomla sites. Together, these three legacy CMS platforms account for 82.2% of the framework-identifiable web. Each carries a distinct vulnerability profile, a distinct user base, and a distinct set of viable migration destinations. There is no single answer to the question of where legacy CMS sites should go. There are three answers, and they diverge sharply.
WordPress: The Headless Exit
WordPress sites split into two populations that require different migration strategies. Content-heavy sites with minimal interactivity — blogs, news outlets, marketing pages — migrate toward static site generators: Hugo (0 total CVEs, score 100), Astro (60 CVEs, score 90), or Eleventy. The content exports cleanly. WordPress's XML export format and REST API make content extraction straightforward for any competent development team. The security surface drops to near zero. The hosting cost drops by 60–80% because static files require no application server, no database, no PHP runtime. A site that cost $200 per month to host on managed WordPress hosting costs $20 per month or less on a CDN serving static files.
Interactive WordPress sites — those with e-commerce, membership systems, or complex forms — migrate toward headless architectures. WordPress becomes a content API (WP REST or WPGraphQL), and the front end moves to Next.js or Astro. This preserves the editorial workflow that non-technical teams depend on while moving the public attack surface to a framework with 92 total CVEs instead of 18,321. The trade-off: the WordPress installation still exists, still requires patching, still carries its CVE history. It is simply no longer internet-facing. For organizations with large editorial teams trained on the WordPress admin interface, this compromise is often the pragmatic path — it delivers the security improvement without the organizational disruption of retraining content authors.
Drupal: The Decoupled Middle Ground
Drupal's migration pattern differs from WordPress because Drupal's user base is different. Drupal sites tend to be institutional — universities, government agencies, large nonprofits — with complex content models, taxonomy systems, and role-based access controls. These organizations invested heavily in Drupal's content architecture over years of configuration, and that investment creates switching costs that exceed the framework migration itself. A university running Drupal with 40 content types, 200 taxonomy vocabularies, and role-based access for dozens of departmental editors cannot switch to a static site generator without rebuilding the entire content governance model.
The dominant Drupal migration path is decoupled Drupal: retaining Drupal as the content management backend while replacing the Twig-based front end with Next.js or Nuxt.js. Drupal's JSON:API module, now included in core, makes this architecturally straightforward. The result is a Drupal installation that serves structured data to a modern front end, reducing the public attack surface while preserving content workflows. Drupal carries 1,376 total CVEs. The decoupled approach does not eliminate those CVEs, but it removes the rendering layer from the public internet and restricts Drupal's exposure to authenticated internal traffic only.
The alternative — full Drupal replacement — is the path organizations take when they have outgrown Drupal's content model or when the Drupal version is so far behind that upgrading Drupal itself is as expensive as replacing it. Drupal 7, which reached end of life in January 2025, still runs on a measurable number of institutional sites. For these organizations, the migration is not Drupal-to-decoupled-Drupal. It is Drupal-to-something-else, and the destination depends entirely on the complexity of the content architecture being replaced.
Joomla: The Full Replacement
Joomla's migration path is the simplest to describe and the hardest to execute. Joomla sites migrate to something else entirely. There is no headless Joomla ecosystem. There is no decoupled Joomla architecture with industry adoption. Joomla carries 1,313 total CVEs and a WebPulse overall score of 52.5 — the second-lowest of any tracked framework. Its 352,042 detected sites represent organizations that chose Joomla in 2008–2014 and have not made an active technology decision since.
The migration destination depends on the site's complexity. Simple Joomla sites — brochure pages, small business sites — migrate to managed platforms (Shopify, Squarespace) or static generators (Hugo, Astro). Complex Joomla sites with custom extensions migrate to Laravel, Django, or Rails, requiring a full application rebuild. The 5 CVEs disclosed in Joomla in the last year, including 2 rated high severity, add urgency to a migration that most Joomla operators have been deferring for years.
The Consolidation Pattern
The migration matrix reveals a consolidation trend. WordPress, Drupal, and Joomla — three platforms that together account for 8.2 million sites — are converging on a narrow set of modern destinations. Next.js (263,488 detected sites, score 80.8) absorbs the interactive migration traffic. Astro (20,080 sites, score 83.1) absorbs content-heavy sites that prioritize performance and security. Hugo (16,743 sites, score 77.2) absorbs sites that want zero CVEs and zero runtime dependencies.
The modern web is not fragmented. It is consolidating around three to four frameworks that score above 77 on every security and performance dimension. The migration matrix is not a menu of equivalent choices. It is a decision tree with three entry points (which CMS are you leaving?), two branching factors (how complex is your site, and how much editorial workflow investment do you carry?), and a small number of validated exit points. Organizations that understand their entry point and their constraints can select a migration target with data rather than vendor pitches.
