Does a site simply keep running after vendor maintenance ends?

Yes, and that is exactly the problem. The code works unchanged, orders go through, the log stays empty. What ends is the supply of fixes. In that state an update run reports that no newer release is available - indistinguishable from the inside from "everything is current". The difference only becomes visible when a vulnerability is reported and no fix appears.

What is the difference between extended support and a security-only phase?

The security-only phase is part of the regular cycle, costs nothing and delivers security-relevant fixes only - for Joomla 5.x, for example, between **13 October 2026** (Joomla! Project) and **12 October 2027** (Joomla! Project). TYPO3's extended support is a paid programme that only starts after community maintenance ends and covers **up to three years** (TYPO3 GmbH). One is included in the cycle, the other is bought.

How much lead time does a version jump need?

Three to six months is a workable starting figure - three for a lean installation, six for a grown site with many extensions and custom templates. The span comes from the inventory, the clearance check, adjustments to custom templates, a test run on a copy and the next free maintenance window. Measure those five steps once and you replace the estimate with a figure of your own.

Does the Cyber Resilience Act apply to an open-source CMS as well?

For open-source software supplied without commercial intent, the regulation provides exceptions. For commercially distributed extensions, themes and services it generally does apply: there, a support period of **at least five years** (Official Journal of the EU) is foreseen, and its end has to be stated at the time of purchase, where **the month and the year** (Official Journal of the EU) are sufficient. In practice: ask for the end date when buying and write the answer into the register.

What happens if an extension is missing for the target version?

Then that one extension decides the jump. Four routes are open: wait for a successor release from the vendor, switch to a different product, rebuild the function yourself or drop it. All four need lead time, and all four are cheaper than a forced jump under time pressure. That is why the clearance situation belongs at the start of the planning and not in the test run.

How does the deadline get into the maintenance contract permanently?

Through three fixed items: a monthly comparison of the version inventory against the running installation, a quarterly comparison of the end dates against the vendor sources, and a lead-time notice to a named address. Plus a maintenance window reserved each quarter so the jump has a slot when it comes due. All three are procedures with a date and a log - that is the difference between an intention and a record.

When your CMS version leaves support: 2026/2027

A shop notices nothing when its major version drops out of vendor maintenance. The basket still adds up, the checkout still accepts orders, the error log stays empty. What ends on that day is not in the shop but in the vendor's calendar: no more fixes will be published for this version, not even security-relevant ones. For the three open-source systems that carry the most German business sites next to the shop platforms, the dates are fixed and public - 30 April 2026 (TYPO3 GmbH) for TYPO3 v12, 13 October 2026 (Joomla! Project) for regular bug fixing in Joomla 5.x, and 9 December 2026 (Drupal release schedule) for Drupal 10. Three end dates in a single year, and none of them raises an alert on its own.

Key takeaways

TYPO3 v12 loses regular maintenance on 30 April 2026 (TYPO3 GmbH). After that, security fixes come only through the paid ELTS programme, at the latest until 30 April 2030 (TYPO3 GmbH).
For Joomla 5.x, regular bug fixing ends on 13 October 2026 (Joomla! Project). A year of security-only fixes follows and runs out on 12 October 2027 (Joomla! Project).
Drupal 10 reaches end of life on 9 December 2026 (Drupal release schedule). The schedule states explicitly that no new releases (Drupal release schedule) of that branch will be made after this date.
TYPO3 v13 LTS is maintained regularly until 31 December 2027 (TYPO3 GmbH). Moving from v12 to that branch buys roughly fifteen months of quiet - and the next deadline is already on the calendar.
A version jump needs lead time: inventory, clearance for every extension, a test run on a copy, a maintenance window. Six months before the end date is when the decision is made, not the execution.

What leaving maintenance means in daily operation

Vendors of open-source systems publish their life cycles as calendars, not as case-by-case promises. Every major version gets two dates when it is released: the end of regular maintenance and, where one exists, the end of a follow-up phase. Until the first date, the vendor fixes errors of every kind - functional faults, misbehaviour with newer runtime releases and security holes. After that date, the channel narrows or closes completely. What never happens: a message in the shop. No notice in the interface, no log entry, no failed job. Operation stays exactly the way it was the day before.

That is the source of the confusion this article exists to clear up. An update run reporting that no newer release is available looks from the inside like "everything is current". In truth it only means that nothing is being published for this branch any more. Both states are indistinguishable as long as nobody looks up how long the deployed major version is actually being supplied. The security updates run quietly into nothing, and the first sign of it usually arrives from outside: from a vulnerability advisory, from an insurer's questionnaire or from an incident.

Three states that get mixed up in practice

