Upgrade or relaunch? Why the real decision has nothing to do with TYPO3 versions

This question accompanies practically every larger TYPO3 project at some point. The older an installation gets, the more often it comes up – usually not among the developers, but at management level. Because there it is not about APIs or extensions, but about budgets, risks and the question of which decision will keep the platform viable for the years ahead.

Interestingly, we see again and again that this discussion starts with the wrong criteria. People talk about version numbers, outdated PHP versions, no-longer-supported extensions or the state of the source code. All of that is of course relevant. Nevertheless, in our view none of these topics decides whether an upgrade makes sense.

The real question is rather:

How much knowledge is already embedded in this platform today – and what would it cost to rebuild that knowledge from scratch?

Software ages differently than buildings

It is tempting to compare software to a building. At some point a house is old, the building services no longer meet current standards, and eventually the question arises whether a renovation still makes sense.

Software, however, works differently.

A ten-year-old TYPO3 project is not automatically technically bad. Often the opposite is true. The fact that a platform has been used continuously for many years usually means that it has created real business value. Editors have adapted their workflows to it, individual processes were integrated, interfaces emerged and countless small optimisations were implemented that appear in no specification document in the world.

It is precisely these things that make an enterprise platform valuable. And it is precisely these things that do not simply disappear by deciding to "rebuild everything".

The code is rarely the real problem

Some time ago an agency brought us into an upgrade project whose technical starting point, at first glance, did indeed argue for a relaunch.

The platform was still running on TYPO3 8.7, had grown over many years and consisted of around forty extensions, several individually developed backend modules and a domain application that was deeply integrated into the end client's business processes. Some of the third-party extensions in use had long since stopped being actively maintained, many APIs were outdated, and individual parts of the project still dated from a time when TYPO3_DB was the usual way to access the database.

One could have found good arguments for developing everything anew. In fact, the discussion initially went exactly in that direction.

The longer we worked with the project, however, the clearer it became that it was not the technical state of the system that posed the real challenge. The bigger challenge was to understand how much business logic had accumulated in this application over the years.

Many functions seemed small or inconspicuous at first glance. Some were only a few lines of code. Nevertheless, they had become second nature to the users and were used every day. A relaunch would have meant first rediscovering all these details, then redesigning them, and finally testing them again.

So the real complexity did not lie in the code. It lay in the knowledge.

Why upgrades often become unnecessarily expensive

It is precisely at this point that our view of TYPO3 upgrades has fundamentally changed over the past years.

When we carried out our first larger upgrade projects, we thought – like many other teams – mainly in terms of technical tasks. Which APIs need to be replaced? Which extensions are compatible? Which upgrade wizards need to be run?

Today we would describe the same projects completely differently. We now see upgrades above all as an engineering task.

Because the actual costs surprisingly rarely arise from TYPO3 itself. They arise from repeated work, from uncertainty, from manual processes – from things that have to be done several times, even though they would actually only be necessary once.

A typical example is the step-by-step modernisation of a code base. Many upgrade projects first adapt the code just enough for TYPO3 9 to work. Shortly afterwards the same spot is changed again so that TYPO3 10 runs. Then further adjustments follow for TYPO3 11 and TYPO3 12.

Technically, this path is perfectly correct. From an engineering perspective, however, it creates work that exists solely because the development process is oriented towards intermediate versions. For the later operation of the platform, this work brings no additional benefit.

We observe the same thing with testing. When extensive manual regression tests become necessary after every major change, effort and project risk rise continuously. The real problem, however, does not lie in the testing itself, but in the fact that the development process offers too few opportunities to make errors visible automatically and early.

The more often we have seen such patterns, the clearer it became to us that the quality of an upgrade does not depend solely on how well developers write code. It depends at least as much on how well the upgrade process itself was engineered.

Good engineering processes change the economics of an upgrade

That was probably the most important insight of the past years.

Many companies regard engineering as additional effort. Scripts have to be written. Automated tests cost time. Deployment processes are built. Internal tools emerge, even though the client never sees them later.

In the short term, that is even true. All these things cost time. In the long term, however, they significantly change the economics of a project.

• A reproducible migration process reduces repeated work.
• Automated regression tests reduce the manual testing effort.
• A shared knowledge base prevents the same problems from being solved again in every project.
• A structured checklist reduces the risk at go-live.

None of these measures immediately produces a new feature for the end client. Together, however, they ensure that an upgrade becomes more predictable, higher in quality and often more economical as well.

In our view, that is exactly the difference between development and engineering. Development solves a problem. Engineering ensures that the same problem never has to be solved the same way again.

Why we decided in favour of the upgrade

In the project described, this very way of thinking ultimately led to a different decision.

We no longer saw the project as a sequence of individual TYPO3 versions, but as a platform that was to be brought onto a new target architecture. From this emerged our approach of consistently separating code and database migration. This allowed us to avoid many intermediate steps that seem unavoidable in a classic upgrade process.

Tools such as Rector, the TYPO3 Extension Scanner, our own Legacy Updater extension and visual regression tests with BackstopJS were important building blocks here. What was decisive, however, was not the individual tool, but the way they worked together.

Each tool had only one job: to permanently eliminate a certain category of recurring work.

The result was not only a successful migration to TYPO3 14.3. The platform additionally benefited from a more modern architecture, noticeably better performance and a code base that will be considerably easier to develop further in the future.

Above all, however, a discussion about a possible relaunch turned into an upgrade that was economically more convincing than a complete rebuild. Not because TYPO3 had become easier, but because we changed the engineering process.

What we took away from this project

When we look back at this project today, we hardly think about TYPO3 8.7 or TYPO3 14.3 anymore. The version numbers were ultimately just the frame. The real insight was a different one.

The cost of an enterprise upgrade is determined far more by the engineering process than by the number of major versions in between.

The better one succeeds in avoiding repeated work, making uncertainty visible early and building quality systematically into the process, the more economical an upgrade becomes – and the higher the quality of the result at the same time.

Perhaps that is exactly the most important reason why today we talk about version numbers far less than we did a few years ago. Not because they are unimportant, but because they are rarely the real challenge.