Pre-Migration Assessment: Metrics and KPIs for WordPress to Drupal Decisions

Image

Organizations considering how to migrate WordPress to Drupal are usually responding to real pressure points: scaling challenges, security requirements, complex content models or the need for deeper integration across systems. But intuition alone isn’t enough to justify a migration of this size.

A pre-migration assessment grounded in clear metrics and KPIs helps teams move beyond opinion and toward evidence. By establishing a baseline for performance, technical limits and operational costs, you can objectively evaluate whether Drupal meaningfully improves on your current WordPress setup – or whether optimization within WordPress is the smarter path. 

This article outlines a structured, data-driven framework to assess that decision before committing time, budget and organizational energy.

Should you migrate from WordPress to Drupal?

The decision to migrate from WordPress to Drupal should be treated as an architectural evaluation, not a popularity contest or a response to isolated frustrations. Both platforms are mature, open-source content management systems capable of supporting large, high-traffic and mission-critical sites. However, they are optimized for different priorities. Understanding those differences is essential before evaluating performance metrics or cost implications.

WordPress is architected around a publishing-centric model. Its core data structure is intentionally simple, prioritizing speed of content creation and ease of use for non-technical teams. Over time, WordPress has expanded its capabilities through custom post types, metadata and a block-based editor. Advanced functionality (such as workflow management, granular permissions, multilingual delivery or structured content relationships) is typically introduced through plugins or custom development. This layered approach allows WordPress to remain flexible and approachable, but it also means that complexity must be consciously designed and maintained rather than enforced by default.

Drupal takes the opposite approach. Its architecture is content-model-first, treating entities, fields, taxonomies and relationships as core concepts rather than extensions. Content structure, access control and configuration are deeply integrated into the platform and managed as deployable configuration rather than database-only settings. This makes Drupal particularly well-suited to organizations with complex content ecosystems, strict governance requirements or the need to deliver the same content across multiple channels via APIs. However, these strengths come with increased implementation effort, higher technical skill requirements and more rigid development workflows.

As a result, migrating from WordPress to Drupal is typically justified only when organizational needs outgrow WordPress’s architectural assumptions. A pre-migration assessment is essential to determine whether those needs truly exist or whether optimizing the current WordPress implementation would achieve the same outcomes with less disruption.

Establishing your WordPress baseline

Establishing a WordPress baseline means creating a clear, factual snapshot of how your site performs and operates before you change anything. This snapshot becomes your reference point. Without it, you can’t objectively answer whether a migration to Drupal improved performance, reduced complexity or justified its cost.

A baseline also prevents misdiagnosis. Many issues attributed to “WordPress limitations” are actually caused by hosting constraints, excessive plugins, unoptimized media or missing caching layers. At the same time, some organizations genuinely outgrow WordPress in areas like content governance, permissions or structured data modeling. Baseline metrics help you tell the difference.

Use the following metrics to document your current state.

• Page load times: Measure how fast key pages load for users and search engines. Use Google PageSpeed Insights for Core Web Vitals (LCP, INP, CLS) and real-user data when available and GTmetrix or WebPageTest for full page load timing and waterfall analysis. Test your homepage, top landing pages and conversion pages in incognito mode, run multiple tests and record the median result along with test location, device type and date.
• Server response time and time to first byte (TTFB): Measure how long the server takes to respond before the page starts rendering. Open your browser’s developer tools, reload the page and check “Waiting for server response” in the Network timing panel. You can also capture this in GTmetrix or WebPageTest. Consistently high TTFB usually indicates hosting, caching, database or server-location constraints rather than front-end issues.
• Total content volume (migration scope): Count how many posts, pages and custom post types exist. The most accurate method is WP-CLI, which gives exact counts by content type and status. If command-line access isn’t available, use the WordPress admin screens for posts, pages and custom types and manually record totals. This defines how complex and time-consuming a migration would be.
• Media library size (storage and migration time): Measure how much disk space your media uses and how many files you have. Start with Tools → Site Health → Info to see the uploads directory size, then use a media size plugin or your hosting file manager to confirm totals. Record total size in GB, number of media items and note any unusually large files that may need optimization.
• Active plugins (functional dependencies): Identify what functionality your site depends on today. Use WP-CLI or the plugins screen to list active plugins, then document what each one does (SEO, forms, caching, ecommerce, analytics, etc.). For performance insight, use Query Monitor or New Relic (available on Pantheon) to see which plugins generate heavy database queries or load large scripts. This step prevents losing critical features during migration.
• Monthly traffic volume (scale requirements): Capture how much traffic your site handles and whether it spikes. Use Google Analytics to record users, sessions, pageviews, traffic sources and peak periods for the last two or three months. If Analytics isn’t set up, use a WordPress analytics plugin connected to GA. This data informs hosting and caching needs more than the CMS choice alone.
• Bounce rate and session duration (engagement baseline): Measure how users interact with your site today. In Google Analytics, record overall bounce rate and average session duration, then capture the same metrics for your top pages and for mobile versus desktop. These numbers don’t judge the CMS – they establish a behavioral baseline to confirm whether future changes improve or harm user experience.

