Carve-Out IT: Wenn ein Unternehmensteil verkauft wird

Wenn die IT plötzlich getrennt werden muss

Ein Carve-Out ist das ungeliebte Geschwister der Integration. Während Post-Merger Integration in Beratungspublikationen ausführlich behandelt wird, beschäftigt sich kaum jemand mit dem umgekehrten Fall: ein Unternehmensteil wird abgespalten, an einen Investor oder strategischen Käufer verkauft, und die IT muss in begrenzter Zeit so getrennt werden, dass der verkaufte Teil eigenständig betriebsfähig ist — ohne dass der verkaufende Konzern in Sippenhaft genommen wird.

In der Praxis ist das oft komplexer als jede Integration. Bei der Integration entscheidet man, welche Welt erhalten bleibt. Beim Carve-Out muss man eine bestehende IT-Landschaft chirurgisch aufteilen, ohne dass auf einer der beiden Seiten kritische Funktionen ausfallen. Und beide Seiten haben ab dem Closing entgegengesetzte Interessen.

Der TSA ist das wichtigste Dokument nach dem Kaufvertrag

Das Transition Services Agreement (TSA) regelt, welche Dienste der Verkäufer für den Käufer nach dem Closing für eine befristete Zeit weiter erbringt — typischerweise IT, Buchhaltung, HR-Systeme. In M&A-Carve-Outs ist der TSA derjenige Vertrag, an dem nach Closing fast täglich gemessen wird, ob das Geschäft funktioniert oder nicht.

Die Erfahrungswerte aus der Beratungsliteratur sind eindeutig: Mayer Brown empfiehlt, den TSA so früh wie möglich im Deal-Prozess zu verhandeln — idealerweise parallel zum Kaufvertrag, nicht danach. Accordion dokumentiert mehrere Fälle, in denen ein schlecht verhandelter TSA den Käufer in eine deutlich schlechtere Verhandlungsposition gebracht hat — bis hin zu dauerhaften Abhängigkeiten vom Verkäufer.

Die Kernelemente eines belastbaren TSA:

• Leistungsbeschreibung pro Service: nicht "IT-Support", sondern "Betrieb von Exchange Online für 240 Mailboxen mit definiertem SLA". Unschärfe führt fast immer zu Streit.
• Service Levels und Eskalationspfade: Reaktionszeiten, Wiederherstellungszeiten, Zuständigkeiten. CrossCountry Consulting empfiehlt, klare SLAs mit messbaren KPIs zu hinterlegen.
• Security-Verantwortung: Wer betreibt die Identitäten? Wer ist für Incident Response zuständig? Wer haftet im Fall eines Vorfalls? Diese Punkte werden häufig zu spät geklärt.
• Exit-Kriterien: Was muss erfüllt sein, damit ein Service als "abgelöst" gilt? Ohne klare Exit-Kriterien drohen sogenannte "Forever TSAs" — Verträge, die nie auslaufen, weil keine Seite ein Interesse am Ende hat.
• Preisgestaltung mit Eskalation: TSA-Services werden typischerweise zu Selbstkosten plus Aufschlag erbracht. Eine Preiseskalation ab Monat 6 oder 9 schafft den richtigen Anreiz, die Trennung zügig abzuschließen.

Identity-Separation ist der Engpass

Bei nahezu jedem IT-Carve-Out wird der gleiche Fehler gemacht: Identitäten werden zu spät getrennt. Die Annahme lautet "wir lassen die User erst mal im alten Tenant, das migrieren wir später" — und dann zieht sich diese Phase über Monate. In der Zwischenzeit hat der verkaufte Teil keine eigenen Admin-Rechte, kein eigenes Audit-Log, keine eigene Compliance-Hoheit.

Die saubere Reihenfolge bei einer Microsoft-365-getriebenen IT-Trennung:

