Legacy-Systeme ablösen: Eine Sourcing-Strategie für den schmerzfreien Systemwechsel

Warum scheitern Transformationsprojekte häufiger an der Angst vor dem Abschalten des Alten als an der Euphorie über das Neue? Es ist das „Legacy-Paradoxon“: Man sehnt sich nach Agilität, klammert sich aber gleichzeitig an Systeme, deren Innenleben niemand mehr vollends versteht. Wer eine Sourcing-Strategie entwickelt, um Legacy-Systeme abzulösen, muss daher mehr tun, als nur Software zu evaluieren. Er muss den Mut finden, den operativen Herzschlag des Unternehmens von einer „eisernen Lunge“ auf ein modernes, atmungsaktives Ökosystem umzustellen – ohne dass der Patient auf dem OP-Tisch aufwacht.

Das archäologische Grabungsfeld: Wenn technische Schulden zur Innovationsbremse werden

In vielen gewachsenen Unternehmen gleicht die IT-Landschaft keinem modernen Campus, sondern einem archäologischen Grabungsfeld. Tief im Fundament arbeiten unermüdlich alte Mainframes oder AS/400-Systeme, auf die über Jahrzehnte hinweg Schicht um Schicht neue Applikationen, Schnittstellen und „Quick-Fixes“ aufgetragen wurden.

Diese technischen Schulden sind weit mehr als ein ästhetisches Problem der IT-Architektur. Sie sind eine direkte Bedrohung für die Wettbewerbsfähigkeit:

• Wissens-Erosion: Die Experten, die den ursprünglichen Code geschrieben haben, sind längst im Ruhestand. Jede Änderung am System wird zum riskanten Blindflug.
• Sicherheits-Vakuum: Veraltete Protokolle und fehlende Patches machen Legacy-Systeme zum bevorzugten Einfallstor für Ransomware.
• Agilitäts-Blockade: Während Start-ups neue Features in Tagen releasen, benötigen Legacy-getriebene Unternehmen Monate, nur um eine einfache API-Anbindung zu stabilisieren.

Sourcing ist hier kein Einkauf, sondern eine „Operation am offenen Herzen“

Der Sourcing-Prozess für den Ersatz solcher Systeme unterscheidet sich fundamental von einer Neuanschaffung auf der sprichwörtlichen „grünen Wiese“. Bei einem Greenfield-Projekt kaufen Sie eine Vision; beim Legacy-Replacement kaufen Sie eine Befreiung. Es geht nicht nur darum, Lizenzen zu erwerben, sondern eine hochkomplexe Transition zu orchestrieren.

Ein klassischer Einkaufsprozess greift hier zu kurz. Sie sourcen nicht nur eine Software-Funktionalität, sondern:

1. Migrations-Intelligenz: Die Fähigkeit des Anbieters, historische Datenbruchstücke in saubere, zukunftsfähige Strukturen zu transformieren.
2. Integrations-Resilienz: Eine Architektur, die während der (oft jahrelangen) Übergangsphase stabil mit den verbleibenden Alt-Systemen koexistieren kann.
3. Kulturelle Akzeptanz: Strategien, um Anwender abzuholen, die seit 20 Jahren dieselben Tastenkombinationen nutzen und das neue System instinktiv als „langsamer“ empfinden werden.

In diesem strategischen Leitfaden analysieren wir, wie Sie den Markt systematisch sondieren, die richtige Architektur-Philosophie (den sicheren Monolithen vs. das flexible Composable ERP) wählen und Verträge so gestalten, dass Sie nicht direkt vom alten Vendor-Lock-in in die nächste Abhängigkeitsfalle tappen.

Ihr erster Schritt aus der Legacy-Falle: Starten Sie Ihre Marktanalyse nicht mit vagen Google-Suchen. Nutzen Sie die kuratierte und spezialisierte Datenbank von https://find-your-software.de, um gezielt nach Nachfolgelösungen zu suchen, die nachweislich Erfahrung mit Ihrer spezifischen Branche und Ihren Altsystemen haben.

1. Die Bestandsaufnahme: Das TIME-Modell statt „Rip and Replace“

Der größte Fehler beim Sourcing ist der impulsive Wunsch, „alles neu“ zu machen. Ein „Big Bang“-Austausch (Rip and Replace) ist bei tief integrierten Legacy-Systemen oft ein Himmelfahrtskommando. Bevor Sie RFI (Request for Information) versenden, müssen Sie Ihr Anwendungsportfolio bewerten.

Nutzen Sie das von Gartner populär gemachte TIME-Modell für Ihre Sourcing-Entscheidung:

