TYPO3 14 LTS: planning the upgrade

Anyone running a TYPO3 installation on major version 12 has had an open decision since spring 2026 that cannot be postponed any further: free maintenance for this branch ran out on 30 April 2026 (get.typo3.org), and since 1 May 2026 the community has delivered neither maintenance nor security updates for it (news.typo3.com). On the other side, TYPO3 14 LTS has been available since 21 April 2026 - a release that sits two major version jumps away from v12 (get.typo3.org). This article lines up the maintenance windows, checks the effort at the points that can actually be recalculated - changelogs, extensions, PHP corridor - and shows how that turns into a time slot that fits your operations rather than the development calendar. If you would rather have the planning accompanied, the framework is in our TYPO3 support.

What ended on 30 April 2026

Free community maintenance for TYPO3 12 LTS ran from 25 April 2023 to 30 April 2026 (get.typo3.org). Those three-odd years follow a fixed pattern: an LTS release is regularly maintained for 1.5 years and then gets another 1.5 years of priority bug fixing, security updates included (news.typo3.com). Since 1 May 2026 the community has delivered neither maintenance nor security updates for v12 (news.typo3.com). For day-to-day operations that means nothing at first: the instance keeps working as it did the day before, editors notice nothing, order paths run through. What is missing is the supply line. A core vulnerability that becomes known after this date will no longer be closed on this branch without paid extended support. Between "it runs" and "it is supplied" sits the gap a plan has to close.

How many operators are in this position can only be stated approximately. For 1 September 2026 the measurement service W3Techs reports that 24.2 per cent of websites with detected TYPO3 were last recorded on major version 12, 25.4 per cent on branch 13 and 1.5 per cent on branch 14 (W3Techs). All three shares refer to websites whose content management system the service detects at all, not to every website on the net. Two limitations come on top: by its own account the service sources the version assignment from a third party, and a recorded website is revisited only about once a month. A version change therefore shows up with a delay, and the 1.5 per cent on branch 14 say nothing about the pace of adoption. What does hold is the order of magnitude: just under a quarter of the recorded installed base was last seen on a branch without free security supply.

Within that quarter the picture is more uniform than one would expect: 99.8 per cent of websites with detected TYPO3 12 run on the LTS release 12.4 (W3Techs, as of 1 September 2026). If you are on v12 you are therefore very likely on the same level as everyone else - with the same extensions on the market and the same open questions. For planning that is good news, because experience transfers. It also means that a vulnerability found in the core of 12.4 affects a very large part of the installed base at once. If you first want to weigh TYPO3 against other systems, the comparison is in our CMS comparison for companies; this article is about the path within TYPO3.

The maintenance windows side by side

TYPO3 plans a new LTS release every 18 months (docs.typo3.org). That rhythm is the actual planning unit: it determines how often an operation has to schedule an upgrade window, and it maps onto the term of a maintenance contract. The overview below lines up the three branches that matter for a decision today. It carries only dates that the publisher or the association states itself; no second-hand date appears in it.

The actual planning question follows from the table. TYPO3 v13 LTS receives free security updates until the end of December 2027 (news.typo3.com); the machine-readable dataset of the association names the same date (get.typo3.org). According to the publisher, TYPO3 v14 LTS receives bug fixes until 31 December 2027 and security patches until 30 June 2029 (news.typo3.com). Planning from v12 today therefore means two target marks: an intermediate step to v13 buys room until the end of 2027, a jump straight to v14 carries through to mid-2029. The second mark lies a good eighteen months further out - and that distance is almost exactly one full LTS rhythm.

• The intermediate step has an expiry date. Going via v13 means the next jump has to be scheduled before 31 December 2027 (get.typo3.org) - that is not a rest period, it is a deferral.
• The direct jump buys the longer term. Security patches for v14 run until 30 June 2029 (news.typo3.com), which spans two planning years.
• The 18-month cadence stays. The next LTS release is planned to follow v14 (docs.typo3.org); an operation that has caught up once still needs the window again.
• Paid extended support only defers the pressure. It keeps the core of 12.4 supplied but changes nothing about extensions, PHP branch and editing interface.

One jump, or v13 as an intermediate step