1. Eigener Microsoft 365 Tenant für den verkauften Teil wird vor Closing aufgesetzt. Ein neuer Tenant ist innerhalb weniger Tage einsatzbereit, die Lizenzen können vom Closing-Tag an aktiv geschaltet werden.
2. Identity-Migration nach Closing — entweder mit Microsoft-eigenen Mitteln oder mit spezialisierten Tools wie Quest On Demand Migration oder BitTitan MigrationWiz, die Tenant-zu-Tenant-Migrationen mit Koexistenz unterstützen.
3. Koexistenz-Phase, in der beide Tenants nebeneinander laufen, GAL-Sync und Kalender-Sharing funktionieren, aber die Hoheit klar getrennt ist.
4. Cutover der Workloads (Mailboxen, OneDrive, SharePoint, Teams) in geplanten Wellen — typischerweise nach Abteilungen.
5. Cleanup auf der Verkäuferseite: Löschung migrierter Daten, Entfernung der Gast-Accounts, Schließen der temporären Konnektoren.

Daten-Splitting ist Detailarbeit

Wer im ERP-System gemeinsam mit dem nicht verkauften Konzernteil gebucht hat, steht vor einer kniffligen Aufgabe. Bei SAP-Systemen mit Mandantenstruktur ist eine Aufteilung formal möglich, faktisch aber oft eine größere Sanierung als jedes Greenfield-Setup. Die Carve-Out-Playbooks aus der Praxis verweisen explizit darauf, dass ERP-Daten-Integrität und Verhinderung von Data Leakage zwei separate Disziplinen sind: Was beim Käufer ankommt, muss vollständig sein. Was beim Verkäufer bleibt, muss vom verkauften Geschäft sauber bereinigt sein. Beides muss revisionssicher dokumentiert sein.

Konkrete Stolperstellen, die in Carve-Outs immer wieder auftauchen:

• SharePoint-Sites mit gemischter Datenhaltung: Eine Site enthält Inhalte beider Geschäftsteile. Die Granularität von Tenant-zu-Tenant-Migrationen reicht nicht immer aus, manuelle Vorarbeit ist nötig.
• Verteilte Postfächer: Postfächer wie info@firma.de, support@firma.de, vertrieb@firma.de werden nach Closing oft von beiden Seiten benötigt — Routing-Regeln, Weiterleitungen und neue Domains müssen sorgfältig geplant werden.
• Geteilte Anwendungen: ERP, CRM, Dokumentenmanagement — entweder muss eines der beiden Systeme neu lizenziert werden (Käufer-Side), oder eine zeitlich befristete Mitnutzung über den TSA erfolgen.
• Historische Daten: Wer behält die Verlaufsdaten? Häufig wird vertraglich vereinbart, dass der Käufer eine read-only-Kopie aller historischen Daten erhält, die ihn betreffen — das muss technisch umsetzbar sein.

Lizenzen sind kein triviales Thema

Software-Lizenzen sind selten ohne Weiteres übertragbar. Microsoft-Lizenzen aus einem Volumenvertrag (Enterprise Agreement oder NCE) bleiben beim Verkäufer — der Käufer benötigt eigene Lizenzen ab dem ersten Tag, an dem die User produktiv im neuen Tenant arbeiten. Das gilt analog für die meisten anderen Hersteller.

In der Verhandlung sollte deshalb früh geklärt werden:

• Welche Lizenzen sind assignable (übertragbar)? Bei Volume Licensing meist nur mit ausdrücklicher Zustimmung des Herstellers.
• Welche Lizenzen müssen vom Käufer neu beschafft werden? Welche Vorlaufzeit benötigt das?
• Wer trägt die Lizenzkosten während der TSA-Phase? Üblicherweise der Käufer, allerdings sind hier deutliche Aufschläge auf den Listenpreis nicht unüblich.
• Welche Open-Source-Komponenten enthalten Eigenentwicklungen — sind die Lizenzen GPL-konform getrennt?

Was am Day 1 funktionieren muss

Am ersten Werktag nach Closing müssen die Mitarbeiter des verkauften Geschäftsteils arbeitsfähig sein. In der Praxis ist das selten der Fall — typische Probleme sind:

