When Third-Party Extensions Change: Why TYPO3 Upgrades Rarely Have a Perfect Solution

Anyone who has ever modernised a TYPO3 installation that has been in productive use for many years knows the situation.

The migration itself is going well. The codebase is being modernised, deprecations are gradually disappearing, database migrations are prepared and the platform is approaching the target version. At some point, however, you come across an extension that technically still exists but has changed significantly in terms of functionality.

The new version supports TYPO3 14 without any problems, it is actively maintained, and it receives security updates. And yet a feature the client has used as a matter of course for years is suddenly missing.

At this point, a technical discussion no longer begins. A product decision begins.

Software keeps evolving – even when your own project stands still

A TYPO3 installation is often used continuously over many years. During that time, it is not only TYPO3 itself that keeps evolving. The extensions in use are also constantly changing.

• Maintainers respond to new requirements.
• Architectures are modernised.
• User interfaces are reworked.
• New features emerge.
• Old ones disappear.

Partly because they no longer make technical sense, partly because they were used by only a few projects, and sometimes simply because the direction of an extension has changed.

From the maintainers' point of view, this is entirely understandable. Actively maintained software has to evolve.

For an upgrade project, however, this creates a new problem. The client's platform is to be modernised. At the same time, the client understandably expects their daily workflows to change as little as possible.

These two goals cannot always be fully reconciled.

Three obvious solutions – and why none of them is perfect

In conversations with agencies, the same three suggestions usually come up.

The first is: “Then we'll just develop the missing feature ourselves.”

Technically, this is often perfectly possible. In the long term, however, you take on responsibility for a custom extension that will have to be maintained, tested and reconsidered again during later upgrades.

A missing feature turns into your own product behaviour.

The second suggestion is: “Then the client has to accept that this feature no longer exists.”

This view, too, can be justified technically. After all, software evolves.

From the users' point of view, however, this answer rarely feels satisfactory. The actual brief was, after all, not to change business processes but to modernise an existing platform.

The third suggestion is to simply stay on the old extension version. That, however, merely postpones the problem into the future. An extension that is no longer maintained rarely becomes easier to migrate with additional years. On the contrary: the technical debt keeps growing.

Interestingly, each of these solutions appears plausible at first glance. And yet none of them convinces us as a general rule.

That is why our first question is not: "How do we solve this?" We first ask a different question.

What task does this feature actually perform?

This sounds obvious. But it is surprisingly rare.

After many years of productive use, almost every enterprise platform contains features that have grown historically. Some are used daily. Others have not been touched in years.

That is why we never start such discussions with the technology, but with the actual use case.

• Is this feature really still needed today?
• Has the underlying business process changed?
• Is there now a different way in the current extension to achieve the same goal?
• Or was only the user interface changed?

Only once these questions are answered do we talk about technical solutions.

Why we almost always opt for the current extension version

There is one decision, however, that we make very deliberately. If an extension is actively maintained, we always use the current supported version.

Not because new versions are automatically better, but because we believe that an upgrade should not only solve today's project. It should keep the platform maintainable for the years to come.

An actively maintained extension evolves together with TYPO3.

• It receives security updates.
• New PHP versions are supported.
• Bugs are fixed.
• New requirements are incorporated.

Anyone who deliberately decides against this development often solves a short-term problem while creating a considerably larger one for the next upgrade.

When custom code does make sense after all

Of course there are situations in which a missing feature is business-critical. The question then arises whether custom code should be created.

Our answer here is neither a fundamental yes nor a fundamental no. We do not regard custom code as a defeat. But neither as a default solution.

When we develop a feature ourselves, we do so deliberately. Not because it happens to be missing in a new extension version, but because we have decided together with the agency and the client that this feature holds long-term business value.

That is a decisive difference. Because it turns custom code into a conscious investment – and not a spontaneous reaction to an upgrade.

There is a second case as well

Not every extension keeps evolving. In older TYPO3 projects in particular, we repeatedly encounter extensions whose development was discontinued years ago.

Here a completely different question arises. Not: "Which current version do we use?" But: "Is there even a future for this extension at all?"

If no realistic successor exists and the feature remains indispensable, we often modernise such extensions ourselves. This is not, however, about replacing the original maintainer. It is about preserving an existing business function over the long term.

This decision, too, we make deliberately. Not automatically.

Good upgrades consist of good decisions

Perhaps that is precisely the most important insight from many enterprise upgrades.

The hardest tasks rarely consist of replacing an API or carrying out a database migration. They consist of reconciling technical possibilities with economic and functional requirements.

From our perspective, an upgrade is therefore never solely a technical project. It is always also a series of product decisions.

• Which features should stay?
• Which are allowed to change?
• Which investments make sense in the long term?
• Which technical debt is still worthwhile – and which is no longer?

Tools cannot answer these questions. Nor can checklists.

They require experience. And often also the courage to accept that in some situations there is no perfect solution.

What we have learned from these projects

After many TYPO3 upgrades, we believe less today in universally valid rules than we did a few years ago. Instead, we believe more strongly in good decision-making principles.

• Actively maintained software should stay as up to date as possible.
• Business-critical features deserve a deliberate assessment.
• Custom code should be a strategic decision, not a spontaneous reaction.

And above all, every technical decision should take into account the period that begins after the upgrade.

Because the real success of an enterprise upgrade rarely shows on go-live day. It shows in the years afterwards, when the platform remains maintainable and future changes are not made unnecessarily difficult.