The question whether to go from v12 straight to v14 or to insert v13 is often treated as a matter of taste. It is not. The difference lies in where the work lands - in one large block or in two smaller ones with a productive intermediate state in between - and in which warnings you get to see along the way at all. Both can be pinned to verifiable numbers: the entries in the changelogs and the version declarations of the extensions. Both figures are public, both have clear limits, and both are regularly over-interpreted.

What the breaking entries say and what they do not

The official changelog lists 93 entries of type breaking for TYPO3 v14, 101 for v13 and 126 for v12 (docs.typo3.org). Putting those three numbers side by side is fair; reading them as a falling trend is not: v12 and v13 each cover five releases, v14 four so far, and the development phase of v14 was shorter. The numbers therefore describe periods of different length. What holds is the sum of the path: going from v12 to v14 means facing the breaking entries of two major versions. Taking the intermediate step means facing the same entries, only spread across two dates. The work does not disappear, it is portioned differently.

This strategy gives developers sufficient time to adjust their TYPO3 extensions, assuming many agencies upgrade from one LTS release to the next (usually 1.5 years).

TYPO3 Documentation Team, Pre-upgrade tasks for major TYPO3 Core updates

That sentence describes the most important side effect of the decision. PHP classes, methods, constants, functions or parameters that are to be removed are marked as deprecated first and only removed in the next major release (docs.typo3.org). The lead-time rule assumes that upgrades go from one LTS release to the next, usually 1.5 years apart (docs.typo3.org). Skipping v13 means the warnings of that intermediate stage never appear in your own operation: whatever was deprecated in v13 and removed in v14 shows up nowhere on the v12 instance. You find it either in the static analysis run before the upgrade or in the error log afterwards. That is no argument against the direct jump, but it shifts effort from operations into preparation.

What the extension counts are good for

The second verifiable figure is the extensions. In the TYPO3 Extension Repository the search can be filtered by supported major version; the counters next to it state how many extensions carry a declaration for that release. What matters is what those counters are not: they rest on version declarations that extension authors enter themselves, not on measured compatibility. And they do not stand still - they carry no date on the page and move over the course of a day. For planning they are usable as a rounded order of magnitude with a retrieval date, not as a cut-off value. What carries more meaning than the total counter is the intersection: how many of the extensions declared for the starting release in question also carry a declaration for 14 LTS.

Coverage is denser coming from v13 than from v12: add the filter for 14 LTS to the filter for your starting release in the extension repository, and the counter for 13 LTS sits clearly above the one for 12 LTS. No fixed number is given here on purpose - the counters carry no date and move over the course of a day; anyone who needs them for planning retrieves them on the day of planning. The gap is to be expected, because many authors maintain their packages onward from whichever release is current. For planning it means the intermediate step via v13 is the better-supplied route in the extension landscape too. Against that stands the fact that the second jump has to be made up by the end of 2027 anyway.

The counter, however, says nothing about your own installation. What counts is not how many extensions in the repository carry a declaration, but which twelve or twenty extensions are active in your instance and whether exactly those carry one. On top of that comes the second distribution channel: the Composer directory lists over 4,400 packages of type typo3-cms-extension (Packagist, retrieved 14 Sep 2026). Installations managed through Composer draw their extensions from there, in part alongside the repository, in part exclusively. An inventory that looks at only one of the two sources regularly misses a substantial share of what is installed.

Platform first: the PHP corridor

For the move, the publisher recommends updating the platform first and the TYPO3 instance afterwards (news.typo3.com). That is more than a sequencing tip; it is the reason an upgrade can be split across two dates at all. TYPO3 12 requires PHP 8.1.0 to 8.4.99, TYPO3 14 requires PHP 8.2.0 to 8.5.99 (get.typo3.org). Both releases are therefore jointly runnable only in the closed range from PHP 8.2.0 to 8.4.99. That corridor is the actual working surface: if you pull the platform forward, you raise PHP within this range, verify the running v12 instance on it and make the TYPO3 jump afterwards on a second date.