Regular maintenance means the vendor fixes errors and security holes and publishes new releases of the running branch. Security-only means functional faults stay unfixed and only what is classified as a security issue is closed - at Joomla this phase is part of the official cycle, at TYPO3 it costs money. Unmaintained means nothing is published any more, not even for a critical hole. Anyone who does not keep these three states apart plans the version jump a year too late.

The calendar: which date applies to which version

TYPO3 keeps its dates machine-readable in a public interface. For v12, still running on many grown sites, it lists 30 April 2026 (TYPO3 GmbH) as the end of community maintenance and 30 April 2030 (TYPO3 GmbH) as the end of extended support. The successor branch v13 LTS appeared in October 2024 and is maintained regularly until 31 December 2027 (TYPO3 GmbH), with extended support ending on 31 December 2030 (TYPO3 GmbH). The current branch v14 LTS was released on 21 April 2026 (TYPO3 GmbH), is maintained until 30 June 2029 (TYPO3 GmbH) and is covered by extended support until 30 June 2032 (TYPO3 GmbH). Given the choice, do not jump to v13 but straight to v14: the effort is the same, the window gained is a year and a half longer.

Drupal works differently. The project's release schedule ties the end of a major version to the arrival of the one after next. Drupal 12 is released in the week of 7 December 2026 (Drupal release schedule), and in the same week the life of Drupal 10 ends - on 9 December 2026 (Drupal release schedule). The decisive sentence is that the schedule states explicitly that no new releases (Drupal release schedule) of Drupal 10 will be made after that date: unlike TYPO3, there is no paid extension here that pushes the deadline back. The schedule also names 10.6.0 (Drupal release schedule) as the last minor release of the branch. What such an ending looks like in hindsight is on record with Drupal 7: support ended on 5 January 2025 (Drupal release schedule), years after the date was known.

System and major version	Regular maintenance until	Fixes after that until
TYPO3 v12	30 April 2026 (TYPO3 GmbH)	ELTS until 30 April 2030 (TYPO3 GmbH)
TYPO3 v13 LTS	31 December 2027 (TYPO3 GmbH)	ELTS until 31 December 2030 (TYPO3 GmbH)
TYPO3 v14 LTS	30 June 2029 (TYPO3 GmbH)	ELTS until 30 June 2032 (TYPO3 GmbH)
Drupal 10	9 December 2026 (Drupal release schedule)	then no new releases (Drupal release schedule)
Joomla 5.x	13 October 2026 (Joomla! Project)	security fixes until 12 October 2027 (Joomla! Project)
Joomla 6.x	17 October 2028 (Joomla! Project)	security fixes until 16 October 2029 (Joomla! Project)

Joomla separates both phases cleanly and names them as such. For the 5.x branch, regular bug fixing ends on 13 October 2026 (Joomla! Project) and the phase with security-relevant fixes only on 12 October 2027 (Joomla! Project). The 6.x branch, available since 14 October 2025 (Joomla! Project), follows the same pattern: regular bug fixing until 17 October 2028 (Joomla! Project), security fixes until 16 October 2029 (Joomla! Project). A fourth system belongs on the same list even though its schedule is not published in the same machine-readable form: anyone running Contao keeps its branches in the same register, and maintenance for Contao follows the same logic of end date, lead time and maintenance window.

Between no support and extended maintenance

TYPO3 is the only one of the three systems with its own paid programme for the time after community maintenance. It is called Extended Long Term Support and delivers security and compatibility fixes for a branch that is officially no longer looked after. The vendor describes the scope as up to three years (TYPO3 GmbH) of continued support for any organisation, and up to four years for official partners. It is booked in blocks of one year (TYPO3 GmbH) each, with two or three blocks possible at once. This is not a substitute for a version jump but a paid extension of the decision window - useful when the jump is prepared in substance but the date does not fit the season.

Joomla's security-only phase is something else, even though it sounds similar. It is part of the regular cycle, costs nothing and starts automatically when bug fixing ends. What is missing in that phase are fixes for functional faults and adjustments to new runtime releases. In a shop environment that quickly becomes the problem: when a new PHP release arrives, the old branch is no longer adapted, and suddenly the version jump depends on the runtime roadmap instead of your own. How to plan that second deadline is covered in the article on handling PHP end-of-life dates.

The end date is not the appointment - the lead time is

The version jump is due on the end date, but it has to be decided long before. Between decision and execution sit the inventory, the clearance check for every extension against the target release, adjustments to custom templates, a full test run on a copy and a maintenance window that does not fall into peak season. Six months is a workable starting figure for a grown site, three months for a lean one. Measure that span once and you know your own lead time better than any general recommendation.