Strategie	Beschreibung	Sourcing-Implikation
Tolerate (Tolerieren)	Das System hat geringen Geschäftswert, verursacht aber kaum Kosten/Risiken.	Kein Sourcing. Status Quo beibehalten (ggf. Support-Verlängerung).
Invest (Investieren)	Das System ist stabil, aber funktional veraltet. Hoher Geschäftswert.	Refactoring / Re-Platforming. Sourcing von Entwicklungsdienstleistern oder Cloud-Infrastruktur, keine neue Softwarelizenz.
Migrate (Migrieren)	Technisch obsolet, hoher Wartungsaufwand, aber notwendige Funktion.	Re-Purchasing. Klassische Ausschreibung für moderne Standardsoftware (SaaS). Fokus auf Datenmigration.
Eliminate (Eliminieren)	Geringer Geschäftswert, hohes Risiko.	Retirement. Aktives Abschalten ohne Ersatz oder Konsolidierung in bestehende Systeme.

Diese Analyse verhindert, dass Sie Budget für Systeme verschwenden, die eigentlich nur abgeschaltet werden müssten. Lesen Sie dazu auch unseren vertiefenden Artikel über die Entscheidungsfindung: ERP-Upgrade oder Ablösung: So treffen Sie die richtige Entscheidung.

Achtung: Suchen Sie nicht nur das System, sondern das Ökosystem In Jahrzehnten mit Legacy-Software haben Fachabteilungen oft Workarounds entwickelt, um funktionale Lücken zu füllen. Diese „Excel-Ufos“ und Access-Datenbanken sind die Schatten-IT, die den eigentlichen Prozess am Laufen hält. Eine Sourcing-Strategie, die nur den Monolithen ersetzt, lässt die Nutzer im Regen stehen. Ihr Projekt-Scope muss zwingend die Identifikation dieser Satelliten-Systeme beinhalten: Werden deren Funktionen im neuen Standard abgebildet oder müssen hierfür dedizierte Microservices gesourct werden?

2. Architektur-Sourcing: Suite vs. Best-of-Breed – Die Anatomie der Entkopplung

Wenn die Entscheidung „Migrate“ gefallen ist, stehen Sie vor der fundamentalen Architekturfrage, die über die Flexibilität der nächsten 15 Jahre entscheidet: Ersetzen wir den alten Monolithen durch einen neuen Monolithen (All-in-One Suite) oder orchestrieren wir eine modulare Landschaft (Best-of-Breed / Composable Enterprise)?

Diese Entscheidung ist keine Geschmacksfrage, sondern ein Trade-off zwischen Daten-Konsistenz (Suite) und Innovations-Geschwindigkeit (Best-of-Breed).

2.1 Der Monolith: Der „Walled Garden“ Ansatz

Die klassische ERP-Suite (z.B. SAP S/4HANA, Microsoft Dynamics 365 F&O) verspricht die „Single Source of Truth“ durch eine eng gekoppelte Datenbankarchitektur.

• Vorteil: Prozessuale Integrität. Ein Kundenauftrag im Vertriebsmodul erzeugt in Echtzeit (ACID-konform) eine Buchung im Finanzwesen. Keine Schnittstellen, keine Latenz.
• Sourcing-Nachteil: Sie kaufen den „Vendor Lock-in“ per Design. Wenn das HR-Modul der Suite funktional schwach ist, müssen Sie es dennoch nutzen oder eine teure „Side-Car“-Integration bauen. Innovationen kommen nur so schnell, wie der Release-Zyklus des Herstellers es zulässt.

2.2 Der Aufstieg von „Composable ERP“ und EBC (Enterprise Business Capabilities)

Moderne Sourcing-Strategien folgen dem von Gartner geprägten Begriff des „Composable ERP“. Hierbei wird die Architektur in PBCs (Packaged Business Capabilities) zerlegt. Technisch orientiert sich dies an der MACH-Architektur (Microservices, API-first, Cloud-native, Headless).

Das Ziel: Sie kaufen keinen Supertanker, sondern eine Flotte von Schnellbooten.

