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.

Common questions

What exactly is ELTS?

ELTS stands for Extended Long Term Support: a paid extension of security maintenance for a version whose regular maintenance has run out. It is offered by TYPO3 GmbH for a limited period after the regular end date.

The scope is deliberately narrow: security fixes for the core and for selected system extensions. New features, support for newer PHP versions or adjustments to new browsers are not part of it.

Will our site simply keep running without support?

Yes, and that is the trap. An installation without security maintenance behaves exactly as it did the day before; nothing visible changes. What changes is the situation behind it: every newly published vulnerability stays open, and its publication tells attackers what to look for.

There is also pressure from below. Hosts retire PHP versions, and an old TYPO3 release will not run on a new one. At some point the host decides the timing of your upgrade, rather than you.

How long should we stay on ELTS?

As a bridge with an end date, never as a permanent state. It makes sense when a relaunch is already scheduled, when a budget year has to be bridged, or when an interface is still tied to the old release.

It stops making sense when the extension gets renewed year after year. The jump does not get smaller that way, it gets bigger, and the running fees eventually add up against the upgrade you need anyway.

How do we know when our version runs out?

The dates are published openly at get.typo3.org and in our version overview, which recalculates the status on every build instead of freezing it.

One practical note: the interesting part is not only the date but the lead time. A version jump with many custom adjustments needs planning, and that sensibly starts a good year before regular maintenance ends.

Terms used on this page

Unsure how long your version will last?

Tell us the version number. We will say how long it is maintained and which route from there is the more economical one.