When collected together, these metrics form a control group for every future decision. Whether you migrate to Drupal or optimize WordPress, you’ll be able to prove – quantitatively – what changed and whether it mattered.

Technical evaluation KPIs

The goal of the following technical KPIs is to identify pain-point thresholds where your current architecture becomes a recurring operational problem (slowdowns during peak usage, fragile performance tuning, frequent emergency patching or a growing need to serve content to multiple channels):

Concurrent user capacity

Measure how the site behaves under realistic simultaneous usage, especially authenticated flows like ecommerce, portals or dashboards. Use load-testing tools (k6, JMeter, Loader.io) to simulate concurrent sessions across critical journeys (homepage → search → login → checkout). Track error rates (429/500/502/504), tail latency (p95/p99) and infrastructure saturation (CPU, memory, PHP worker queueing). Pair this with application performance monitoring (APM) – such as New Relic, which is available on Pantheon – to identify whether constraints come from PHP workers, database connections or cache misses. If failures occur primarily during logged-in traffic, the issue is usually session handling and caching strategy rather than raw CMS throughput.

Database query performance

This KPI shows whether your content model and extension footprint generate queries that don’t scale. Measure slow transactions and queries using APM, database slow query logs and WordPress tooling like Query Monitor. Document where high query counts, repeated meta queries or slow filters appear. If indexing or caching dramatically improves results, that’s an implementation issue. If complex relational queries remain slow after optimization, that’s a structural signal.

Time to first byte (TTFB)

TTFB isolates backend responsiveness before rendering begins. Measure medians across multiple runs using WebPageTest, GTmetrix or browser dev tools. Classify results using consistent thresholds (≈200ms excellent, ≈300ms good, ≥500–800ms problematic) and compare cached vs uncached responses. Persistently high TTFB after hosting and caching improvements usually points to backend efficiency limits.

Security incidents and patch requirements

Treat security as an operational load. Track emergency patch frequency, critical updates per quarter and whether issues originate in core or extensions. The migration-relevant question is whether patch coordination and risk mitigation are disrupting delivery.

Third-party integrations

Inventory every integration touching identity, data capture, personalization, analytics and commerce. Record how each integrates (plugin/module, API, client-side script), data direction and business criticality. Critical integrations demand verified replacement and testing plans.

API call volume

If content feeds multiple frontends, your CMS is an API platform. Measure requests per minute, burst traffic, cache hit rates and p95 latency via APM, proxy logs or content delivery network (CDN) analytics. Growing API demand stresses caching, query efficiency and preview workflows.

Mobile performance (Core Web Vitals)

Measure with PageSpeed Insights, Search Console and CrUX data where available. The key question isn’t ecosystem averages – it’s whether your most important mobile pages consistently meet CWV targets without excessive, ongoing optimization work.

Business case metrics

From a business perspective, you need to identify what will change in cash spend, team time and risk – and if those changes pay back within a reasonable horizon. The goal is to measure your current costs first, then model what would change after migration:

