Maintenance costs saved by 50%. Goal achieved? Not quite.

In times of economic uncertainty and stagnant growth, organizations must use their IT budgets with particular care. Consolidating distributed website landscapes is a strategic lever that delivers measurable savings.

TYPO3 is especially well-suited for such consolidation projects – and for good reason:

Multi-tenancy: Multiple websites can be run on a single TYPO3 instance without interfering with each other. Each site retains its own identity but shares the technical infrastructure.

Multi-site management: Centralized administration of all websites via a single backend. Updates, security patches, and new features are deployed once and apply to all sites – instead of each one individually.

Sophisticated permissions system: Different teams can work on their respective sites without needing access to other areas. Global administrators maintain an overview, while local editors remain within their defined area.

Multilingualism: Especially for international organizations or institutions with multilingual requirements, TYPO3 offers native multilingual support that functions consistently across all consolidated sites.

The technical prerequisites for successful consolidation are therefore in place. But as our project demonstrates: Technology is just the beginning.

A team wants headings in their project to be displayed differently—aesthetic reasons, perfectly understandable. The problem: On consolidated websites, all projects share a common CSS. A change here affects all other websites.

What might appear to be stubbornness ("Why can't you just make the H2 bigger?") is actually the responsibility to keep the interests of all teams in mind.

The conflict: Project teams think project-specifically. IT needs to think system-wide.

Our advice: Establish governance early.

Define clear governance rules for consolidated systems from the outset:

• Which changes are possible on a project-specific basis?
• Which require agreement across all teams?
• Who makes the final decision in case of disagreement?

A regular exchange format (e.g., a monthly "web governance meeting") can work wonders here. Global change requests are discussed, prioritized, and agreed upon before being implemented.

Features are commissioned, developed, and approved – done? Unfortunately not. Every new feature needs to be tested and, if necessary, adapted for future TYPO3 updates.

The initial development might cost €5,000. But what's often overlooked is that every major update incurs follow-up costs – for testing, adjustments, and documentation.

Our experience shows that these follow-up costs are difficult to quantify, but typically amount to about 10% of the initial development costs per year. After three years or a "TYPO3 LTS double jump" (e.g., from TYPO3 12 to 14), this means that €5,000 effectively becomes €6,500 over the lifetime of the system.

Our advice: Communicate the Total Cost of Ownership.

Make these hidden costs transparent before commissioning features. Ask yourself:

• Is this feature truly necessary, or is there a standardized alternative?
• Can existing TYPO3 built-in features be used instead of custom development?
• Does the benefit justify the long-term maintenance costs?
• How many sites will truly benefit from this new feature?

A seemingly trivial question sparked intense discussions: Who needs to be notified about which change, and to what extent?

Team A wants to be informed immediately about every system change (push principle). Team B finds this excessive and prefers to retrieve information themselves as needed (pull principle). As is so often the case, the truth lies somewhere in between.

Our advice: Differentiated communication rules

Define different categories:

• Breaking Changes: Must be actively communicated to everyone (push)
• New Features: Announcement is sufficient; details available upon request (push + pull)
• Bug Fixes/Maintenance: Maintain a changelog; no active notification is required (pull)
• Security Updates: Immediate notification to everyone (push)

It is crucial that these rules are documented and known to all involved. A well-maintained changelog and regular (e.g., quarterly) update meetings ensure clarity.

Consolidating websites into a modern TYPO3 system offers significant cost advantages – savings of 50% on maintenance costs are not uncommon. Performance increases, accessibility improves, and updates become simpler.

However, the real challenge begins after the go-live. The next step is establishing processes that are compatible with the new, consolidated structure:

1. Transparency in communication: Feature requests require traceable status updates.
2. Clear governance: Who decides what at the global versus local level?
3. Realistic cost accounting: Total cost of ownership, not just initial development costs.
4. Differentiated information: Intelligently combining push and pull strategies.

The good news: These challenges are solvable. All it takes is the willingness to address them early on instead of dismissing them as "soft factors."

Do you have questions about website consolidation with TYPO3? I'd be happy to help.