Why a TYPO3 upgrade is rarely the real problem

Most TYPO3 upgrade projects are not a technology problem. They are an organisational one.

At the end of April 2026, community support for TYPO3 v12 came to an end. For many organisations, this is the moment when the topic of upgrading moves back onto the agenda. Very early in those conversations, one question tends to come up: if we have to invest anyway, should we just switch systems altogether?

It is a reasonable thought. A major upgrade often feels like a good opportunity to start fresh. In practice, however, the root cause of these large and complex projects is rarely the system itself.

In most cases, situations where an upgrade suddenly becomes large and complex develop gradually over time. Content continues to be maintained and updated, but the underlying structures remain largely unchanged. Extensions stay in place and are only adapted where absolutely necessary, while real development rarely takes place.

Instead of evolving the system as a business tool, something else builds up over time: technical debt.

The result is a system that appears stable on the surface, but increasingly depends on the hope that new browsers and devices will continue to support it without issues.

In this situation, a relaunch or system switch often feels like the clean solution. Starting over and leaving behind accumulated complexity is an appealing idea. In many cases, however, this simply shifts the underlying problem.

If the way the organisation works with its website does not change, the same situation will eventually reappear. The only difference is that it will not happen in TYPO3, but in whatever system comes next.

It is also worth noting that a system switch involves more than just project costs. There are additional efforts around building up new knowledge, training teams and adapting existing processes. And in reality, the old website often continues to run in parallel for a while as a safety net during the transition.

Postponing an upgrade has consequences beyond the technical level. With every delayed upgrade, not only is further development pushed back, but often the evolution of the site as a business tool as well. Continuous development ensures that content, processes and functionality improve step by step. When that process is interrupted, the organisation’s digital value creation stalls along with it.

At the same time, the technical debt that has accumulated over time continues to grow and tends to surface precisely when change becomes necessary.

Many of these situations arise because development is treated as a project. An upgrade becomes something that has to be done every few years, while only minimal adjustments happen in between.

An alternative approach is to treat development as an ongoing process. We described this in more detail here: Hybrid project management in practice. The idea is to combine structure and flexibility in a way that avoids large, one-off projects.

TYPO3 provides a good example of this dynamic right now. With the end of community support for TYPO3 v12, many organisations are faced with the question of how to proceed.

Whether continuing with ELTS, upgrading to a current version, or starting over with a relaunch makes sense depends heavily on the specific situation. We have outlined the differences and implications here: Upgrade from TYPO3 v12 to v14

Regardless of the choice of system or version, one question remains central: how continuously is the website being developed?

Systems that are developed on a regular basis remain easier to maintain and evolve gradually. Systems that are not will eventually lead to larger, more complex projects. Continuous Upgrading is one way to make that the default, not the exception: Continuous Upgrading

In many cases, the choice of system is less important than the way it is managed and developed over time.

If the organisation itself does not change, the same challenges will reappear – even with a different system.