29. Juli 2025

Post Merger Integration (PMI):

Legacy vs. Cloud native – was kann bleiben, was muss gehen?

M&A ist oft ein Spiel der Konsolidierung: Märkte, Teams, Produkte und natürlich: Systeme. Aber während Finanz- und HR-Prozesse zügig harmonisiert werden, bleibt die IT-Architektur oft ein unübersichtliches Minenfeld.

Zwei Unternehmen, zwei Tech-Stacks, zwei Philosophien. Die einen schwören auf ihre monolithische Kernanwendung, „läuft doch stabil seit 15 Jahren“. Die anderen bauen Microservices, die mehrfach am Tag neu veröffentlicht werden.

Die zentrale Frage nach dem Merger lautet: Was kann bleiben und was muss (endlich) gehen?

Der Cloud-native Bluff

Viele Unternehmen behaupten heute, „Cloud-native“ zu sein. In der Realität heißt das oft: Die Monolithen laufen jetzt halt in AWS. Aber Cloud-native ist mehr als ein Hosting-Ort. Es bedeutet:

• Modularität statt monolithischer Knoten
• Self-Contained Services mit klaren Schnittstellen
• Automatisierte CI/CD-Pipelines
• DevOps-Mindset und Ownership im Team

Und es bedeutet vor allem: Schnelligkeit, Anpassungsfähigkeit, Resilienz – die Eigenschaften, die man nach einem Merger dringend braucht. Legacy-Systeme dagegen haben eine andere DNA:

• Schwerfällige Release-Zyklen
• Abhängigkeiten, die niemand mehr überblickt
• Inhouse-Spezialisten, die bald in Rente gehen
• Technologien, die von heutigen Frameworks nicht mal mehr erkannt werden

Realität vs. Ideal: Warum Legacy nicht automatisch böse ist

Jetzt kommt die Gegenperspektive und sie ist wichtig: Nicht jedes Legacy-System ist ein Problem!

Ein gut gepflegter Monolith mit klarer Dokumentation, stabilen APIs und eingespielten Wartungsprozessen kann effizienter und risikoärmer sein als eine halbfertige, schlecht orchestrierte Cloud-Architektur.

Entscheidend ist nicht das Buzzword, sondern:

• Wartbarkeit
• Skalierbarkeit
• Integrationstiefe
• Kosten-Nutzen-Verhältnis

Oder ganz pragmatisch gefragt:

• Können wir neue Features in weniger als 30 Tagen ausrollen?
• Können wir das System modular erweitern ohne die Architektur zu ändern?
• Wie viele Menschen und Tage braucht es für einen Hotfix?

Architektur-Duelle nach dem Merger: Typische Szenarien

1. Zwei Monolithen treffen sich und keiner will zuerst aufgeben

Hier geht es um Politik, nicht um Technik. Oft entscheidet Macht, nicht Qualität. Was tun?

• Architektur-Bewertung durch ein externes, neutrales Tech-Assessment
• Funktionsweise, Tech Debt und Skalierungspotenzial objektiv vergleichen
• Kompromiss ist keine Lösung: Klar entscheiden, dann umbauen oder ablösen

2. Cloud-native übernimmt den Legacy-Zoo

Klingt logisch, ist es aber nur, wenn der Cloud-native Stack dazu auch fähig und vorbereitet ist. Sonst entsteht eine gefährliche Überforderung der Dev-Teams. Was ist zu beachten?

• Roadmap zur kontrollierten Migration erstellen
• MVP-Migrationen für kritische und abgegrenzte Domains (z. B. Reporting, Auth, Search)
• Hybride Phase sauber definieren: Wer trägt Verantwortung? Was wird abgelöst?

3. Beide Seiten sind Legacy, aber keiner hat es gemerkt

Wenn zwei monolithische Systeme aufeinandertreffen, kommt es zu Stillstand statt Synergien.

• Wie würden wir ein System heute und für die Zukunft neu aufbauen?
• Rebuild einzelner Komponenten (Frontends, APIs, Schnittstellen) mit Cloud-Prinzipien
• Zielbild definieren: In 18 Monaten x% des Umsatzes über die neue Architektur

Was hilft bei der Entscheidungsfindung?

1. Tech Due Diligence 2.0: Nicht nur Code scannen, sondern Architektur im Kontext von Business-Zielen analysieren.

2. Domain-driven Thinking: Welche Domains bleiben stabil uns welche werden integriert, ersetzt oder verschmolzen? Klarheit über Fachlichkeit führt zu technischer Klarheit.

3. Cloud-Maturity-Check: Wie weit ist das Zielsystem wirklich? Gibt es API-First-Prinzipien, Observability, Rollbacks und skalierbare Datenarchitekturen?

4. Timeline & Kosten realistisch kalkulieren: Refactoring ist keine Freizeitbeschäftigung oder Routinetätigkeit, es muss messbar Mehrwert erzielt werden oder unterbleiben.

Fazit: Mut zur Entscheidung mit technischer Tiefe

Nach dem Merger gibt es keine perfekte Architektur, aber es braucht eine klare Entscheidung und verantwortungsvolle Führung. Wer die Altlasten mitzieht, „weil’s ja irgendwie noch läuft“, verlangsamt Innovation. Wer blind alles neu bauen will, ohne Prozess- und Businesskontext, riskiert Chaos und vernichtet Kapital.

Die beste Lösung liegt oft dazwischen: Mut zur Cloud mit Respekt vor gewachsener Substanz.

Schauen Sie gerne auch mal auf fup-ag.com