The upper edge belongs in every plan: PHP 8.5 is not covered by TYPO3 12 (get.typo3.org). Raise the platform too far and you end up with a v12 instance on an unsupported PHP branch, having blocked your own staged route. At the lower edge sits the counter-question: TYPO3 v14 LTS requires at least PHP 8.2 and additionally supports PHP 8.3, 8.4 and 8.5 (news.typo3.com). According to the PHP Group, however, the PHP 8.2 branch only receives security updates until 31 December 2026 (php.net). The sensible choice is therefore the middle of the corridor, 8.3 or 8.4 - both are covered by v12 and v14, and the branch carries beyond the upgrade date.

The sequence has a practical advantage. A platform change can be rehearsed on a clone and rolled out in a short maintenance window, because nothing changes in content or the editing interface. The TYPO3 jump, by contrast, touches the backend, the extensions and usually the templates as well. Putting both on one date means a fault at three in the morning can no longer be attributed cleanly. For the infrastructure questions that come up along the way - runtimes, memory, caches - our cloud and hosting support is the right place.

Count the extensions before fixing the date

Before a date goes in the calendar, an inventory belongs on the table. It can be done in half a day and determines the order of magnitude of the whole project. The public counters only help with classification; what counts is the list of active extensions in your own instance, checked against the declarations for 14 LTS. The following sequence has proven itself and can be run regardless of whether the direct jump or the intermediate step wins in the end.

1. List the active extensions, separated by distribution channel - repository, Composer, custom development. Inactive packages belong on a list of their own; they are not migrated, they are removed.
2. For every public extension, check whether a declaration for 14 LTS exists. The filter in the TYPO3 Extension Repository shows how many packages declared for your starting release also carry one for 14 LTS - whether yours are among them is decided case by case.
3. Check custom development against the breaking entries in the changelogs of v13 and v14 (docs.typo3.org). The static analysis run finds the larger part, the test instance finds the rest.
4. Run all upgrade wizards of the current major version - that is a precondition for the jump, not rework (docs.typo3.org).
5. Sort the effort per extension roughly into three buckets: replaceable, adaptable, to be rebuilt. Only that sorting turns a list into an estimate.

The fourth point is the one most often overlooked. Before jumping to the next major version, all upgrade wizards of the current major version must have been run (docs.typo3.org). In an instance that has been in operation for years and moved through its jumps briskly, open items regularly remain there. Individually they cost little time, but they block the next step - and they typically surface exactly when the maintenance window is already running.

#!/usr/bin/env bash
# Inventory before the TYPO3 upgrade - results go to report/
set -euo pipefail
mkdir -p report

# Open upgrade wizards of the current major version
./vendor/bin/typo3 upgrade:list --all > report/wizards.txt

# Installed packages with version, the basis for the comparison
composer show --format=json \
  | jq -r '.installed[] | .name + " " + .version' \
  > report/packages.txt

# Custom development: everything that lives in the project itself
find packages -maxdepth 2 -name composer.json -printf '%h\n' \
  > report/custom.txt

# Shared PHP range of v12 and v14: 8.2.0 to 8.4.99
php -v | head -n 1 > report/platform.txt

echo "Inventory is in report/ - the assessment stays manual work."

The inventory turns into a number as soon as every item is assigned to one of the three buckets. Replaceable means the core or a maintained extension now covers the function. Adaptable means a release exists and only configuration and templates need to follow. To be rebuilt means no release exists and the function is needed anyway. Experience shows the size of the third bucket decides whether an upgrade stays a maintenance task or becomes a project with its own schedule. If the decision tips towards rebuilding larger parts, it is worth looking at the system question as a whole - our article on CMS migration from a legacy system describes that transition.

Extended support extends, but replaces no plan

For operations that cannot schedule the date in time, paid extended support exists. The ELTS programme for TYPO3 12.4 runs until 30 April 2029, for official partners until 30 April 2030 (typo3.com). One ELTS coverage period runs for a year and can be booked two or three periods at a time (typo3.com). The provider states 3,200 euros per licence and year before discounts for it, and that across the entire duration of up to four years (news.typo3.com). That is a list price before member discounts, priced as of 14 September 2026, and not a commitment - anyone budgeting with it should obtain a current quote.