For 2026 this arithmetic produces an uncomfortable result. Anyone still on TYPO3 v12 in September 2026 has already passed the end date and is either inside extended support or running unmaintained. Anyone using Joomla 5.x has a good two weeks left until bug fixing ends and twelve months of security fixes after that - that is the lead time, nothing more. And anyone running Drupal 10 has around two and a half months until the hard stop. Three systems, three very different levels of urgency, one common denominator: the decision should have been taken in spring.

Why an unmaintained system costs more than the jump

On paper, the cost calculation of a postponed version jump looks good: no project time, no test runs, no maintenance window. It changes as soon as you add the other side. Exploiting known vulnerabilities is now the most common way into corporate networks, accounting for 31 % (Verizon) of analysed incidents with an identified initial access vector - ahead of stolen credentials. And remediation takes time: closing a vulnerability classified as critical takes a median of 43 days (Verizon). Those 43 days assume that a fix exists at all. For a version without vendor maintenance, the counter runs to infinity.

The other side is considerably faster than the operator. Between a vulnerability being added to the relevant catalogue and its mass exploitation, the median is five days (Verizon). At the same time, according to figures from the German Federal Office for Information Security, an average of 119 (BSI) new vulnerabilities become known every day. An unmaintained major version no longer takes part in that race - it stands still while the catalogue grows. What helps is not another protective wall but a calendar that forces the jump before the state sets in. What the running comparison between advisory and deployed release looks like is described in the article on handling vulnerability advisories.

System and major version

For each site, the system, the running major version and the exact minor version. Without those three entries no end date can be assigned, only guessed.

End of maintenance

The date from the vendor source, not from memory. TYPO3 publishes it in a public interface, Drupal and Joomla in their published schedules.

Lead-time marker

A second marker three to six months before the end date. It marks when the decision is due and belongs in the same calendar as the maintenance windows.

Extension clearance

Which target release is every deployed extension cleared for? The jump is decided at the weakest link, not at the core of the system.

Runtime environment

The scripting language release has its own deadline and runs independently of the system. Both belong side by side, otherwise they collide in the same quarter.

Ownership and record

One named person per deadline and one log entry with date and decision. Without a record, all that is left later is reconstruction from memory.

The runtime environment deserves a sentence of its own because its deadline regularly overtakes the system's. Every branch of the scripting language is fully supported for two years (The PHP Group) and then supplied with critical security fixes only for two additional years (The PHP Group). Four years in total, and that rhythm runs independently of which CMS sits on top. Put both calendars side by side and you see immediately which quarters carry a double load - and you move one of the two projects before they land in the same maintenance window.

What the law says about the support period

Since the Cyber Resilience Act, the support period is no longer just a matter of vendor culture but a legal quantity. For products with digital elements, the regulation prescribes a period of at least five years (Official Journal of the EU) and requires that its end be stated to the buyer at the time of purchase, where the month and the year (Official Journal of the EU) are sufficient. Exceptions apply to open-source systems supplied without commercial intent; for the extensions and themes an operator buys on top, they generally do not. The practical consequence is the same: the end date becomes a figure you can demand and document instead of estimating it.

Without prejudice to the second subparagraph, the support period shall be at least five years.

Regulation (EU) 2024/2847, Article 13(8)

For operations this means: when you buy an extension package or a theme today, ask for the end of the support period and write the answer into the same register that holds the system deadlines. How closely the two are connected shows up during the jump: an extension without clearance for the target release pins the entire site to the old branch. The article on licence deadlines for extensions describes that second layer of deadlines in detail; the register below brings both together.

support-deadlines-report.sh

#!/usr/bin/env bash
# Read the version register: report expired maintenance and everything inside the lead-time window
set -euo pipefail

REGISTER="/srv/maintenance/versions.csv"
# Columns: site;system;major;maintained_until;lead_days;owner
TODAY=$(date +%s)

tail -n +2 "$REGISTER" | while IFS=';' read -r site system major until_date lead owner; do
  end=$(date -d "$until_date" +%s)
  left=$(( (end - TODAY) / 86400 ))

  if   [ "$left" -lt 0 ];      then state="UNMAINTAINED"
  elif [ "$left" -le "$lead" ]; then state="LEAD TIME"
  else                              state="ok"
  fi

  [ "$state" = "ok" ] && continue

  printf '%-13s %-24s %-9s %-7s %5d days  until %s  %s\n' \
    "$state" "$site" "$system" "$major" "$left" "$until_date" "$owner"
done

How much lead time a version jump really needs

