Why We Can Offer TYPO3 Upgrades at a Fixed Price

There is hardly a topic that comes up more often in initial conversations with agencies than project costing.

Almost everyone has experienced projects that looked manageable at first and turned out to be considerably more complex during implementation than expected. Old extensions behave differently than documented, custom modifications reach deep into the TYPO3 core, or in the middle of the upgrade it turns out that a critical business process was implemented exclusively in a barely documented extension.

The more such experiences you accumulate, the more reasonable the conclusion seems:

"You can't really offer a major TYPO3 upgrade at a fixed price in good conscience."

We understand this view well. A few years ago we would probably have argued much the same way. Today we see the relationship a little more carefully.

Not because upgrade projects have become easier, but because we now understand better where uncertainty in such projects actually comes from.

The biggest risk factor is rarely TYPO3 itself

When a project budget gets out of hand, it is often assumed that the upgrade was harder than expected. Our experience is a different one.

Most surprises already existed before the project began. They simply only became visible during development. That is a decisive difference.

An unmaintained extension does not suddenly become problematic because the upgrade has started. A legacy architecture does not first emerge during the migration. And a fifteen-year-old PI-based extension does not become complicated overnight.

All of these things were already there. The only difference lies in when they are recognised.

That is why we do not regard the analysis phase as organisational preparation. It is already an essential part of the actual engineering process.

Good estimates do not come from experience alone

Experience helps, of course. After more than 150 TYPO3 upgrades we recognise many technical patterns far faster than we did a few years ago. We know which extension combinations regularly cause problems, we are familiar with the typical architectures of older enterprise projects, and we have developed a good sense of which areas of a system deserve particular attention.

Even so, in our view it would be dangerous to build good estimates on experience alone. Experience is valuable, but it remains subjective.

That is why we try to translate as many insights as possible into a reproducible analysis process:

• Which extensions are in use?
• Which of them are actively maintained?
• How large is the custom code?
• Which integrations exist?
• How has the platform evolved over recent years?
• Which areas, in our experience, carry the greatest technical risk?

The more of these questions that can be answered before the project even begins, the smaller the share of genuine uncertainty becomes.

Our goal is not to eliminate every risk

The impression sometimes arises that a fixed price automatically means a project is entirely predictable. That would be neither realistic nor honest.

Even after a careful analysis, questions remain open. Perhaps there is a custom extension whose actual scope of functionality only becomes fully visible during the migration. Perhaps it turns out that a third-party extension no longer offers important features in its current version. Or a previously unknown edge case surfaces during quality assurance.

Such situations cannot be entirely avoided. Our goal, therefore, is not to eliminate uncertainty. Our goal is to make it as visible as possible.

The smaller the unknown area becomes, the more reliable any costing becomes.

Why processes are more economical than heroics

Especially on complex projects, it is easy to assume that successful developers are above all exceptionally good at solving problems. That is true. At least as important, however, is the ability to ensure that the same problems do not have to be solved again in every project.

This is where engineering begins for us:

• our internal upgrade checklist,
• the Legacy Updater,
• our own Rector rules,
• automated regression tests,
• deployment scripts,
• our knowledge base.

None of these investments was developed for a single project. They came about because we observed the same patterns again and again.

Each new tool reduces a small part of the uncertainty. On its own, this effect often looks unspectacular. Across many projects, however, it changes the entire basis for costing.

Why quality and economy go together

One interesting observation has occupied us particularly in recent years: many companies regard quality as additional effort.

• more tests,
• more documentation,
• more reviews,
• more processes.

In the short term, that is correct. In the long term, however, the economics of the entire project change.

When visual regression tests automatically detect differences during development, the manual testing effort later drops considerably. When a reproducible deployment process exists, far fewer surprises arise at go-live. When frequent migrations are automated, not only the development effort but also the probability of errors goes down.

In other words: good engineering does not only save development time, it simultaneously reduces the cost of quality assurance. It is precisely this connection that, in our view, is often underestimated.

There are projects we deliberately do not offer at a fixed price

This section may come as a surprise. Despite everything, we do not offer every upgrade at a fixed price. There are situations in which we deliberately advise against it:

• when essential parts of the platform are missing,
• when the installation is not runnable,
• when source code or database are incomplete,
• or when the actual project scope has not yet been defined at all.

In such cases a fixed price would not be a strength. It would be speculation.

We do not believe that a good offer comes from taking on as much risk as possible. A good offer comes about when both sides understand which risks actually exist and which have already been cleanly assessed.

Why this is particularly interesting for agencies

Many of our projects arise in collaboration with agencies. It is precisely there that we frequently observe the same conflict of objectives.

On the one hand, end customers want planning certainty. Budgets have to be approved early. On the other hand, the agency does not want to take on an economic risk it cannot assess.

A reproducible engineering process helps both sides. It does not replace experience, but it reduces the number of unknown factors that make sound costing difficult.

That is exactly why we do not regard a fixed price as a sales instrument. For us, it is rather the result of an engineering process that systematically reduces uncertainty.

What we have learned from this

When we look back today on our first major upgrade projects, we notice how much our understanding of project planning has changed. We used to believe that a good estimate came above all from experience.

Today we would say: a good estimate comes from having to estimate as little as possible. The more knowledge is already available before the project begins, the more reliable any costing becomes.

Perhaps this very thought describes the true connection between engineering and economy. Engineering does not make projects easier. Engineering makes projects more predictable.

And that is exactly why we can offer a fixed price for many TYPO3 upgrades today – not because we ignore risks, but because we have learned to make them visible far earlier.