Drupal vs TYPO3: which fits your team and your upgrade rhythm
A regulated or public sector team shortlisting Drupal and TYPO3 is choosing between two GPL PHP enterprise CMSs, and neither license should decide it. Both are GPL-based, and extensions in both ecosystems can be sold or used commercially. Choose Drupal when you want a large contributed module ecosystem, a predictable release calendar with a major version roughly every three years, and a team that is comfortable with frequent minor and security updates. Choose TYPO3 when you want a long-term support cadence built around LTS releases, a mature multi-site tree model for editorial organizations, and a team already comfortable with its extension conventions. Neither is a licensing barrier, so the decision turns on operations and people.
Start with upgrade rhythm. Drupal core publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, and Drupal 10 reaches end of life on December 9, 2026, while Drupal 12 is scheduled for the week of December 7, 2026. TYPO3's roadmap lists v12.4, v13.4 and v14.3 as LTS releases with free support ending in 2026, 2027 and 2029 respectively, and links to paid Extended Long Term Support after free support ends. Map your content and module inventory against those dates, and ask each vendor or partner to confirm the ELTS pricing and terms for your version before you commit. Then test the other axes: multi-site and multilingual needs, whether your PHP and database stack matches (Drupal 12 requires PHP 8.5 or later, TYPO3 14 accepts PHP 8.2.0 up to 8.5.99), and whether the local market has Drupal or TYPO3 developers you can hire or contract for the next three to five years.
Which platform fits which scenario
This table matches common scenarios to the platform that usually fits better, and states the condition under which each choice holds. Read each row as a starting point: the deciding factor is often your team's skills, your release-planning tolerance and the agencies you can hire, so confirm those before committing.
| Scenario | Better fit | Condition under which it holds |
|---|---|---|
| Multi-country public sector portal with many languages | Drupal | Holds when you need many content languages and sites managed centrally, and your team can plan for a major upgrade roughly every three years on the core schedule. Confirm each language and site setup with a pilot before you commit. |
| Fixed long-term support window for budgeting | TYPO3 | Holds when the budget owner needs a published LTS calendar. TYPO3 lists v13.4 with free support ending in 2027 and v14.3 with free support ending in 2029. Ask what ELTS would cost for your chosen version before the window closes. |
| Single-language corporate site with a small team | Either, leaning TYPO3 if the team already knows TYPO3 | Holds when content needs are simple and the team's skills decide the outcome. Both are GPL PHP platforms, so compare the editor experience and the extensions you need in a short proof of concept. |
| Team with existing PHP skills but no Drupal experience | TYPO3 for TYPO3 experience, Drupal if you can hire Drupal specialists | Holds when the existing PHP staff can ramp up quickly on the chosen platform. Ask each candidate agency for references on projects of similar size, since both platforms depend heavily on specialist developers. |
| Headless front end with a separate JavaScript team | Drupal with the core JSON:API module, or either platform used as an API backend | Holds when the front end is built in React, Vue or Astro. Confirm the API surface, preview and caching needs with your front-end team, since the cost of a decoupled setup sits mainly in front-end hosting and preview work. |
| Upgrade planning in a regulated environment | TYPO3 if a fixed LTS calendar matters most, Drupal if a predictable annual-style core cadence suits your change process | Drupal lists bugfix releases on the first Wednesday of each month, security releases on the third Wednesday and new major versions typically every three years. TYPO3 publishes LTS dates per version, so map each calendar to your change board. |
| Multi-site with shared modules or extensions | Drupal for a shared codebase with many sites, TYPO3 when a single installation with a shared page tree suits your editors | Holds when site count and editorial structure are settled. Ask both candidate teams to demonstrate the multi-site setup you need, since the right answer depends on how far your sites share content and permissions. |
| Extension licensing and sold add-ons | Either, after a licensing review | Both platforms are GPL-based. TYPO3 states that extensions form a combined program under GPL v2 or later and may be sold if license terms are unchanged. Confirm with counsel how any commercial module or extension you plan to buy fits your procurement rules. |
How the Drupal and TYPO3 builds differ in operations
Both platforms run on PHP, a relational database and a web server, but they package code, versions and multi-site setups differently. The cards below cover the parts a platform owner handles every month, and what each difference means for patching, hosting and the people you need to hire or contract.
Core and contributed modules
Drupal core ships separately from contributed modules and themes, and each module carries its own release history and maintainer. A site owner must track core releases and every contributed project in use, then test them together. Ask which modules are unmaintained or lack a Drupal 11 release before you commit to a build, and budget for that review as a recurring task.
TYPO3 core with combined extensions
TYPO3 treats the core and installed extensions as one combined program under GPL v2 or later. Your extension list therefore becomes part of the licensed product you distribute and maintain. Confirm which extensions your agency maintains, how they are versioned against TYPO3 14, and who signs off on upgrades when an extension lags behind the core.
PHP and database versions
Drupal 11 requires PHP 8.3 or later, while TYPO3 14 accepts PHP 8.2.0 up to 8.5.99. Those ranges shape your server image and your patch calendar, since a PHP upgrade can force a core or extension upgrade first. Check the supported database versions for each platform, including MariaDB, MySQL, PostgreSQL and SQLite, against the database your hosting team already runs.
Composer and memory footprint
TYPO3 14 requires Composer 2.1 or higher and at least 256 MB of RAM. Drupal installs are also typically managed with Composer, so your build pipeline needs it either way. Ask your hosting team whether the build runs in CI or on the production server, because dependency updates and memory limits drive how often a platform owner must rebuild and redeploy.
Web server choice
Drupal runs on Apache, Nginx and other web servers, which gives you room to match your organization's standard stack. TYPO3 has its own server requirements in its installation guide, so confirm both against your load balancer and TLS setup before you pick images. Your team will maintain one web server configuration for each platform, and staff who know that server already will cut the cost of the first deployment.
Multi-site tree configuration
Drupal runs multiple sites from one codebase through its multisite setup, which shares core and modules but keeps separate databases and settings per site. TYPO3 organizes multiple sites as a tree of site configurations within one installation. Decide early whether each country or department needs its own release cadence, because a shared codebase means one upgrade affects every site at once.
What the GPL licenses and paid support cover for each platform
Drupal core is licensed under the GNU General Public License version 2 or later (GPL-2.0-or-later), and the Drupal.org licensing page states that contributed files that are derivative works of Drupal carry the same license. There is no paid edition of Drupal itself, so the core license costs nothing and the money goes to the work around it: upgrades, hosting, custom code and support. Extended coverage is a separate question that applies mainly to Drupal 7 sites, which lost security support on January 5, 2025.
- Core license: GPL-2.0-or-later for Drupal core, with no commercial edition to purchase.
- Contributed modules: Modules hosted on Drupal.org are GPL too, so you can install and run them without a license fee. Custom modules are your own code, and their license terms are for your counsel to confirm.
- Support windows: Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Upgrade planning follows this calendar, and no license renewal is involved.
- Extended security coverage: The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for Drupal 7 sites that cannot migrate yet. Each vendor's coverage terms differ.
Before signing with an extended support vendor, ask for its coverage end date, its scope and its migration exit terms in writing.
TYPO3 CMS is licensed under the GNU General Public License version 2 or later, and the TYPO3 project is represented by the TYPO3 Association. TYPO3's licenses page describes TYPO3 and its installed extensions as a single combined program, so extensions fall under GPL v2 or later. The paid offer is Extended Long Term Support (ELTS) for versions after their free support ends, which is a support service on the core rather than a separate edition.
- Core license: GPL v2 or later for TYPO3 CMS from version 3.x onward, with the TYPO3 Association representing the project.
- Extension sales: TYPO3 says extensions may be sold as long as the license terms are not changed, so a vendor can charge for an extension while it keeps GPL terms.
- Free support windows: The roadmap lists v12.4 (released April 25, 2023) with free support ending in 2026, v13.4 (released October 15, 2024) with free support ending in 2027, and v14.3 (estimated April 21, 2026) with free support ending in 2029.
- Paid ELTS: After free support ends, TYPO3's roadmap links to paid ELTS. Price, length and scope come from TYPO3 or its partners, so ask for them in writing.
- New projects: get.typo3.org lists TYPO3 14 LTS at version 14.3.9 and describes it as the release for new projects.
Confirm the ELTS term, the coverage per version and whether it extends to your installed extensions before you commit to a version.
Both core licenses are free to use, so the contract questions concern support, not licensing of the core. The license facts for Drupal and TYPO3 do not tell you what a vendor covers, for how long or at what price, and vendor terms change over time. Get those answers in a dated document before work starts, and compare them against the release and support dates for your chosen version.
- Coverage dates: Ask for the end date of coverage for each version you run, and tie it to the Drupal release schedule or the TYPO3 roadmap you rely on.
- Scope of security fixes: Ask whether fixes are backported to your exact version and which contributed or installed extensions fall inside the coverage.
- Extension rights: Confirm who holds rights to custom and vendor-built extensions, and that any sold extension keeps its GPL terms.
- Migration exit: Ask whether support continues while you migrate off an extended window, and what happens to coverage if the migration slips.
- Delivery model: DeployOpen agrees scope, deliverables and timelines in writing before fixed-scope work starts, and ongoing support is available as a retainer. Ask any provider to state its model in the same way.
Request these answers from each vendor in writing and compare them side by side with the dates above.
Side-by-side: LTS, databases, PHP, multilingual and identity
This table sets Drupal's release cadence, supported platforms and identity modules against TYPO3's LTS cycle and extension model. Read each row against the version you would deploy and the date its support ends. Where a cell says to confirm, the public facts do not settle the point, so check it with the vendor or in a test install before you commit.
| Capability | Drupal | TYPO3 |
|---|---|---|
| Release model | Major versions typically every three years; bugfix releases on the first Wednesday monthly, security releases on the third Wednesday | LTS releases with fixed free support windows, then paid Extended Long Term Support (ELTS) |
| Current major version and end of life | Drupal 11 is current; Drupal 10 reaches end of life December 9, 2026; Drupal 12 scheduled for the week of December 7, 2026 | TYPO3 14 LTS (14.3.9) is the release for new projects; 13.4 free support ends in 2027 |
| PHP requirement | Drupal 11 requires PHP 8.3 or later; Drupal 12 requires PHP 8.5 or later | TYPO3 14 requires PHP 8.2.0 up to 8.5.99 |
| Supported databases | MariaDB 10.6+, MySQL 8.0+, PostgreSQL 16+, SQLite 3.45+; SQL Server and MongoDB through contributed modules | TYPO3 14 supports MariaDB 10.4.3+, MySQL 8.0.17+, PostgreSQL 10.0+ and SQLite 3.8.3+ |
| Multi-site and multilingual | Core multilingual modules cover interface, content and configuration translation; confirm your multi-site design | Verify multi-site and multilingual handling in the TYPO3 14 documentation and your chosen extensions |
| SAML single sign-on | Contributed samlauth module (8.x-3.14) acts as a SAML service provider; supports Drupal 10.3+ and 11 | Verify SAML options and the extension you would use on your TYPO3 version |
| OpenID Connect | Contributed OpenID Connect module with built-in clients for generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta; creates accounts on first sign-in | Verify OpenID Connect options and the maintenance status of the extensions in your environment |
| Extension licensing | Contributed files on Drupal.org are licensed under GPL-2.0-or-later | Extensions fall under GPL v2 or later as one combined program and may be sold if license terms are unchanged |
| Support windows | Drupal 7 security support ended January 5, 2025; extended support vendors exist for sites that cannot migrate yet | Free support for 12.4 ends in 2026, 13.4 in 2027 and 14 in 2029; ELTS is paid after free support ends |
What drives the running cost of each platform
The running cost of both platforms is mostly people and hosting, not licenses, because neither Drupal nor TYPO3 charges for the core software. Drupal and contributed modules are GPL-2.0-or-later with no paid edition of Drupal itself, and TYPO3 and its extensions fall under GPL v2 or later, so your recurring spend goes to the hosting stack, the developers who maintain custom code and the partner who runs upgrades. On the hosting side, TYPO3 14 requires PHP 8.2.0 up to 8.5.99, Composer 2.1 or higher and at least 256 MB of RAM, with MariaDB, MySQL, PostgreSQL or SQLite as the database, while Drupal 11 requires PHP 8.3 or later. Ask your team which PHP and database versions they already operate, because a PHP line that must be moved forward to match a CMS line is a one-time cost that recurs in every environment you keep, including staging and build pipelines.
The largest recurring cost is usually extension and module maintenance, and it grows with the number of sites, languages, custom modules and integrations. Each contributed Drupal module and each TYPO3 extension has its own compatibility and security cadence, so every custom module, identity connector or multilingual workflow adds regression testing on every core update. The paid item to examine is TYPO3's Extended Long Term Support (ELTS), which the TYPO3 roadmap links for versions after free support ends. Confirm the exact ELTS terms, price basis and coverage dates with the TYPO3 Association before you budget for it, since the roadmap shows free support for v12.4 ending in 2026 and v13.4 ending in 2027. On the Drupal side, the equivalent exposure is the Drupal 10 end of life on December 9, 2026, and the planned Drupal 12 timing, so ask any vendor how a major upgrade is priced inside a retainer and what is excluded.
Major upgrades and LTS migrations are the one-time costs that most often surprise budgets, and they should be written into the scope as separate deliverables. Quotes should state the following: who performs the upgrade and whether it is fixed-scope or billed by time, which custom code and extensions are in scope, how many environments and languages are tested, how content and configuration are migrated, and whether training and documentation for your staff are included. Ask whether ongoing support, security patching and upgrade work are sold as a retainer, and what the retainer excludes. Ask for the vendor's written terms on any paid extended support you would rely on. DeployOpen plans, implements and supports open-source platforms inside your own infrastructure and works from written, fixed-scope agreements, so the quote will follow from the scope you define. Use that scope to compare the two platforms on like terms, not on license line items that do not exist.
Moving a site from TYPO3 to Drupal, or the reverse
The sequence turns an existing TYPO3 or Drupal site into a documented target build, with content, identities and URLs moved and checked before the source system is switched off. Each step ends with an artifact the team can review, so the cutover is a decision rather than a guess.
Inventory content, languages, sites and integrations
Record every content type, page tree, language, site or tree root, user group, scheduled job and external integration in the source system. Assign an owner to each item and note which ones are live, stale or duplicated. The output is a signed inventory that becomes the scope baseline for the migration statement of work, and a gap list the client must resolve before work starts.
Map templates and extensions to target modules
For each TYPO3 extension and Drupal module in use, decide whether the target has a maintained equivalent, a configuration-only replacement or no match that requires custom code. Check that each candidate supports the target major version and PHP version. Map every page template, content element and theme to a target content type, view mode or theme component. The finished mapping sheet, reviewed by the client's developers, shows which parts are rebuilt rather than moved.
Build the target and migrate content in staging
Stand up the target site in a staging environment inside the client's infrastructure, using the database and PHP versions the target major release requires. Migrate content, media, taxonomy, language variants and user records with scripts that log every rejected row. Rebuild themes and templates on the target. The check is a reconciliation report comparing item counts and sample pages per language and site against the inventory.
Test editorial workflows, permissions and integrations
Run editors and reviewers through representative tasks in staging, including creating translations, publishing, scheduling and restoring revisions. Confirm that role and permission rules match the mapping, and that search, forms, APIs and any single sign-on flow behave as they did in the source. Record defects in a tracker with severity and an owner. The step closes when the client signs off the test results and the open-defect list is empty for release-blocking items.
Cut over identity and redirects
Plan the switch of authentication, including how existing accounts map to the target identity provider or local users, and how sessions and API tokens are reissued. Build a complete URL map from source to target, including language prefixes and legacy paths, and load it as permanent redirects before the DNS change. Verify a sample of high-traffic and legally referenced URLs in production after cutover. The output is a redirect file and a verified list of URLs that return the expected status.
Decommission the source and retain records
Freeze writes to the source system, take a final verified backup, and archive the database, file store and configuration in a location the retention policy allows. Remove public access, revoke service credentials and retire scheduled jobs. Keep the mapping sheet, reconciliation report and test records with the archive so audits and later questions can be answered. The step is complete when the client confirms in writing that the source is read-only or removed and the archive is accessible.
Where Drupal and TYPO3 projects usually run long
Drupal projects usually run long because of decisions made before any theme is built. The content model, the taxonomy and field structure, and the multilingual design (which content is translated, which interface strings are translated, and whether configuration is translated) are hard to change once editors have content in the system. Settle the language list and the site structure early, because adding a language or splitting a multi-site setup after launch means touching every content type. On the front end, decide early whether Drupal renders pages with its own theme layer or serves a separate JavaScript application, since that choice drives who owns the theme and how the identity integration is built. For identity, a SAML or OpenID Connect integration using the contributed samlauth or openid_connect modules needs the identity provider's metadata, attribute mapping and account provisioning rules agreed with the identity team before configuration starts.
TYPO3 projects tend to stall in the same places but with different triggers. Extension choice is the main one: TYPO3 extensions are licensed under GPL v2 or later as part of one combined program, so the question is not license but whether an extension is maintained for the TYPO3 version you run, which you must confirm with each extension's maintainer. Typical delay points across both platforms are unclear ownership of contributed modules or extensions, late decisions on languages and sites, and custom code that nobody has documented. A fixed-scope written plan should name the owner for every extension or module, list every language and site with its launch date and content owner, inventory custom code with its tests, and set the acceptance criteria for the identity integration. It should also cover the test plan for a major or LTS upgrade: regression testing of content types, workflows, translations, search and login, run on a staging copy of production data. The plan should name the TYPO3 14 or Drupal 11 and 12 upgrade path your team commits to, and whether a paid Extended Long Term Support arrangement is part of the budget, which the reader should confirm with the TYPO3 roadmap before committing.
Questions buyers ask before choosing Drupal or TYPO3
What does a Drupal or TYPO3 implementation cost?
Neither project publishes a price for building a site, so the cost depends on the scope you agree in writing. The main drivers are the number of sites and languages, how many content types and workflow steps you need, how many third-party systems the site must connect to, the front-end design, and whether you need a content migration. Hosting, backups, monitoring and the internal staff who own the site are recurring costs. For TYPO3, extensions can be sold under the GPL, so some capabilities come as paid commercial extensions, and ELTS is a paid option once a version leaves free support. For Drupal, there is no paid edition of the core, so most spending goes to services and contributed modules that you select. Ask any partner for a quote that separates one-time build work from recurring support, upgrades and hosting, and that lists each third-party extension with its license terms.
How long does a migration to Drupal or TYPO3 take?
The timeline is set by the volume and state of the content, the number of templates to rebuild, and how many integrations must be re-tested. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site with the core Migrate modules or with Drush, and themes must be rebuilt because they cannot be migrated. Move a site from TYPO3 across major versions and expect extension compatibility to be the constraint, since each extension must support the target version. Before you agree a schedule, inventory content types, custom code, languages, sites, authentication flows and the number of editors who must be trained. A written scope with a sample migration of one representative content type will show far more than any generic estimate.
Can an in-house team run Drupal or TYPO3 without a partner?
Yes, if the team has the skills and time to operate the platform, but the skills differ. Drupal sites need PHP developers who can manage contributed modules, Composer-based builds, database operations and a regular update rhythm. Drupal's security releases come on the third Wednesday of the month, and bugfix releases on the first Wednesday, so someone must own that cycle. TYPO3 needs similar PHP and Composer skills plus familiarity with its extension model and LTS calendar. Run a small pilot before committing: ask who will apply each security release, who reviews extension updates and who handles restores. If that ownership is unclear, a fixed-scope engagement for setup and hardening, followed by a retainer for upgrades and testing, is one option to compare against hiring.
What does the client need to provide for a Drupal or TYPO3 project?
The work needs three kinds of access and decisions from your side. First, content owners must approve content models, editorial workflows and the sign-off steps for publishing, and they must be available during testing. Second, identity teams must confirm how staff and external users sign in. Drupal has contributed modules for SAML 2.0 service provider behavior and OpenID Connect, and your identity provider must support the chosen protocol. Third, the hosting team must provide access to the servers or cloud accounts, database hosting, backup targets, DNS, certificates and a staging environment. Check that the database engine and PHP version you plan to use match the requirements on the vendor's pages before hosting is ordered.
What happens when Drupal 10 reaches end of life?
Drupal 10 reaches end of life on December 9, 2026, and no new Drupal 10 releases follow that date, according to the Drupal core release schedule. Sites still on Drupal 10 after that date will need a planned move to a supported major version, which is Drupal 11 today and Drupal 12, scheduled for the week of December 7, 2026. Drupal 12 requires PHP 8.5 or later, while Drupal 11 requires PHP 8.3 or later, so check the PHP version on your hosting before you start. For TYPO3, the roadmap lists v12.4 with free support ending in 2026, v13.4 with free support ending in 2027, and v14.3 with free support ending in 2029. After free support ends, TYPO3 links to paid Extended Long Term Support (ELTS). Ask any vendor to price ELTS, and any upgrade, as separate line items in the quote.
How hard is it to switch from Drupal or TYPO3 later?
Switching is practical when the content model is clean and the custom code is documented, and it becomes expensive when most logic lives in templates and extensions. Both platforms are GPL-licensed, so you can take the source code and keep control of the site and its data, which helps with exit planning. The cost of leaving comes from rebuilding templates and front-end code, remapping content types, and replacing extensions or modules that have no equivalent on the other side. Keep content exportable, store custom code in your own repository, and record each third-party license. Ask any partner to show how a full content export and a restore to a clean environment would work before you commit.
Which compliance evidence should we expect from a Drupal or TYPO3 partner?
A partner can prepare configuration, access controls, logging, backup and patching records that an independent auditor may review, but the partner does not issue audit reports or certifications. Ask for a written list of the controls the partner will set up, how evidence will be stored, and who in your organization will own each record. For public sector and regulated buyers, confirm which assessment frameworks apply to your organization before the scope is signed. This lets the implementation cover the right evidence from the start instead of after go-live.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms inside the client's own infrastructure, so the Drupal or TYPO3 decision can be tested against your hosting, identity and compliance requirements before anything is built. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm which TYPO3 LTS or Drupal release line your timeline and support window require, using the vendors' published schedules.
- Map sites, languages, content types, editors and extensions or modules against the features each platform needs.
- Agree the written scope, deliverables and timelines, and list the agency and extension licensing items the client must confirm.
How we build
- Set up the chosen platform in your cloud account, data center or air-gapped network, with the PHP and database versions the vendor requires.
- Integrate single sign-on and directory identity, then configure multisite and multilingual structures for the agreed content model.
- Test upgrade paths, permissions and security settings, and record the results against the agreed acceptance criteria.
How we hand over
- Document the architecture, configuration, extension inventory, backup and restore procedures, and upgrade runbook for your team.
- Provide compliance readiness evidence for your assessors, while noting that independent auditors and certification bodies issue any audit reports.
- Walk your administrators and developers through operation so they can run upgrades and content work without DeployOpen on call.
How we support
- Run upgrades, security patches, backups and monitoring checks under a retainer, if your team prefers ongoing help.
- Schedule continuous security testing of the live site and integrations as part of an optional retainer, with scope agreed in writing.
- Revisit the platform decision when a major release, end-of-life date or paid support program changes your cost or risk.
