TYPO3 v12 LTS: New Possibilities
What the v12 sprint cycle is already showing — and what we're preparing for the LTS release in October 2023.
With version 12, TYPO3 started a new major cycle in October 2022 that has by now, through the sprint releases v12.1 to v12.3, drawn a very clear line. In October 2023, this becomes the next long-term-support release, pinning the platform for the following three years. In this post I summarise what changes structurally, what we are already preparing for our clients, and where the migration from v11 LTS typically gets sticky.
PHP 8.1 as the new floor
The most important hurdle for the migration is the raised PHP minimum version. v11 still ran from PHP 7.4; v12 requires PHP 8.1 and is prepared for PHP 8.2 from day one. For many existing installations, this means not only a TYPO3 migration but also a PHP jump across two major versions. Third-party extensions we run in our setups have to be verified for PHP-8 compatibility — and a share of them is no longer usable in their current form.
In practice this is rarely a drama, but has to be addressed consistently. We use Rector with the TYPO3-specific rule sets in combination with PHPStan. This pipeline has run on every client platform since the first v12 sprint releases, so we do not enter a marathon at the October LTS but keep the lock-step continuously.
Content Blocks: an interesting PoC in the extension ecosystem
One of the more exciting developments around v12 sits not in the Core but in the extension ecosystem as a proof of concept: Content Blocks. The concept is lean — a YAML definition, a Twig or Fluid template, an optional asset file in one coherent directory. What used to be TCA configuration, Fluid partials, TypoScript mapping and a custom PHP provider would then be bundled in one place.
In my assessment, this is visibly early in April 2023: no stable 1.0 yet, a modest sample collection, an API that has still moved between the most recent sprint releases. We evaluate Content Blocks alongside our existing custom-content-element pipeline on an internal sandbox site, not in client projects. If the concept stabilises over the next v12 sprint releases, it becomes a clear candidate for our standard pipeline. Until then it remains an interesting observation.
Modernised backend
The v12 backend looks at first glance like a UI refresh with better readability and a reworked sidebar. On second look there is more: a new module API lets extensions wire backend modules through PSR-15 middlewares instead of the old ext_tables mechanics. That makes backend extensions more testable and cleaner in routing.
For our clients this means in practice: custom modules we build for internal workflows — such as an editor dashboard for approval-bound content — get a more modern foundation. Migrating existing custom modules is manageable, but not a drop-in.
Composer-first in practice
v12 consistently continues the Composer-first path that TYPO3 began with v11. Classical installations that still ran through the TYPO3 Extension Repository without a composer.json are hard to maintain from v12 onwards. For us this is the standard anyway — all projects have been exclusively Composer-based for years, with a frozen composer.lock and an explicit update path via Renovate.
What changes with v12: TYPO3 itself can now be composed at a finer granularity from individual packages. Anyone needing only backend editorial can leave out frontend packages; anyone running a headless architecture can drop classical rendering. We use this granularity to reduce attack surface and accelerate update cycles.
Migration from v11 LTS to v12 LTS — our approach
The migration from v11 LTS to v12 LTS is not a patch update but a major migration with a PHP jump. We approach it in four steps:
- PHP preparation. The application is first lifted to PHP 8.1 (still under TYPO3 v11). This decouples two large risk classes from each other.
- Extension audit. Every third-party extension is checked: does a v12-compatible version exist, or does an in-house adjustment have to be made? Our own extensions are run through Rector with the TYPO3 12 rule sets.
- v12 sprint upgrade. We bring v12.3 (or v12.4 at migration time) onto a staging environment. Only when the build there is green and a full regression test passes cleanly does production follow.
- LTS transition. With the October LTS, the staging environment is lifted to v12 LTS and rolled out into production after a brief stabilisation period.
The effort for an average mid-market platform sits at three to five person-days, depending on extension depth. A setup with own, well-maintained extensions is cheaper than a setup that has grown over the years with two dozen third-party extensions.
What we are preparing for October 2023
Since v12.0, two tracks have run in parallel in our setups: the productive v11 LTS platform for the client, and a v12 sprint platform in staging mode that we pull forward with every sprint release. With that, by the October LTS we will have already touched every single incompatibility once — and do not have to hope on LTS day that everything fits.
We recommend clients still on v11 LTS today to start planning their migration in the second half of 2023. v11 LTS is supported until October 2024 with standard support and extended for a fee thereafter, but every additional v11 season only postpones the problem. Anyone arriving at v12 benefits directly from the modernised backend module API and the granular Composer structure — and is close to experiments like Content Blocks once they stabilise.
Conclusion
v12 LTS is not a revolutionary break from v11 but a consistent modernisation. Anyone already living the Composer-first path and PHP 8.1+ has the hardest part behind them. Anyone with it still ahead should tackle it this year — not because v11 LTS is breaking acutely, but because the whole ecosystem around it is settling on v12.