• The Core (System of Record): Hier ist Stabilität und Compliance gefragt. Suchen Sie auf https://find-your-erp.de/ nach Systemen, die starke Finanz- und Controlling-Funktionen bieten, aber prozessual „schlank“ bleiben.
• The Specialist (System of Differentiation): Für HR nutzen Sie eine dedizierte Suite (siehe https://find-your-hr.de/), für ESG-Reporting ein Spezialtool (siehe https://find-your-esg.de/). Diese Systeme ändern sich schneller als der Core.

2.3 Die „Integration Tax“: Was Sie technisch sourcen müssen

Wer Best-of-Breed wählt, muss wissen: Integration ist das neue Customizing. Das Sourcing verschiebt sich vom Einkauf von Features hin zum Einkauf von Konnektivität. Ein System ohne API-Reife ist im Composable-Ansatz wertlos („Dead on Arrival“).

Ihr RFP (Request for Proposal) muss folgende technische „Deep-Dives“ beinhalten, um die Integrationsfähigkeit zu validieren:

Technisches Kriterium	Warum Sie danach fragen müssen (The „Gotcha“)
API Coverage & Granularität	Viele Anbieter haben APIs, aber decken diese auch 100% der Business-Logik ab? Fragen Sie: „Gibt es Funktionen in der UI, die nicht via API triggerbar sind?“ (Stichwort: Headless-Fähigkeit).
Event-Driven Architecture (Webhooks/Streaming)	Vermeiden Sie Polling! Ein modernes System muss Events (z.B. „Kunde angelegt“) aktiv publizieren (via Webhooks oder Kafka-Topics). Fragen Sie nach der Event-Latenz.
Rate Limiting & Throttling	Im SaaS-Umfeld oft der Showstopper. Wenn Sie 100.000 Artikelpreise pro Stunde updaten müssen, die API aber nur 1.000 Calls/Minute erlaubt, steht Ihr Betrieb still. Sourcing-Frage: „Können wir dedizierte Throughput-Kapazitäten kaufen?“
Authentifizierung & Security	Akzeptieren Sie kein Basic Auth. Fordern Sie OAuth 2.0 / OIDC Support für Machine-to-Machine (M2M) Kommunikation.

3. Der „Brownfield“-RFP: Was Sie anders fragen müssen

Ein Request for Proposal (RFP) für eine Systemablösung unterscheidet sich drastisch von einem Greenfield-Projekt. Während man auf der grünen Wiese Visionen einkauft, geht es im Brownfield-Szenario um die taktische Extraktion von Business-Logik aus einer verkrusteten Umgebung. Wer hier nur Standard-Feature-Listen abfragt, riskiert, dass das Projekt an der ersten komplexen Datenbanktabelle scheitert.

3.1 Von der „Feature-Checkliste“ zur „Migrations-Methodik“

Fragen Sie im RFP nicht: „Besitzt das System ein Modul für die Lagerverwaltung?“. Fragen Sie stattdessen: „Mit welchen Extraktions-Methoden migrieren Sie eine de-normalisierte DB2-Tabellenstruktur in Ihr relationales (oder Graph-basiertes) Datenmodell, ohne die referenzielle Integrität der historischen Buchungen zu verletzen?“

Kritische Kriterien für den Legacy-Ersatz:

• ETL-Orchestrierung & Konnektivität: Besitzt der Anbieter native Konnektoren (z.B. für SAP IDoc, AS/400 Data Queues oder Datev)? Wenn die Antwort „Wir nutzen Standard-CSV-Imports“ lautet, steigen Ihre Sourcing-Kosten für externe ETL-Middleware (wie Informatica, Talend oder Azure Data Factory) massiv an.
• Deep Fit-Gap-Analyse (Logik-Parität): Legacy-Systeme sind oft über 30 Jahre „hartcodiert“ worden. Diese „versteckte Logik“ (z.B. komplexe Rabattstaffeln im COBOL-Code) wird im Standard-ERP fehlen. Fordern Sie eine technische Code-Analyse oder ein Reverse-Engineering-Audit als Teil der Vorstudie.
• Multi-Stage Data Cleansing: Fordern Sie automatisierte Validierungstools. Ein Partner muss in der Lage sein, während des Migrationsflows (Staging Area) Dubletten-Checks und Format-Harmonisierungen (z.B. Umstellung von 8-stelligen auf 13-stellige Artikelnummern) durchzuführen.
• Historien-Management & Audit-Compliance: Sie müssen nicht alles migrieren, aber Sie müssen alles vorhalten. Fragen Sie nach Cold Storage Architekturen. Kann das neue System auf ein schreibgeschütztes Archiv-Volume zugreifen, um bei einer Betriebsprüfung alte Belege anzuzeigen, ohne die neue Datenbank aufzublähen?

3.2 Datenqualität: „Zero Garbage Strategy“

In Legacy-Systemen finden sich oft Datensätze, die physikalisch vorhanden, aber logisch korrupt sind (z.B. Lieferanten ohne Steuernummer). Ihr RFP muss den Dienstleister verpflichten, eine Data Profiling Phase vorzuschalten.

Sourcing-Tipp: Definieren Sie „Definition of Ready“ (DoR) für Daten. Der Implementierungspartner sollte erst mit der Migration beginnen dürfen, wenn die Datenqualität einen Score von X% (basierend auf Ihren Validierungsregeln) erreicht hat. Dies verhindert teure Nachträge während der Go-Live-Phase.

Thema	Greenfield Frage (Falsch)	Brownfield Frage (Richtig)
Schnittstellen	Haben Sie eine API?	Wie sieht das Error-Handling aus, wenn Ihr System asynchrone Daten von unserem Legacy-Bus empfängt?
Performance	Wie schnell ist das System?	Wie skaliert die Datenbank bei einem Import von 5 Mio. historischen Transaktionsdatensätzen?
Benutzer	Ist die UI intuitiv?	Können Power-User die Tastatur-Shortcuts des Altsystems (z.B. F-Tasten-Mapping) selbst konfigurieren?

4. Vendor Due Diligence: Prüfen Sie die Zukunftsfähigkeit (Beyond the Sales Pitch)

Sie lösen ein Altsystem ab, weil es technologisch zur Sackgasse wurde. Der größte Fehler wäre es, bei der Auswahl nur auf heutige Features zu schauen. In der Vendor Due Diligence für Legacy-Nachfolger müssen Sie wie ein Risikokapitalgeber denken: Ist die Architektur des Anbieters in zehn Jahren noch relevant, oder kaufen Sie gerade den „Legacy-Code von morgen“?

4.1 Der Cloud-Native Acid Test: Architektur-Wahrheit vs. Marketing-Fiktion

Viele Anbieter betreiben „Cloud-Washing“. Sie nehmen ihren monolithischen On-Premise-Code, packen ihn in einen Docker-Container (oder schlimmer: eine VM) und hosten ihn bei AWS. Das ist kein SaaS, das ist „Software-Hosting mit neuem Preisschild“.

Echte Zukunftsfähigkeit erkennen Sie an der 12-Factor-App-Konformität. Stellen Sie im Due-Diligence-Audit diese unbequemen Fragen:

• Statelessness: Ist die Applikationslogik zustandslos? Nur so kann das System bei Lastspitzen (z. B. Jahresabschluss) horizontal skalieren, ohne dass User-Sessions abbrechen.
• Microservices vs. Distributed Monolith: Besteht das System aus unabhängig deploybaren Services? Wenn ein Update des Webshops das gesamte ERP-Backend für Stunden lahmlegt, haben Sie keinen modernen Cloud-Stack gesourct.
• Multi-Tenancy (Echte Mandantenfähigkeit): Teilen sich alle Kunden dieselbe Code-Basis? Wenn der Anbieter sagt „Wir legen für Sie eine eigene Instanz an“, bedeutet das: Sie hängen bei jedem Sicherheits-Patch von manueller Arbeit ab. Das ist ein Skalierungskiller.

4.2 Die „API-Lüge“ entlarven: Granularität ist alles

Jeder Sales-Manager behauptet heute: „Wir haben eine offene API“. Im Brownfield-Kontext ist das oft eine gefährliche Halbwahrheit. Oft sind diese APIs nur „nachgerüstet“ und bieten nur Lesezugriff auf 20 % der Datenfelder.

API-Level	Technischer Standard	Bedeutung für die Legacy-Ablösung
Level 1: CRUD API	Einfaches Create, Read, Update, Delete.	Reicht für Datenexporte, aber nicht für Prozessautomatisierung.
Level 2: Business Logic API	Triggert komplexe Abläufe (z. B. „Rechnung buchen“ inkl. Validierung).	Zwingend notwendig, um alte Workflows aus dem Altsystem zu orchestrieren.
Level 3: Event-Driven / Webhooks	System meldet Statusänderungen aktiv (Push statt Pull).	Ermöglicht Echtzeit-Synchronisation während der hybriden Übergangsphase.

4.3 Die technologische R&D-Quote: Wo fließt Ihr Geld hin?

Ein technisch brillantes System kann scheitern, wenn die Firma dahinter von einer Private-Equity-Gesellschaft „ausgequetscht“ wird. Fragen Sie in der Due Diligence gezielt nach der R&D-Investitionsquote (Forschung & Entwicklung) im Verhältnis zum Marketing-Budget.

Warnsignal: Wenn ein Anbieter mehr für „Branding & Sales“ ausgibt als für die Weiterentwicklung des Kern-Codes, finanzieren Sie lediglich den Exit der Investoren, während Ihre Software technisch verrottet.

4.4 ESG-Compliance: Den „Regulatory Legacy“ vermeiden

Altsysteme scheitern heute massiv an neuen Reporting-Pflichten wie CSRD (Corporate Sustainability Reporting Directive) oder dem Lieferkettengesetz (LkSG). Ein moderner Nachfolger muss diese Daten nativ im Datenmodell führen können.

• Prüfen Sie, ob das System CO2-Äquivalente auf Positionsebene im Einkauf erfassen kann.
• Nutzen Sie Spezial-Datenbanken wie find-your-esg.de, um zu prüfen, ob der Anbieter eine validierte Roadmap für EU-Taxonomie-Reporting besitzt.

5. Die Archäologie der Geschäftslogik: Wissensmanagement & Reverse Engineering

Das größte Risiko bei der Ablösung von Legacy-Systemen ist nicht die Hardware, die im Keller verstaubt. Es ist die implizite Geschäftslogik, die tief im Spaghetti-Code vergraben ist. Wenn die ursprünglichen Entwickler seit 10 Jahren im Ruhestand sind und die Dokumentation den Stand von 2004 widerspiegelt, wird Ihr Sourcing-Projekt zur digitalen Archäologie.

5.1 Die Gefahr der „Forgotten Rules“

In 20 oder 30 Jahren Betrieb wurden unzählige Sonderlocken, Rabattlogiken und Compliance-Regeln direkt in den Code „gehackt“ (Hardcoding). Wer hier blind nach dem Motto „Standard ist Trumpf“ verfährt, merkt erst beim ersten Go-Live-Monatsabschluss, dass 15 % der Sonderfälle nicht mehr abgebildet werden können.

Sourcing-Tipp: Suchen Sie Spezialisten für Software-Intelligenz

Verlangen Sie von Dienstleistern im RFP nicht nur „Prozessberatung“, sondern explizite Reverse Engineering Skills. Ein moderner Partner sollte folgende Werkzeuge und Methoden im Werkzeugkasten haben:

• Statische Code-Analyse (White-Box): Einsatz von Tools, die aus altem COBOL-, RPG- oder ABAP-Z-Code automatisch Flussdiagramme (Control Flow Graphs) und Datenmodell-Abhängigkeiten generieren.
• Dynamic Analysis (Black-Box): Instrumentierung des Altsystems, um im laufenden Betrieb zu messen, welche Programmteile überhaupt noch genutzt werden (Dead Code Elimination).
• Abstract Syntax Trees (AST): Die Fähigkeit, Code in eine sprachneutrale Struktur zu übersetzen, um die Logik für das neue System (z. B. als Microservice in Java oder C#) neu zu modellieren.

---

6. Sourcing des Implementierungspartners (Systemintegrator)

Bei komplexen Ablösungen ist die Software nur 50 % des Erfolgs. Die anderen 50 % liegen beim Implementierungspartner (SI). Ein fataler Fehler: Man kauft die Software direkt beim Hersteller (Vendor) und lässt sich einen Partner „zuweisen“. In der Welt der Legacy-Ablösungen brauchen Sie keine „Software-Installer“, sondern Transformations-Architekten.

6.1 Der Unterschied zwischen Greenfield-Blenden und Brownfield-Sanierern

Ein Partner, der SAP S/4HANA auf der „grünen Wiese“ einführen kann, scheitert oft kläglich an einer Brownfield-Migration von einem 20 Jahre alten Microsoft Navision oder einer AS/400. Warum? Weil Greenfield-Partner gewohnt sind, dass der Kunde seine Daten „sauber anliefert“.

Ihr RFP für den Implementierungspartner muss diese spezifischen Brownfield-KPIs abfragen:

Sourcing-Kriterium	Was Sie prüfen müssen	Das „K.O.“ Kriterium
Extraktions-Kompetenz	Hat der Partner eigene Scripts oder Middleware, um Daten direkt aus der DB2/Oracle/SQL-Legacy-Datenbank zu ziehen?	„Wir benötigen von Ihnen flache Excel-Listen zum Import.“ (Finger weg!)
Hybrid-Betrieb-Erfahrung	Kann der Partner Schnittstellen bauen, die das alte und neue System für 12 Monate synchron halten?	Der Partner drängt auf einen „Big Bang“ ohne Fallback-Option.
Branchen-Tiefe vs. Tool-Wissen	Versteht der Berater Ihre Branche oder klickt er nur im System herum?	Die Berater-Lebensläufe zeigen nur Junior-Level ohne Legacy-Erfahrung.

6.2 Die „Shadow-IT“ Detektive

Ein exzellenter Integrationspartner fragt im Erstgespräch nicht nach Ihren Anforderungen, sondern nach Ihren Excel-Listen. In Jahrzehnten mit Legacy-Software haben Fachabteilungen oft riesige Schatten-Systeme gebaut, um funktionale Lücken zu füllen. Ein guter Partner sourct diese „Satelliten“ mit ein und integriert sie in die neue Architektur, statt sie zu ignorieren.

Strategischer Sourcing-Rat: Trennen Sie die Software-Lizenz-Verhandlung von der Dienstleistungs-Ausschreibung. Ein Partner, der Ihnen die Software „besonders günstig“ verkauft, holt sich die Marge oft über teure Change Requests während der komplexen Datenmigration wieder zurück.

7. Vertragliche Absicherung: Der Exit vom Exit – Souveränität in der Cloud

Wenn Sie heute einen SaaS-Vertrag unterschreiben, planen Sie bereits die Scheidung. Das klingt paradox, ist aber im strategischen Sourcing überlebenswichtig. Nichts ist gefährlicher, als den Mainframe-Lock-in der 90er Jahre gegen einen Cloud-Lock-in der 2020er zu tauschen, bei dem Ihre Daten zwar „modern“ liegen, Sie aber die Kontrolle über Kosten und Portabilität verlieren.

7.1 Datenhoheit & technische Portabilität: Jenseits von PDF-Exports

Verlassen Sie sich nicht auf vage Zusagen wie „Ihre Daten gehören Ihnen“. Im Falle eines Systemwechsels oder einer Insolvenz des Anbieters benötigen Sie technische Souveränität. Basierend auf der Norm ISO/IEC 19086 (Cloud Service Level Agreements) müssen folgende Punkte fixiert werden:

• Maschinenlesbarkeit & Granularität: Der Anbieter muss vertraglich zusichern, dass Datenexporte in einem relationalen oder semantisch strukturierten Standardformat (z. B. Parquet, JSON, Avro oder SQL-Dump) erfolgen – und zwar inklusive der Metadaten und Feldbeziehungen. Ein bloßer CSV-Export ohne Erläuterung der Tabellenverknüpfungen ist wertlos.
• API-basierte Extraktion: Bestehen Sie auf eine Klausel, die den unbegrenzten Bulk-Export via API ohne zusätzliche „Extraktions-Gebühren“ erlaubt. Verweisen Sie explizit auf Art. 20 DSGVO (Recht auf Datenübertragbarkeit), erweitern Sie diesen aber vertraglich auf alle geschäftskritischen (nicht nur personenbezogenen) Daten.
• Logik-Dokumentation: Fordern Sie, dass auch im System hinterlegte Formeln, Workflows und Konfigurationen (Infrastructure as Code) exportierbar oder zumindest dokumentiert übergeben werden müssen.

7.2 Preismodell-Garantie: Den „Honeymoon-Effekt“ verhindern

Cloud-Anbieter nutzen oft aggressive Einstiegspreise. Sobald Ihre Prozesse jedoch tief im System verwurzelt sind (nach ca. 3 Jahren), steigen die Preise bei Vertragsverlängerung sprunghaft an.

Sourcing-Strategie: Fixieren Sie Price Caps. Vereinbaren Sie, dass zukünftige Preiserhöhungen an objektive Indizes gekoppelt sind (z. B. den Verbraucherpreisindex oder den Index für IT-Dienstleistungen) und eine Obergrenze von beispielsweise $3\%$ bis $5\%$ pro Jahr nicht überschreiten dürfen.

7.3 Die Zeit der zwei Welten: Hybride Betriebsphasen & Synchronisation

Ein „Big Bang“-Go-Live ist bei Legacy-Systemen oft ein Himmelfahrtskommando. In der Realität werden Alt und Neu über Monate parallel betrieben (Koexistenzphase). Dies erfordert eine Interims-Architektur.

Ihr Sourcing-Projekt muss die bi-direktionale Synchronisation abdecken:

• Middleware-Sourcing: Kaufen Sie nicht nur das ERP, sondern auch die „Brücke“. Ob iPaaS (Integration Platform as a Service) oder ein Custom-ETL-Layer – die Synchronisations-Middleware muss Delta-Loads beherrschen, um Dateninkonsistenzen zu vermeiden.
• Single Source of Truth (SSoT) Definition: Legen Sie für jede Übergangsphase fest, welches System für welche Datenhoheit verantwortlich ist. Beispiel: Während der Migration bleibt die AS/400 das SSoT für Lagerbestände, während das neue CRM bereits die SSoT für Kundenstammdaten ist.
• Transition Support & Read-Only Zugriff: Vereinbaren Sie eine „Transition Period“ von mindestens 6-12 Monaten nach Kündigung des Altsystems. In dieser Zeit muss das Altsystem im kostengünstigen Read-Only-Modus verfügbar bleiben (Cold Storage), um historische Anfragen oder Audits ohne Datenmigration abwickeln zu können.

7.4 Use Case: HR-Transformation im Mittelstand (Best-of-Breed Architektur)

Checkliste für das Vertrag-Audit:

1. Exit-Unterstützung: Ist der Anbieter verpflichtet, beim Auszug aktiv zu helfen? Zu welchem Stundensatz?
2. Daten-Herausgabe: In welcher Zeitspanne nach Vertragsende müssen die Daten final gelöscht oder übergeben werden?
3. Abhängigkeiten: Erfordert das neue System proprietäre Drittanbieter-Lizenzen, die Sie separat sourcen müssen?

8. Change Management als Sourcing-Bestandteil: Das „Legacy-Stockholm-Syndrom“ überwinden

Unterschätzen Sie niemals die emotionale Bindung eines Power-Users an seinen „Green Screen“. In Jahrzehnten mit Legacy-Systemen haben Mitarbeiter eine Meisterschaft in der Bedienung von Ineffizienz entwickelt. Sie kennen jeden kryptischen Shortcut auswendig und ziehen ihren Expertenstatus daraus, das System trotz seiner Macken zu beherrschen. Ein neues, modernes System bedroht diesen Status.

8.1 Die Psychologie des Wechsels: Warum „Besser“ sich oft „Schlechter“ anfühlt

Ein neues ERP oder CRM ist am ersten Tag für den Anwender immer langsamer. Während er in der AS/400 blind F3-Enter-Tab-F12 drückte, um einen Auftrag anzulegen, muss er nun mit der Maus navigieren, Dropdowns suchen und validierte Pflichtfelder ausfüllen.

Wenn Sie Change Management nicht als festen Bestandteil sourcen, riskieren Sie den „Silent Boycott“: Die Nutzer arbeiten weiterhin in ihren alten Excel-Schattenkopien, und Ihr teures neues System wird zur Datenwüste.

8.2 Sourcing-Anforderungen an das Change Management

Change Management ist kein „Workshop mit bunten Post-its“. Es ist eine prozessbegleitende Dienstleistung, die Sie im RFP messbar machen müssen. Fordern Sie von Ihrem Implementierungspartner:

• UI-Mapping & Ergonomie-Coaching: Der Partner muss zeigen, wie die hocheffizienten (wenn auch hässlichen) Workflows der alten Welt in moderne Oberflächen übersetzt werden, ohne die Klickrate zu verfünffachen.
• Multi-Channel Training: Kaufen Sie nicht nur PDF-Handbücher. Sourcen Sie interaktive In-App-Guidance-Tools (z. B. WalkMe, Userlane), die den Nutzer direkt im neuen System führen („Digital Adoption Platforms“).
• Stakeholder-Matrix: Der Dienstleister muss die informellen Meinungsführer in den Abteilungen identifizieren. Wenn der dienstälteste Lagermeister das neue System ablehnt, wird es das gesamte Team tun.

8.3 Hyper-Care & Floor Walking: Die kritische Phase Null

Planen Sie bei der Budgetierung (Lizenzen vs. Dienstleistung) eine „Hyper-Care-Phase“ ein. Das bedeutet: In den ersten zwei Wochen nach dem Go-Live stehen Berater physisch neben den Anwendern („Floor Walking“).

Maßnahme	Sourcing-Quote	Das Ziel
Key-User Enablement	20% des Dienstleistungsbudgets	Ausbildung interner Multiplikatoren, die den First-Level-Support selbst leisten können.
Floor Walking	Fixpreis pro Standort	Sofortige Angstlinderung beim Go-Live. Keine Ticket-Staus in der IT.
Gamification / Incentives	Variabel	Belohnung für die erste fehlerfreie Datenpflege oder den vollständigen Umzug aus Excel.

8.4 Die „Schleusenwärter“ des Wissens

Legacy-Ablösungen sind oft Generationen-Projekte. Sourcing bedeutet hier auch: Wissenstransfer-Sicherung. Stellen Sie vertraglich sicher, dass der Implementierungspartner die Dokumentation nicht für die IT schreibt, sondern für die Fachabteilung. Ein technisches Architekturdiagramm hilft dem Sachbearbeiter nicht, wenn er nicht weiß, wie er eine Gutschrift im neuen System korrigiert.

Fazit für das Sourcing: Rechnen Sie mit einem Change-Budget von 10-15 % der Gesamtprojektkosten. Ein technisch perfektes System, das von den Nutzern gehasst wird, hat einen ROI von Null. Sourcen Sie Akzeptanz, nicht nur Software.

Fazit: Evolution statt Revolution

Die Ablösung von Legacy-Systemen ist kein reines IT-Projekt, sondern eine Unternehmenssanierung. Die richtige Sourcing-Strategie bewertet nicht nur den Preis der neuen Software, sondern die „Total Cost of Migration“ – inklusive Datenbereinigung, Prozessanpassung und Change Management.

Seien Sie mutig beim Zerschneiden alter Monolithen und vorsichtig beim Unterschreiben neuer Cloud-Verträge. Die Zukunft der IT ist modular. Beginnen Sie Ihre Reise zur Modernisierung mit einer fundierten Marktanalyse. Nutzen Sie https://find-your-software.de als Kompass im Dschungel der Anbieter, um die Bausteine zu finden, die Ihre digitale Architektur für das nächste Jahrzehnt tragen.

FAQ: Experten-Wissen zur Legacy-Ablösung

Was ist der präzise Unterschied zwischen „Greenfield“, „Brownfield“ und „Selective Data Transition“?

Greenfield: Ein radikaler Neuanfang. Sie ignorieren alte Prozesse und setzen das System „Out-of-the-box“ nach Best Practices auf. Ideal, wenn Ihre aktuellen Prozesse völlig veraltet sind. Risiko: Hoher Change-Management-Aufwand.

Brownfield: Eine technische Konvertierung. Das Ziel ist die Mitnahme der gesamten Historie und Prozesslogik in eine moderne Umgebung. Ideal für hochgradig spezialisierte Industrien. Risiko: Sie schleppen „Müll“ aus 20 Jahren mit umher.

Selective Data Transition (Bluefield): Der Königsweg. Sie bauen ein neues System (Greenfield-Ansatz), migrieren aber gezielt komplexe Stamm- und Bewegungsdaten sowie historische Belege der letzten X Jahre. Dies minimiert das Risiko und maximiert die Modernisierung.

Wie verhindere ich technisch einen „Cloud-Lock-in“ beim Sourcing?

Ein Lock-in entsteht heute weniger durch die Software, sondern durch die Daten-Gravitation und proprietäre Logik. Achten Sie auf drei Faktoren:

• Exit-Code: Können Sie Ihre Geschäftslogik (z.B. Workflows) exportieren, oder ist diese in einer herstellerspezifischen Sprache (wie Apex oder ABAP) gefangen?
• Data Egress: Prüfen Sie die Kosten für den massiven Datenabzug. Manche Cloud-Anbieter machen den Einzug kostenlos, berechnen aber horrende Gebühren für den Export (Egress Fees).
• Open Standards: Bestehen Sie auf Schnittstellen nach dem OpenAPI-Standard (Swagger) und Identitätsmanagement via OIDC/SAML.

Wie berechne ich den ROI, wenn das Altsystem eigentlich „abbezahlt“ ist?

Das Altsystem ist eine tickende Zeitbombe mit negativer Verzinsung. Berechnen Sie den ROI über die Total Cost of Inaction (COI):

• Risikokosten: Wahrscheinlichkeit eines Systemausfalls x Kosten pro Ausfallstunde (Produktionsstopp).
• Opportunitätskosten: Umsatzverlust durch fehlende Time-to-Market (z.B. weil der neue Webshop nicht angebunden werden kann).
• Schatten-IT Kosten: Zeitaufwand der Mitarbeiter für manuelle Excel-Workarounds, um Legacy-Lücken zu füllen.
• Security-Premium: Zusatzkosten für isolierte Netzwerke und Spezial-Support für End-of-Life Betriebssysteme.

Was ist die größte Gefahr in der Koexistenzphase (Alt und Neu parallel)?

Die Daten-Inkonsistenz. Wenn ein Kundenstammsatz im neuen CRM geändert wird, das alte ERP im Lager aber noch die alte Adresse hat, bricht die Logistik zusammen. Sie benötigen eine klare Synchronisations-Strategie (Master Data Management). Definieren Sie für jedes Datenfeld während der Übergangsphase genau ein „führendes System“.