Choosing a web platform from a list of features often leads to a poor decision. WordPress, Drupal, Symfony, and headless CMSs can all publish content, manage users, and call APIs. The real difference lies in how each solution organizes editorial content, business rules, permissions, integrations, and operation over multiple years.
A relevant choice does not seek the most powerful technology. It seeks the simplest solution capable of sustainably handling the real constraints of the project. A custom framework may be disproportionate for a mainly editorial site. Conversely, pushing a general-purpose CMS to perform a complex task can create a fragile and costly platform.
Start by separating content, profession, and experience
Three layers must be distinguished before talking about the product.
The editorial layer manages pages, media, taxonomies, translations, drafts, approvals, and content reuse. The business layer executes rules specific to the organization: calculations, workflows, fine-grained permissions, contracts, orders, documents, synchronizations, or asynchronous processing. The experience layer delivers these capabilities on a website, an extranet, a mobile application, a terminal, or another channel.
In a simple project, these layers can exist within the same tool. In a complex project, their separation often becomes the main factor of maintainability.
When WordPress is an excellent choice
WordPress is particularly effective when value comes from publishing and team autonomy: institutional site, media, landing pages, editorial catalog, multilingual blog, or content space with a few controlled interactions. Its ecosystem, familiar interface, and ability to speed up integration reduce the initial cost.
The project must, however, be framed. The types of content, fields, components, roles, and layout rules must be structured. An accumulation of plugins, competing builders, and business logic in the theme quickly turns the initial advantage into debt.
WordPress remains suitable for ambitious projects when used as a real CMS: child theme or controlled integration, reusable components, structured data, caching, observability, update policy, and isolation of business services.
When Drupal takes the lead
Drupal is comfortable when the content itself is rich, relational, and governed: numerous taxonomies, validation workflows, rights by role or scope, advanced multilingual, multisite, institutional portals or networks of contributors.
Its strength lies less in the number of modules than in its content model, its views, its permission management, and its configuration mechanisms. This power requires rigorous design and dedicated skills. A poorly modeled Drupal becomes as difficult to evolve as a custom application.
Drupal is therefore suitable when editorial complexity is a long-term requirement, not just when the number of pages is high.
When Symfony is the right center of gravity
Symfony is an application framework. It becomes relevant when the core of the project lies in specific business rules: client area, contractual workflow, pricing engine, marketplace, document management, integration with the information system, or data processing.
The team controls the model, services, API contracts, tests, and the lifecycle. This freedom allows for a precise architecture, but it involves building or integrating what a CMS already provides: editorial management, preview, media, contributor experience, and sometimes search.
Symfony can be associated with a back-office like Sonata, with a CMS, or with a dedicated interface. The question is therefore not 'CMS or Symfony,' but often 'which part of the system should be handled by custom business logic?'
What a headless architecture changes
In a headless architecture, the content system exposes its data via API and the interface is developed separately. This separation facilitates multiple frontends, content reuse, highly personalized experiences, and integration into a composable platform.
It also adds responsibilities: previewing, distributed caching, invalidation, API security, server-side rendering for SEO, management of redirects, analytics, monitoring of multiple applications, and coordination of deployments. A headless is not automatically faster or more modern. It is useful when the independence of channels or teams outweighs this complexity.
The fifteen criteria that really change the choice
1. Nature of the value
If the value comes mainly from the content, a CMS must remain central. If it comes from a proprietary process, the custom business solution must be the heart of the architecture.
2. Content model
Simple pages and a few taxonomies do not justify the same solution as a graph of multilingual content, versioned and shared between entities.
3. Editorial workflows
Drafting, legal review, local approval, embargo, translation, and coordinated publication must be considered from the outset.
4. Business rules
The more numerous, changeable, and critical they are, the more they must be isolated in testable services rather than scattered across editorial extensions.
5. Authorizations
The number of roles matters less than the subtlety of the perimeter: by organization, site, file, data type, action, or workflow step.
6. Multisite and multilingual
It is necessary to determine what is shared, locally overloaded, or completely independent. The choice of the foundation strongly influences future governance.
7. Integrations
CRM, ERP, PIM, SSO, payment, signature, storage, and marketing tools require contracts, error management, and observability, not just connectors.
8. Multiple frontals
A single site does not require the same separation as a site, a mobile application, kiosks, and partner interfaces.
9. Research
Simple editorial search, business filtering, full-text or hybrid search require different indexing models.
10. Performance and availability
Objectives must be quantified: traffic, peaks, response time, availability rate, and disaster recovery.
11. Security and data
The attack surface, personal data, permissions, and audit requirements may necessitate the separation of certain functions.
12. Contributor experience
An elegant but difficult-to-manage architecture shifts the cost to business teams and encourages workarounds.
13. Available skills
The foundation must be maintainable by an identifiable team. A rare or fragmented solution increases the risk of dependency.
14. Total cost
The cost includes development, but also licenses, updates, hosting, monitoring, QA, training, and reversibility.
15. Life expectancy
An eighteen-month campaign and a platform expected to last ten years do not require the same architectural investment.
The matrix represents three complementary dimensions rather than an absolute ranking. WordPress mainly occupies the area where editorial autonomy is strong and business rules are controlled. Drupal extends towards structured content, governance, and multisite or multilingual configurations. Symfony progresses with the complexity of business rules, data, and specific integrations. Headless or composable makes more sense when multiple independent channels need to use the same content. The overlapping areas show possible hybrid architectures: a CMS can retain the editorial aspect while Symfony handles the business side and APIs feed multiple experiences.
Four typical scenarios
Brand site with high editorial autonomy
Structured WordPress is often sufficient. The rules are simple, editing is quick, and operating costs are manageable. Specific needs can be isolated in a service rather than being turned into theme logic.
Multilingual and multi-contributor institutional portal
Drupal becomes attractive thanks to its content model, its permissions, and its workflows. However, it is necessary to invest in modeling and governance of configurations.
Extranet or business software
Symfony, possibly combined with Sonata and a CMS for content, offers better control over rules, tests, data, and integrations.
Omnichannel ecosystem
A headless or decoupled CMS can serve multiple experiences. The decision should include the cost of the frontend, previewing, observability, and orchestration.
Hybrid architectures are often the most realistic
A binary opposition masks effective combinations. A WordPress site can consume Symfony services. Drupal can expose its content to a dedicated application while retaining its rendering for certain pages. A Symfony back office can integrate an editorial component. A headless CMS can coexist with an independent business engine.
The condition is to define stable boundaries: data owners, API contracts, security responsibilities, caching strategy, and deployment rules.
The signs of an oversized choice
An architecture is probably too complex when teams cannot preview it locally, when each release depends on multiple deployments, when caches are impossible to explain, or when the majority of the product's capabilities will never be used.
Conversely, a foundation is undersized when business rules are duplicated, permissions rely on conventions, each integration changes the theme, or developments require permanent workarounds.
A decision must produce a trajectory
The deliverable of a scoping should not be the name of a tool. It should describe the components, responsibilities, flows, risks, operating costs, and scaling steps. It should also specify what can be replaced without rebuilding the whole.
Partitech works on WordPress, Drupal, Symfony/Sonata, and integrated architectures. This plurality allows starting from the need rather than imposing a single product. The right foundation is the one that gives editorial teams the necessary autonomy, protects the business, and remains usable over time.
Compare Partitech's expertise in WordPress, Drupal and Symfony/Sonata. The upcoming analysis of the multisite architecture is temporarily replaced by our multisite architecture reference. While waiting for the articles dedicated to API-first and headless use cases, respectively, consult our Symfony/Sonata expertise to isolate the business logic and its APIs and our front-end development service for decoupled experiences.
Maintained verified versions
As of August 17, 2026, the official WordPress API offers 7.0.4 as the current version. Drupal presents 11.4.5 as the actively maintained version and 10.6.15 to support the transition of Drupal 10 sites. Symfony indicates 8.1.4 as the stable version, 7.4.16 as the current LTS version, and also maintains the 6.4 branch according to its schedule. The term “headless” here refers to a family of architectures and not to a specific product version.
Official references
References consulted on August 17, 2026:
- WordPress — Official Documentation ;
- WordPress — Official Version API ;
- WordPress — Supported Versions Policy ;
- Drupal — Official Documentation ;
- Drupal — Maintained Versions of the Core ;
- Symfony — Official Documentation ;
- Symfony — Maintained Versions Calendar ;
- Partitech — WordPress Expertise ;
- Partitech — Drupal Expertise.