t3land

Run

TYPO3 Update and LTS Migration

While a TYPO3 version is actively maintained, security fixes are there for everyone. After that they cost money, and eventually they stop altogether. An update is not a luxury, then; it is the price of running a site for the long term.

Start a project

The lifecycle sets the rhythm

TYPO3 follows a fixed pattern: every LTS version is actively maintained for a period, after which security fixes are only available through ELTS for a fee, and eventually that ends too.

Keep an eye on it and updates can be planned and budgeted. Ignore it and you usually find out at the worst possible moment. We keep the current dates in the version overview, straight from the official source.

Why the extensions decide the effort

The TYPO3 core itself updates comparatively well. The effort arises at the edges: with extensions from the repository that have not been adapted yet, and with custom code that relies on functions which no longer exist.

So there is always a list at the beginning. Every installed extension is assessed on its own: is there a compatible release, is the project still active, is the feature still in use. Experience says a portion of them falls away with no replacement, because it was installed once for an occasion and forgotten afterwards.

Testing means more than looking at the frontend

Between major versions, a good deal changes in the backend too: in content elements, in backend layouts, in permissions and in the way files are managed.

So before the switch we walk through the editorial side, with the same permissions the editors will have. Errors that only occur while editing do not show up in a frontend test. They show up on the first working day afterwards.

How we approach an update

Taking stock

Current version, installed extensions, custom code, PHP version and server environment. Only then can the effort be estimated seriously.

Reviewing the extensions

For each one: is there a compatible release, is it still maintained, and is it still needed at all?

A copy, not the original

The update runs on a copy of the installation first. The live site is only touched once the copy comes through cleanly.

Bringing custom code along

Whatever was removed or changed between versions gets caught up in the sitepackage and in the custom extensions.

Checking what editors see

Not just the frontend. Backend layouts, content elements and permissions get reviewed as well, because a fair amount changes there between majors.

Switching over and watching

A backup beforehand, a look at the error logs afterwards. The way back is planned before anyone needs it.

Common questions

What happens if we put the update off?

Once active maintenance ends, security fixes only appear within ELTS, which means for a fee. When that period runs out as well, newly discovered holes in your installation stay open.

The second effect is quieter and more expensive: the longer you wait, the more major versions lie in between and the bigger the jump becomes. A plannable task turns into a project. Which version is supported for how long is set out in the version overview.

Can we skip several major versions at once?

Yes, and it is often the pragmatic route. You do not really skip them, though; you work through the changes of every version in between. The effort adds up even if the testing only happens once.

Beyond a certain distance the arithmetic tips over, and rebuilding the templating layer becomes cheaper than catching it up. Where that point sits depends on how much custom code there is.

What about extensions that no longer exist?

That is the most common stumbling block. For each affected extension there are three routes: an actively maintained replacement, a custom implementation of the part you need, or dropping it if the feature is barely used anyway.

Which route fits is something we settle before the update rather than in the middle of it. That question usually decides the total effort.

Does the site have to go offline during the update?

Not to any noticeable degree, as a rule. The actual work happens on a copy; only the finished state goes live.

For the switch itself we plan a short window in which no content should be edited, so no changes get lost.

More services

Not sure how big the jump would be?

Tell us your TYPO3 version and the list of extensions. Even before any detailed work, that is enough to say whether this is a manageable task or a project.

Start a project See what we do