Decisions
TYPO3 Update or Relaunch? How to Decide
The question comes up in almost every conversation about an older TYPO3 installation. There is no blanket answer, but the criteria the answer hangs on are few enough to list.
Why the question comes up at all
The trigger is almost always the same: the TYPO3 version in use is approaching the end of its support or has passed it. That forces a decision which could be postponed until then.
At that point two quotes appear that sit far apart. One prices an update, the other a rebuild. The difference looks arbitrary and has traceable reasons.
What an update actually covers
An update brings the core to a new version and catches up everything affected by that: extensions, custom code, configuration, occasionally the server environment.
It does not change the structure of the site, the information architecture or the appearance. If the site was confusing before, it is still confusing afterwards, only on a current version.
When an update is enough
Several signs point that way together. The structure of the site still matches what the organisation does. The editorial team gets along with the backend. The sitepackage is put together traceably and lives in version control. The number of extensions is manageable and most of them are still maintained. The distance to the target version is one or two majors.
Where that holds, an update is almost always the more economical route. It solves the acute problem and leaves everything else untouched.
When a relaunch is the more honest route
Other observations point the other way. The page structure mirrors an org chart rather than the questions visitors arrive with. Nobody can say why certain things in the templating are solved the way they are. Essential configuration sits in the database. Several extensions have gone years without an update, and for some there is no replacement. Several majors lie between the current version and the target.
In that situation an update will be technically possible, but the effort approaches that of a rebuild without delivering its benefit. You pay to preserve a state nobody is happy with anyway.
The middle route
There is a third possibility that is rarely offered: update now, rebuild in stages afterwards. The installation comes back into support, and the structural work happens in planned steps over the following months.
That makes particular sense when the site is business-critical and a longer rebuilding phase would be hard to justify. The condition is that the stages actually get scheduled rather than quietly deferred.
A question that gets decided along the way
A relaunch automatically raises the accessibility question. Anyone rebuilding the templating layer anyway can get it right from the start; reaching the same standard afterwards is considerably more work.
The same goes for the structure of the addresses. A relaunch is the moment when the URL structure and the internal linking can be reordered at no extra cost, because a redirect plan is being written in any case.
What we look at
Before we make a recommendation we always look at the same things: the current version and the distance to the target, the list of extensions and how well each is maintained, the extent and state of the custom code, whether the installation is managed with Composer, where the configuration lives, and how the page structure matches the traffic it actually gets.
That usually produces a clear picture. When it does not, we say that too, rather than quoting a figure based on guesses.