The effort of a jump depends less on the core than on everything that has grown around it. A site with two dozen extensions, custom templates and a link into the merchandise system needs different planning from a lean installation. What behaves the same in both cases is the order: first the inventory, then the clearance situation, then the test run, then the date. Reverse that order and start with the date, and you regularly end up with a jump that fails the evening before go-live because of a single extension that was never ported.

Inventory read out of the running installation for each site: system, major version, minor version, runtime release.
End of maintenance noted per major version from the vendor source, with the date of the check and the reference.
Lead-time marker set - three to six months before the end date, depending on the size of the site.
Clearance checked per extension: is there a release for the target version, and is it still maintained?
Custom templates and adaptations reviewed for hard dependencies on the old branch.
Jump run on a copy first; how to set up such a test environment properly is part of the preparation.
Regression run across the load-bearing paths - catalogue, basket, checkout, invoicing - as described in the article on testing after updates.
Rollback point secured and restored once; an unverified backup state is not a rollback point.
Maintenance window placed outside peak season and agreed with everyone involved.
Decision, date and owners logged so that the record is available later without reconstruction.

Two points on that list get skipped most often. The first is the clearance situation of the extensions: it decides feasibility and is nevertheless often checked only during the test run. The second is the rollback point. A jump across a major version changes the database schema; without a tested way back, aborting stops being an option the moment the migration starts. Both cost an hour beforehand and a weekend afterwards.

Four routes when the date moves closer

Step 1

Jump

The standard case. Move to the next maintained major version - and to the newest one, not the nearest. For TYPO3 that currently means v14 LTS instead of v13 LTS: same effort, a window that is a year and a half longer. The jump belongs in a planned maintenance window with a prepared way back, not in a night shift after a vulnerability advisory.

Which route is right comes down to two questions: how long does the deployed branch still carry, and how far along is the clearance situation of the extensions? With both answers in hand, the decision is made in one meeting. With one missing, the decision turns into a project. If the deadline has already passed and an advisory is on the table, the short route runs via emergency support - but that replaces no planning, it only buys time.

What of this belongs in the maintenance contract

A version register that is filled during onboarding and never touched again is worthless after twelve months. Minor versions move, extensions are added, the hosting provider raises the runtime release. That is why the comparison belongs in the running rhythm: once a month the inventory against the installation, once a quarter the end dates against the vendor sources. Both are short procedures when they happen regularly, and a project when they sit untouched for two years.

In the maintenance contract these items can be named without turning them into a deadline promise: the monthly comparison, the lead-time notice to a named address, the maintenance window reserved each quarter and the documented state per site. Anyone running several systems keeps one list instead of four - the deadlines for TYPO3, Drupal and Joomla differ in the date, not in the procedure. A look at the service overview shows which of these items run on a fixed rhythm and which are commissioned case by case.

Silent state

The site keeps running, the fix no longer arrives. Neither from inside nor from outside is that visible until the hole is exploited.

Chain effect

One extension without clearance for the target version pins the entire site to the old branch - and with it every other component.

Two calendars

System and runtime environment have separate deadlines. If they land in the same quarter, two plannable projects become one unplannable one.

Schema change

A jump across a major version changes the database schema. Without a verified rollback point, aborting stops being an option once the migration starts.

Burden of proof

Insurers and audits ask about the state at the time of the incident. Without a log from the register, all that is left is memory.

Season

The end date does not ask about the Christmas season. If it falls into peak trading, the jump has to happen before it - or the extension has to be decided before it.

The record is more than a formality. After an incident, the first question is whether the system was still being supplied by the vendor at the time. A register with date, release and decision answers that in a minute; without it, the answer becomes a reconstruction from invoices and memories that nobody enjoys. The same question shows up in tenders, in audits and in every conversation about a cyber policy. It costs nothing as long as the answer is kept current.

The next step

The entry point is a single line per site: system, major version, end of maintenance, lead-time marker, responsible person. For most estates that list is finished in a morning, and it answers immediately which sites need a jump within the next twelve months. After that comes the order: first the sites whose end date has already passed, then those with an end date in the current year, then the rest. Anyone who wants to know how such a handover works in an existing estate will find the steps in the pricing overview and in a short conversation faster than in any written breakdown.

Sources and studies

This article draws on data from: TYPO3 GmbH, get.typo3.org (version data for the major releases) and typo3.com (Extended Long Term Support); Drupal release schedule on drupal.org (core release cycles); Joomla! Project, developer roadmap on developer.joomla.org; Verizon, 2026 Data Breach Investigations Report - Retail Snapshot and 2025 Data Breach Investigations Report; BSI, The State of IT Security in Germany 2025; Official Journal of the EU, Regulation (EU) 2024/2847 (Cyber Resilience Act); The PHP Group, PHP: Supported Versions. All dates were checked against the named sources on 16 September 2026.