Why We Automate Everything Worth Automating in TYPO3 Upgrades

When we talk to agencies about larger TYPO3 upgrades, the conversation almost always starts with technical topics. Which TYPO3 version is in use? Which extensions need to be modernised? How much custom code is there? Which PHP version should be used going forward?

These questions are important, of course.

Interestingly, though, they tend to occupy us internally far less than another question that usually only surfaces after several projects:

Why do we actually keep doing certain tasks by hand?

At first this question sounds surprisingly trivial. In reality, it has changed the way we work over the past few years more than many technical innovations within TYPO3 itself.

Because almost every larger upgrade consists of a mix of two very different kinds of work.

On one side are technical decisions that require experience, architectural understanding and conversations with the client. On the other side are numerous recurring tasks whose outcome should be identical every single time. Telling these two areas apart is, for us today, one of the most important parts of a successful upgrade process.

Repetitive work is not an engineering problem

At the start of our first upgrade projects, we naturally carried out many steps by hand. We analysed deprecation logs, ran upgrade wizards, adjusted configurations, checked extensions, performed database migrations and worked through our test lists point by point.

It worked.

With every additional project, however, a strange feeling set in.

Not because the tasks had been difficult.

But because we noticed that we were solving the same problems again and again.

Of course the projects differed in their details. Every platform came with its own architecture, its own business logic and its own challenges. And yet many technical patterns recurred with surprising frequency.

Certain deprecations kept appearing.

Similar adjustments to extensions became necessary across several projects.

Deployment steps ran almost identically.

And even many of the issues we found during quality assurance kept falling into the same categories.

At some point it became clear to us that we should no longer regard these tasks as actual development work.

They had become a process problem.

Experience should not stay in the minds of individual developers

In many companies, experience is treated as something personal.

One developer knows a legacy extension concept particularly well. Another remembers the pitfalls that came up during an earlier upgrade. Yet another knows exactly which sequence has to be followed in a complex deployment.

This works surprisingly well — as long as the same people are involved in every project.

From our perspective, however, this creates a structural risk.

The more knowledge exists solely in the heads of individual developers, the harder it becomes to carry out projects reproducibly.

That is why today we try to move as much recurring insight as possible into the process itself.

Sometimes this turns into a new Rector rule.

Sometimes it expands our internal knowledge base.

Sometimes a new script emerges, or an additional item on our upgrade checklist.

And sometimes a brief note in our documentation is enough to ensure that the same mistake never even occurs in the next project.

The decisive factor here is not the tool.

The decisive factor is that experience becomes part of the system, step by step.

Automation does not mean doing everything automatically

This is where we often encounter a misunderstanding.

As soon as automation is mentioned, it is easy to get the impression that we want to replace as many tasks as possible entirely with tools.

That is precisely not our goal.

Automation is excellent for tasks whose outcome is clearly defined.

• A recurring database migration.
• A known API transformation.
• A standardised deployment step.
• A visual regression that can be compared reliably.

But as soon as decisions about the subject matter are required, this advantage disappears very quickly.

A script cannot judge whether a custom backend feature still reflects the client's current business process.

It cannot decide whether an extension would be better replaced or further developed.

And it certainly cannot discuss with a product owner why a particular feature came into being over the past few years.

These tasks will remain the responsibility of experienced developers in the future too.

That is exactly why we do not see automation as a replacement for expertise.

We see it instead as a way to free experts from routine work.

Our tools are the result of many projects

When visitors see our office or talk to our team, they occasionally ask about the Legacy Updater or our internal Rector rules.

Sometimes this gives the impression that these tools were the starting point of our process.

In reality, it was exactly the other way around.

First came the projects, then the problems — and only after that did the tools emerge.

Our internal upgrade checklist is a good example of this.

Today it comprises forty-four individual checkpoints and accompanies a project from the first local development environment all the way to the final go-live check. At the beginning there are questions such as access to Git, up-to-date database dumps or the local reproducibility of the installation. At the end, we deliberately check seemingly minor things as well — such as 404 and 403 pages, redirects, robots files or the sitemap — because it is exactly these details that are often the first to be noticed after a launch.

None of these points was developed in theory.

Every single one exists because at some point a problem occurred in precisely that spot.

The same applies to our Legacy Updater.

Or to our internal migration scripts.

Or to the many small helpers that outsiders will probably never get to see.

All of them are the result of concrete experiences from real projects.

Good processes improve more than just speed

When automation is discussed, the conversation almost always turns to time savings first.

Speed does matter, of course.

From our point of view, however, it is more of a side effect.

The real benefit lies elsewhere.

A reproducible process improves quality.

When a deployment follows the same steps every time, the likelihood of forgetting an important point shortly before go-live drops.

When recurring code transformations are automated, fewer careless mistakes occur.

And when visual regression tests run automatically after every major change, many problems no longer have to be discovered during an extensive manual testing phase in the first place.

This does not just reduce development effort.

It also changes quality assurance.

The earlier errors become visible, the cheaper they are to fix.

That is why today we deliberately invest time in things that remain invisible to the end client at first.

They often only pay off weeks or months later.

Every completed project changes the next one

Perhaps it is precisely this idea that distinguishes us most from the way we worked a few years ago.

We used to consider an upgrade complete as soon as the platform was running successfully on the new TYPO3 version.

Today, a second analysis often begins at exactly that point.

• Which insights from this project will we need again in the future?
• Which steps cost time unnecessarily?
• Which problems could we have spotted earlier?
• Which parts of the process should we automate or document?

Only once these questions have been answered do we really consider a project complete.

Because our actual goal is not merely to modernise a single platform successfully.

Our goal is for the next upgrade to be a little better than the previous one.

What we have learned from this

In hindsight, we would probably organise our first upgrade projects quite differently today.

Not because the solutions back then were bad.

But because we have since understood that long-term quality does not arise from good developers alone.

It arises when good developers turn their experience into processes, tools and shared standards.

Perhaps that is precisely what describes the difference between development and engineering.

Development solves a specific problem.

Engineering ensures that the same class of problems no longer has to be solved in the same way in the future.

And that is exactly why today we invest at least as much energy in our processes as in the actual code.