• Login-Probleme, weil Identity Federation falsch konfiguriert wurde
• E-Mail-Routing-Schleifen zwischen altem und neuem Tenant
• Drucker, Netzlaufwerke, Telefone nicht erreichbar
• VPN-Zugänge funktionieren nicht, weil Conditional Access Policies nicht mitgewandert sind
• Kein Zugriff auf Geschäftsanwendungen, weil Lizenzen noch nicht zugewiesen sind

Day-1-Readiness ist deshalb ein eigenes Workstream im Carve-Out-Projekt. Empfohlen wird ein dedizierter Cutover-Test mindestens zwei Wochen vor dem geplanten Closing, mit einer repräsentativen Pilotgruppe und einem belastbaren Rollback-Plan.

Worauf der Verkäufer achten muss

Auch die Verkäuferseite trägt erhebliche Risiken — die in vielen Carve-Outs unterschätzt werden:

• Datenresidualien: Daten des verkauften Geschäfts dürfen nach Ablauf des TSA nicht in den Verkäufer-Systemen verbleiben. DSGVO-relevante Daten sind besonders sensitiv.
• Stranded Costs: Lizenzen, Verträge, Mitarbeiter, die dimensioniert waren für die Gesamtorganisation, sind nach dem Carve-Out überdimensioniert. Diese Kosten müssen rasch abgebaut werden, sonst belasten sie die verbleibende Profitabilität.
• Sicherheitskontinuität für den verkauften Teil während der TSA-Phase: Der Verkäufer haftet im Zweifel weiter, solange Identitäten und Daten unter seiner Hoheit sind.
• Reputationsrisiko: Ein gescheiterter Carve-Out wird häufig als Verschulden des Verkäufers ausgelegt — auch wenn die Ursache beim Käufer liegt.

Empfohlener Projektablauf

Aus der Beratungspraxis hat sich folgender Ablauf bewährt:

1. 8–12 Wochen vor Closing: IT-Inventur, Tenant-Aufbau Käuferseite, TSA-Verhandlung, Migrationstool-Auswahl
2. 4–6 Wochen vor Closing: Pilot-Migration einer Abteilung, Day-1-Cutover-Test, Lizenz-Beschaffung
3. Closing-Tag: Identity-Cutover für initiale Pilotgruppe, alle anderen User parallel im Koexistenz-Modus
4. Wochen 1–8 nach Closing: Mailbox-, OneDrive-, SharePoint-Migration in Wellen; ERP-Trennung; Anwendungs-Migration
5. Monat 3–6 nach Closing: TSA-Exit, finale Aufräumarbeiten, Stranded-Cost-Abbau auf Verkäuferseite

Welche Kosten realistisch sind

Carve-Out-IT-Projekte sind teurer als Integrationen. Die Hauptursachen: Doppellizenzen während der TSA-Phase, externer Beratungs- und Migrationsaufwand, kurzzeitige Personalverdopplung. Eine grobe Orientierung für mittelständische Carve-Outs (200–500 Mitarbeiter im verkauften Geschäftsteil): die reinen IT-Carve-Out-Kosten liegen erfahrungsgemäß zwischen 0,5 % und 2,5 % des Transaktionsvolumens, abhängig von der Tiefe der bestehenden Integration. Bei stark verzahnten Konzernstrukturen sind höhere Werte realistisch.

Wichtig ist, diese Kosten transparent in den Kaufvertrag einzuarbeiten — entweder über klare TSA-Preisformeln oder über eine separat verhandelte "Stand-up-Kosten"-Pauschale. Unklare Regelungen führen regelmäßig zu Streit und gefährden den Projekterfolg.

Fazit

Ein IT-Carve-Out ist kein verkleinertes Integrationsprojekt. Er erfordert eine eigene Methodik, eigene Vertragswerkzeuge und ein eigenes Mindset: Trennung statt Konsolidierung, Eigenständigkeit statt Synergien, befristete Koexistenz statt finaler Architektur. Wer das früh im Deal-Prozess anerkennt, gewinnt zwei Dinge: einen belastbaren TSA und eine realistische Kostenplanung. Beides erspart erhebliche Konflikte nach Closing.