• Current annual hosting costs: Add up the last 12 months of spend across hosting, CDN, WAF/security add-ons, database services, monitoring and extra environments. Record what drives cost (traffic spikes, storage, bandwidth) so you can tell whether a hosting/architecture upgrade would solve the problem without migrating.
• Plugin/theme licensing fees: List every paid plugin/theme plus SaaS subscriptions that power site features (search, forms, backups, personalization). These are recurring costs you may eliminate – or replace with implementation effort elsewhere.
• Developer hours for maintenance: Use time tracking or ticket history to total routine updates, bug fixes, performance tuning, integration upkeep and content support. Convert hours into dollars using your blended internal/agency rate.
• Time spent on security updates: Track monitoring, staging validation, patch deployment, emergency fixes and incident response as separate hours. This shows whether your security burden is occasional hygiene – or an ongoing operational tax.
• Team PHP/Drupal skill level (1-5): Score editors and engineers separately and include ramp-up costs: training spend plus productivity loss during adoption.
• Estimated migration timeline: Build the timeline from baseline scope (content volume, media size, integrations, rebuild needs) and translate it into resourcing (PM, dev, QA, DevOps) with contingency.
• Downtime tolerance: Quantify the cost of downtime (revenue, leads, SLA penalties) and choose a cutover strategy that fits it.
• Content editor satisfaction score: Survey editors and pair that with measurable output (time to publish, support tickets, pages/week). A migration only “wins” if it improves or at least preserves editorial throughput.

Creating your migration decision matrix

At this point, you’ve gathered baseline metrics and evaluated technical and business KPIs. The final step is to synthesize that data into a clear, defensible decision framework that removes ambiguity and prevents emotionally driven migrations.

Start with a weighted decision score (0-100). Assign weights to five factors that reflect enterprise priorities: strategic value, technical feasibility, risk profile, resource availability and timeline readiness. Score each factor on a 1-10 scale based on your documented findings, then calculate the weighted total. This ensures the decision reflects what matters most to your organization – not just technical preference.

Next, apply a risk assessment rating across five categories. Technical, security and operational risks are typically highest in WordPress to Drupal migrations due to module parity gaps, permission model differences, password hashing incompatibilities and training demands. Financial risk is usually medium, driven by cost overruns and hidden integration work, while organizational risk is often lower but still relevant. Each risk should have an explicit mitigation plan before proceeding.

Then model your ROI timeline. If your business case cannot justify benefits within the specific window you decide, migration risk increases sharply.

Lastly, calculate critical success factors met (%) using a checklist across content readiness, module parity, permissions, integrations, SEO preservation and team training.

Example scenarios

Let’s imagine an enterprise platform with the following conditions:

• More than 3 million monthly visits with significant authenticated traffic.
• Time to first byte reaches approximately 750ms during peak load.
• Over 40 active plugins, including custom permission extensions.
• More than 20 third-party integrations requiring ongoing coordination.
• Security updates frequently require emergency scheduling.
• Structured content delivered to multiple frontends via APIs.
• The internal team already has Drupal experience.

These points show us that performance degrades under load, permission complexity is managed through layered plugins, security updates are operationally disruptive and the organization needs structured content and API-first delivery.

The decision matrix may look something like this:

With a final score of 76/100, the migration cost from WordPress to Drupal is justified because it reduces long-term operational friction and improves scalability.

Now, let’s take a look at a mid-sized marketing platform with the following baseline:

• Approximately 250,000 monthly visits, primarily anonymous traffic.
• Time to first byte averages 280ms under normal load.
• Fewer than 20 active plugins, none generating heavy database queries.
• Limited third-party integrations with minimal custom API requirements.
• Security updates are routine and rarely require emergency intervention.
• Content structure is straightforward, with no complex permission model.
• The internal team has WordPress experience but no Drupal expertise.

These points show us that performance remains stable under load, plugin usage is manageable, security overhead is predictable and the content model does not require advanced structural capabilities.

The decision matrix may look something like this:

With a final score of 47/100, the data suggests that migrating to Drupal would introduce more risk and cost than measurable benefit. In this case, optimizing the existing WordPress architecture is the more rational decision.

Migrating from WordPress to Drupal with Pantheon

If your assessment shows that a WordPress-to-Drupal migration is justified, execution quality becomes the deciding factor between long-term success and costly rework. This is where Pantheon plays a critical role. 

Pantheon provides a unified WebOps platform purpose-built for both WordPress and Drupal, allowing teams to plan, test and migrate with confidence. With Pantheon, you get benefits from a container-based architecture, automated Dev, Test, Live workflows and integrated version control. Also, Pantheon supports configuration-as-code, Multidev environments for parallel workstreams and enterprise-grade security and performance out of the box. This lets teams validate performance KPIs, rehearse cutovers and mitigate risk before launch – while giving developers and content teams the tooling they need to stay productive post-migration.

Whether you ultimately migrate to Drupal or optimize WordPress, the decision should be grounded in data and executed on a platform that minimizes operational friction like Pantheon.

If you’re evaluating a WordPress-to-Drupal migration, start with Pantheon today and get the visibility, control and scalability to do it right!