Working that through gives a simple picture: the extension falls due annually, and at the end of the booked years the same task remains - only with more distance to the current state and in an environment that has moved on. The fourth year of the programme, the period from 1 May 2029 to 30 April 2030, is additionally open only to official TYPO3 partners (typo3.com). Extended support is therefore a workable way to bridge a window that opens later for operational reasons - an alternative to the upgrade it is not.

Placing the time slot

An upgrade date does not belong in the development calendar but in the operations calendar. That sounds obvious and is nevertheless regularly handled the other way round. What helps is counting backwards from the outer mark: going via v13 means the second jump has to stand before 31 December 2027 (get.typo3.org). Going straight to v14 buys quiet from the next mandatory exercise until 30 June 2029 (news.typo3.com), but the 18-month release cadence should stay in view (docs.typo3.org). Between those marks sit the season, the budget year, staffing and the fact that a test instance needs time in which someone actually uses it.

• Fix the outer mark: 31 Dec 2027 for the intermediate step via v13, 30 Jun 2029 for the direct jump to v14
• Pull the platform date forward and raise PHP within 8.2.0 to 8.4.99 while v12 is still running
• Work through all upgrade wizards of the current major version before the window opens
• Set up a test instance with real content and schedule an editorial sign-off, not only a technical one
• Sort the extension list into replaceable, adaptable and to be rebuilt, and tackle the third bucket first
• Write down the fallback path: state, database dump, point of decision

The editorial sign-off is where schedules most often tear. A major version jump changes the backend, and two jumps at once change it noticeably. Signing off the test instance on technical grounds alone pushes the editors' feedback past the production date, to where it is most expensive. Two weeks in which the editorial team actually works in the test system are, in our experience, better invested than any additional round of automated checks. How to plan such a sequence as a whole is described in our article on relaunch planning.

What gets tidied up along with the upgrade

A major version jump is often the only date in the year on which everything gets touched anyway. That makes it the cheapest moment for work that otherwise never gets its own budget. The URL structure belongs here: if page paths or file names change with the jump, a redirect plan belongs on the same date. The same goes for accessibility requirements, whose implementation sits in templates and forms - the framework for that is set by our accessibility support.

Two topics from this week connect directly here. If the upgrade touches the platform anyway, it makes sense to review the hosting contract at the same time: which switching rights apply from 2027 is covered in our article on cloud provider switching from 2027. And if the templates are being reworked anyway, the accessibility statement and the feedback channel can be created along with them - what both have to look like is covered in our article on the accessibility statement and feedback mechanism. Both are pieces of work that an open maintenance window nearly carries along.

Where the numbers come from and what they do not say

The dates in this article come from two sources: the announcements of TYPO3 GmbH and the machine-readable dataset of the TYPO3 Association on get.typo3.org. The figure for extensions in the Composer directory comes from the package list on Packagist, retrieved on 14 September 2026 and carried here rounded, because it moves over the course of a day; the facet counters of the TYPO3 Extension Repository are given here without a fixed value on purpose, because they carry no date and move over the course of a day. The share figures come from W3Techs and refer to websites with a detected content management system; by the provider's own account the sample covers considerably more than 20 million websites (W3Techs).

What the numbers do not say matters just as much. Among websites with the .de suffix, TYPO3 reaches 6.7 per cent of the sites with a detected content management system; worldwide it is 0.5 per cent (W3Techs, retrieved 27 September 2026). It follows that penetration in the German segment is many times higher - not how the installations are distributed across countries. Those are quotas per segment, not an installed base. Nor can a pace be read from the version shares: they say what was last recorded, not how quickly anyone is switching.

The next step

The decision between the direct jump and the intermediate step is not made at a desk but on the extension list. If it is mostly standard packages declared for 14 LTS, the direct jump is the shorter route and carries through to mid-2029 (news.typo3.com). If it holds a lot of custom development, the intermediate step via v13 is the calmer stretch - on condition that the second jump is set before the end of 2027 (get.typo3.org). In both cases the first step is the same: the inventory. We take it on as a finished deliverable, with a defensible list, an effort estimate per item and a scheduling proposal - the entry point is on our page for TYPO3 support, the comparison between systems on our page for content management systems.