Versions
When Support Ends: ELTS, Risk and the Alternatives
Every TYPO3 version has a date on which regular maintenance ends. After that there are two routes: buy extended support, or move the installation to a current release. Both are defensible, for different reasons.
Three states, not two
A TYPO3 version passes through more than “current” and “outdated”. Three states matter in practice.
Under regular maintenance an LTS release receives bug fixes and security fixes at no extra cost. This is the normal case, and it lasts several years for every LTS line.
Under extended support regular maintenance has finished, while security fixes continue for a fee. The installation is no longer state of the art, but it is looked after.
Without support even that ends. From here on, newly discovered vulnerabilities get no fix at all, neither free nor paid. What this means for daily operation is covered in securing TYPO3.
Which version sits where right now is shown in the version overview. It derives the status from the published dates so that it never shows the state of the last data fetch. The relationship between LTS lines and intermediate releases has its own glossary entry: LTS.
What ELTS covers, and what it does not
Covered are security fixes for the core and for the system extensions included in the package. That is the hard core of the risk, and for many installations it covers exactly what matters.
Everything else is out of scope. Third-party extensions follow their own maintenance, and their authors usually drop support for old releases well before the core does. New PHP versions do not arrive; the installation stays tied to the PHP level it was built for. Features missing from the backend stay missing.
That last point gets underestimated regularly. Backend accessibility, handling of modern image formats, behaviour on small screens: what newer releases bring along does not arrive through extended support.
When the extension is the right choice
There are good reasons for ELTS, and they all have to do with planning.
A relaunch is already fixed. If a new site is being built anyway, an interim upgrade of the old installation would be money burned. The extension bridges the build time.
A dependency is not ready. An interface to the ERP system that is itself being rebuilt, or a specialist extension without a release for the new version.
The budget year does not line up. A jump that is planned but funded in the next financial year.
The same pattern holds in all three cases: the extension has an end date that somebody has written down.
When the jump is cheaper
As soon as the extension becomes a habit, the maths flips. The fee keeps running while the installation ages and the eventual jump grows. Extensions that still have a build for the old version disappear one by one. Anyone developing the site further during this phase invests in a state they are about to leave.
The honest question is therefore not “ELTS or upgrade” but: when is the jump planned, and what does waiting cost until then? Whether an upgrade or a relaunch is the better route is covered in update or relaunch. How a version jump runs in practice is described under TYPO3 update.
Lead time is the real lever
A version jump is rarely technically hard, but it is organisationally demanding: review extensions, go through custom adjustments, adapt templates, test, sign off. Starting once maintenance has already lapsed means working under pressure and paying for the hurry.
Starting a year ahead lets you place the work in quiet periods, split it into stages, and clear out what has accumulated over the years along the way. The effort is the same; the experience of it is entirely different.