Why we believe senior developers shouldn't spend their time on upgrade routine

A few years ago, we would probably have answered this question differently ourselves.

Of course a complex TYPO3 upgrade needs experienced developers. Anyone who has ever modernised an enterprise platform that has grown over many years knows that it constantly requires technical decisions which can neither be automated nor fully captured in a checklist.

Even so, today we would add something to that statement.

Not every task within an upgrade project requires the same kind of experience.

And in our view, this very distinction changes how agencies should organise larger modernisation projects.

Experience is most valuable where decisions are made

When we work with agencies, we frequently encounter very strong development teams. Many have experienced TYPO3 architects, senior developers and technical leads who have supported their clients for years and know their business processes in detail.

These developers in particular are often the most important reason a project succeeds in the long term.

• They design architectures.
• They advise clients.
• They discuss new requirements.
• They make decisions about future extensions.
• They identify technical risks long before they become visible.

All of these tasks create immediate value.

An enterprise upgrade, however, does not consist solely of such activities.

A considerable part of any larger migration project consists of work that demands a high degree of technical care, yet whose course unfolds remarkably similarly across many projects.

This is exactly where the real discussion begins for us.

An upgrade consists of very different tasks

From the outside, a TYPO3 upgrade often looks like a single technical task.

In practice, however, it is more a collection of very different disciplines.

First there are the actual architectural decisions.

• Which target version should be operated in the long term?
• Which extensions will be kept?
• Which will be replaced?
• How does the system architecture change?
• Which business logic should be modernised?

These questions cannot be standardised.

They require experience, technical understanding and often intensive conversations with the client as well.

Alongside this, however, there is a second area.

• Code has to be migrated.
• Upgrade wizards have to be prepared.
• Deployment processes have to be built reproducibly.
• Regression tests have to be carried out.
• Known migration patterns reappear.

Many of these tasks are by no means trivial.

Yet they differ fundamentally from architectural work.

The more often a team handles such projects, the more these areas in particular can be standardised and systematised.

Specialisation changes the economics

Let us imagine two agencies.

The first develops bespoke TYPO3 projects, supports digitalisation initiatives, builds new features and occasionally carries out larger upgrades.

The second focuses almost exclusively on TYPO3 upgrades and handles several migrations in parallel.

Both employ excellent developers.

After a few years, their competencies will nevertheless differ.

Not because the developers are differently talented, but because specialisation inevitably changes the process.

A team that handles upgrade projects every week eventually stops merely solving problems.

It begins to recognise patterns.

• Which deprecations occur regularly?
• Which extensions repeatedly cause the same difficulties?
• Which test cases are missing in almost every project?
• Which deployment steps can be standardised?

Out of these observations, tools emerge.

• Checklists.
• Automation.
• Internal knowledge bases.
• Custom Rector rules.

And it is precisely this that changes the economics of future projects.

Why we do not believe experience alone is enough

It would be easy to claim that experienced developers automatically perform better upgrades.

Our experience, however, shows that experience alone does not scale.

If a project succeeds because a single senior developer remembers a hundred small details, then the company does have an outstanding employee, but not yet a reproducible process.

That is precisely why we try to permanently transfer as many recurring insights from individual projects as possible into the way we work.

Our internal upgrade checklist is a good example of this.

It did not emerge at a whiteboard, but out of many projects.

Every additional check step exists because at some point a problem occurred at exactly that spot.

The same applies to our knowledge base, our deployment scripts or the Legacy Updater.

They all pursue the same goal.

Experience should not remain solely in the heads of individual developers. It should become part of the engineering process.

What agencies gain from this

When we work with agencies, we therefore do not see ourselves as a replacement for their developers.

That would hardly make sense.

The people who have supported the client for years understand their requirements far better than we do.

Our goal is rather to relieve these developers precisely where specialisation makes the biggest difference.

While our team concentrates on the actual upgrade process, architects and technical leads can continue to devote themselves to the topics where their knowledge has the greatest impact on project success.

• New features.
• Architectural decisions.
• Workshops.
• Consulting.
• Strategic development of the platform.

In our view, this is exactly where the real value of a white-label collaboration arises.

Not by outsourcing tasks, but by both teams doing what they can contribute most to.

Why this has nothing to do with speed

Sometimes the impression arises that specialisation is primarily a question of speed.

Of course projects often benefit when a team regularly works on similar tasks.

The actual goal, however, is a different one.

We want to reduce uncertainty.

The more recurring tasks are standardised, the better effort, quality and risks can be estimated.

That is precisely why we invest so much time in processes, tools and internal standards.

Not because they are spectacular, but because they ensure that our developers can concentrate on the few tasks that simply cannot be standardised.

The real task of experienced developers

When we look back today at larger enterprise upgrades, we are repeatedly struck by the fact that the hardest decisions were rarely of a technical nature.

It was not about which API had to be replaced or which extension should be updated.

The real challenges almost always lay where technical possibilities and business requirements came together.

• Should an existing feature be retained even though it no longer exists in a current third-party extension?
• Is a bespoke extension worthwhile in the long term?
• Does a particular process even still make sense today?

That, in our view, is precisely where the greatest value of experienced developers arises.

Not in repeatedly working through familiar migration steps, but in decisions that determine the future character of a platform.

What we have learned from this

Perhaps the most important insight of recent years is therefore not that TYPO3 upgrades require specialist knowledge.

They undoubtedly do.

The real insight is rather that this specialist knowledge can be applied in very different ways.

Part of it belongs in architectural decisions. Part of it belongs in conversations with clients. And a surprisingly large part can, over the course of many projects, be transferred into processes, tools and shared standards.

That is where we see the real value of specialisation today.

Not in a team programming faster, but in it improving the entire engineering process with every completed project.

Because in the end, it is not only future upgrade projects that benefit from this.

Above all, the developers benefit, whose time is freed up again for the tasks where experience really does make the biggest difference.