TYPO3 in Munich: a lot of legacy, high expectations
Munich is home to corporate headquarters, insurers, publishers and universities: organisations with multilingual sites, many editors and structures that have grown over time. TYPO3 has been widespread here for two decades, and that shapes the work: it is less often about a first website than about handling what already exists intelligently.
Our most frequent Munich cases: the LTS jump across several versions, the relaunch with rankings that must not get lost, and the question of which of the years-old extensions are genuinely still needed.
How working across the distance actually works
Honestly: it works the way it would with a Munich agency, because TYPO3 work happens in Git, in video calls and on preview environments, not in a meeting room. The difference lies in two or three meetings over the course of a project, and for those we get on the train.
What we do not do for it: rent a Munich address to simulate proximity. The office is in Stuttgart-Feuerbach, the distances are short, and both of those are stated here rather than disappearing into the small print.
Maintenance with a named contact
With larger Munich installations in particular, the decisive question is rarely who builds it but who looks after it afterwards. Our maintenance means security advisories watched, updates in planned waves, backups demonstrably restorable, and a person who knows the installation when something jams.
Where approvals run through email chains
In publishing houses, insurers and corporations there is almost always an approval process, and it almost always runs past the website. The text travels as a document through three inboxes, gets agreed, and eventually somebody types it into the backend.
TYPO3 can model that better. With workspaces, changes are made in a draft area, checked as a finished page in the preview, and only published after approval. The decisive difference: what gets checked is the result, not a description of it.
We do not recommend it across the board. Where an editor writes and publishes themselves, a draft area is extra work with nothing in return. Where things get agreed anyway, it replaces a process that costs time today and still lets mistakes through.
Large installations, extension lists that have grown
The second Munich classic is the legacy: an installation that has been running for a decade, with an extension list nobody can fully explain any more.
Before every update we go through that list one by one: is there a compatible release, is the project still maintained, is the feature still used at all? Experience says a noticeable share falls away with no replacement, installed for an occasion and forgotten afterwards. That is the cheapest form of reducing effort, because it costs nothing beyond the review. The criteria are set out under evaluating extensions.