In vielen mittelständischen Unternehmen läuft das zentrale ERP seit Jahren zuverlässig, aber nur solange niemand zu tief hineinschaut. Schnittstellen sind historisch gewachsen, Dokumentation fehlt, einzelne Abläufe hängen an einer Handvoll Spezialisten. Gleichzeitig steigen Wartungsaufwand, Sicherheitsanforderungen und der Druck, Daten mit modernen Anwendungen, SaaS-Diensten oder einer EU-Only-Cloud zu verbinden.
Nach 19 Jahren in Migrationsprojekten sehe ich immer wieder dasselbe Muster: Nicht der technische Umzug allein entscheidet über den Erfolg. Entscheidend sind Bestandskenntnis, fachliche Priorisierung, Datenqualität, Parallelbetrieb, Archivierung und ein belastbarer Rückfallplan. Wer nur „Lift-and-Shift“ plant, verschiebt viele Probleme in eine neue Umgebung. Wer Migration als Geschäftsprojekt mit klarer Governance behandelt, schafft dagegen eine kontrollierbare Grundlage für Betrieb und Weiterentwicklung.
Inhaltsverzeichnis
- Warum Legacy System Migration jetzt unvermeidbar wird
- Assessment und Priorisierung des Bestands richtig durchführen
- Migrationsstrategien im Vergleich und richtig auswählen
- Datenmigration und Architekturentscheidungen sicher gestalten
- Test Rollout und Risiko Management in der Praxis
- Fazit und nächste Schritte für deine Legacy System Migration
Warum Legacy System Migration jetzt unvermeidbar wird
Montagmorgen in einem typischen mittelständischen Produktionsunternehmen. Das ERP ist ungefähr 10 Jahre alt, die Kernprozesse funktionieren, und trotzdem wartet die Einkaufsabteilung auf eine kleine Anpassung, die seit Monaten auf der Liste steht. Der Entwickler, der den relevanten Cobol- oder proprietären Code noch versteht, arbeitet inzwischen nur noch tageweise. Für eine neue Kundenplattform wird eine Schnittstelle benötigt, doch das alte System exportiert Daten in einem Format, das niemand sauber dokumentiert hat.
Die Geschäftsführung sieht zunächst keinen zwingenden Grund für eine Migration. Schließlich läuft das System. In der Praxis entstehen die Kosten aber nicht nur durch Lizenz- oder Hostinggebühren. Sie liegen in manuellen Umgehungslösungen, verlängerten Release-Zyklen, Spezialwissen, schwer planbaren Wartungsfenstern und der Tatsache, dass jede Änderung an einer unbekannten Abhängigkeit einen weiteren Prozess gefährden kann.
Der Druck im deutschen Markt
Die Studie zur Legacy-Modernisierung 2024 beschreibt die Lage deutlich. 72 Prozent der befragten Unternehmen und Organisationen müssen geschäftskritische Bestandssysteme modernisieren, während 56 Prozent weiterhin Mainframes und Midrange-Systeme einsetzen. 46 Prozent nennen hohe Betriebskosten, und über 40 Prozent berichten von Einschränkungen für ihre Geschäftsaktivitäten.
Das Problem ist damit nicht auf einzelne überalterte Server begrenzt. Eine frühere deutsche Untersuchung zur IT-Modernisierung zeigt, dass rund 60 Prozent der Befragten bereits in großem oder sehr großem Umfang Anwendungen und Prozesse modernisiert hatten. Gleichzeitig betrieben 36 Prozent der Mittelständler Legacy-Systeme ohne aktuelle Alternative. 60 Prozent bestätigten höhere Betriebs- und Wartungskosten als bei aktuellen Anwendungen.
Die Signale für Handlungsbedarf
Ein System muss nicht erst ausfallen, bevor eine Migration sinnvoll wird. In Projekten achte ich besonders auf diese Anzeichen:
- Abhängigkeit von Einzelpersonen: Nur wenige Mitarbeitende kennen Datenmodell, Batch-Verarbeitung und Sonderlogik.
- Manuelle Nebenprozesse: Fachbereiche übertragen Daten per Tabellenkalkulation oder E-Mail, weil Standardintegrationen fehlen.
- Blockierte Produktentwicklung: Jede neue Funktion erfordert Eingriffe in einen monolithischen Kern.
- Unklare Sicherheitslage: Betriebssysteme, Bibliotheken oder Datenbankkomponenten lassen sich nur schwer aktuell halten.
- Fehlende Cloud-Fähigkeit: Das System kann nicht sauber mit einer souveränen, EU-basierten Infrastruktur verbunden werden.
- Ungeklärte Abschaltung: Niemand weiss, welche Daten nach dem Cutover noch benötigt werden und wie Nachweise erbracht werden.
Aufschieben wirkt kurzfristig bequem, verlagert die Entscheidung aber in eine schlechter kontrollierbare Situation. Eine geplante Migration erlaubt Sequenzierung, Wissenstransfer und Parallelbetrieb. Eine Migration nach einem Ausfall wird meist von Zeitdruck, fehlenden Alternativen und unvollständiger Dokumentation bestimmt.
Assessment und Priorisierung des Bestands richtig durchführen
Eine belastbare Legacy-System-Migration beginnt mit einer Bestandsaufnahme, nicht mit der Auswahl eines Cloud-Anbieters. Der erste Schritt ist ein vollständiges Inventar aller Anwendungen, Datenbanken, Dateischnittstellen, Batch-Jobs, Benutzergruppen und externen Abhängigkeiten. Dabei reicht es nicht, den offiziellen Applikationskatalog zu übernehmen. Gerade kritische Prozesse laufen oft über alte Exportdateien, lokale Skripte oder Schnittstellen, die nie in der Architektur dokumentiert wurden.
Ich erfasse pro System mindestens fachlichen Zweck, verantwortliche Abteilung, technische Plattform, Datenarten, Integrationen, Betriebszeiten, Wiederanlaufanforderungen und vorhandene Ansprechpartner. Danach folgt die Abhängigkeitsanalyse. Ein ERP-Modul, das isoliert aussieht, kann über Nachtverarbeitung, Druckstrecken oder eine alte Lageranbindung eng mit mehreren Bereichen verbunden sein.
Drei Blickwinkel für die Priorisierung
Business-Kritikalität steht an erster Stelle. Ein System für interne Auswertungen kann technisch veraltet sein, aber ein Auftragseingangs- oder Produktionssystem hat eine andere Risikoklasse. Ich bewerte deshalb, welche Prozesse bei einem Ausfall stehen, welche Kunden oder Lieferanten betroffen wären und ob ein manueller Ersatz realistisch ist.
Technisches Risiko bildet die zweite Achse. Dazu zählen nicht unterstützte Komponenten, schwer testbare Eigenentwicklungen, unklare Datenflüsse und fehlende Spezialisten. Ein kleines System mit hoher Abhängigkeit von einer Einzelperson kann riskanter sein als eine grössere, gut dokumentierte Anwendung.
Compliance und Datenhaltung bilden die dritte Achse. Personenbezogene Daten, steuerlich relevante Buchungen und geschäftliche Nachweise benötigen eine andere Behandlung als temporäre Cache-Daten. Schon vor der Zielarchitektur muss feststehen, was migriert, archiviert, anonymisiert oder kontrolliert gelöscht werden darf.
Praktische Regel: Priorisiere nicht nach Alter allein. Priorisiere nach Geschäftsfolgen, technischer Verwundbarkeit und rechtlicher Bindung.
Ein mittelständisches Beispiel
Bei einem Unternehmen wie Küstermann Media würde ich die Arbeit sequenziell aufbauen: zuerst Inventar und Abhängigkeiten, danach Bewertung der Geschäftsprozesse, dann Zielplattform und Migrationsreihenfolge. Ein Webportal mit klarer API kann früh entkoppelt werden. Ein Kernmodul mit historischer Finanzlogik benötigt dagegen zunächst Tests, Datenmapping und eine definierte Archivierungsstrategie.
Die aktuelle Marktanalyse zeigt, dass 49 Prozent der befragten Firmen Dienstleister in ihre Modernisierung einbinden und 63 Prozent eine Private Cloud als Zielplattform nennen, wie die Einordnung zur Legacy-Modernisierung berichtet. Externe Unterstützung ersetzt dabei nicht die Verantwortung des Unternehmens. Sie hilft vor allem, blinde Flecken zu reduzieren, Abhängigkeiten sichtbar zu machen und eine realistische Reihenfolge zu entwickeln.
Am Ende des Assessments sollte jede Anwendung einem klaren Cluster zugeordnet sein:
- Ablösen: Funktion wird durch eine neue Lösung ersetzt.
- Schrittweise modernisieren: Wertvoller Kern bleibt vorerst bestehen, Schnittstellen und Module werden entkoppelt.
- Technisch verlagern: Anwendung bleibt weitgehend unverändert, wird aber auf eine kontrollierbare Zielplattform gebracht.
- Archivieren oder stilllegen: Daten bleiben nachweisbar verfügbar, der aktive Betrieb endet.
Diese Einteilung ist keine endgültige Architekturentscheidung. Sie ist ein belastbares Arbeitsmodell, das Budget, Verantwortlichkeiten und Migrationswellen begründet.
Migrationsstrategien im Vergleich und richtig auswählen
Ein mittelständischer Betrieb in Münster muss ein altes Kernsystem ablösen, darf den laufenden Auftragseingang aber nicht unterbrechen. Gleichzeitig verlangt der Datenschutz eine EU-Only-Cloud, während Aufbewahrungspflichten den Zugriff auf historische Vorgänge sichern. In solchen Projekten entscheidet nicht die modernste Methode, sondern die Kombination aus Betriebsrisiko, Kopplungen, Datenresidenz und verfügbarem Zeitfenster.
| Strategie | Ideal für | Aufwand und Risiko | EU-Cloud-Eignung |
|---|---|---|---|
| Strangler Pattern | Monolithen mit klar abgrenzbaren Modulen | Schrittweise, gut kontrollierbar, aber mit temporärer Doppelarchitektur | Hoch, wenn neue Dienste auf EU-Only-Infrastruktur betrieben werden |
| Replatforming | Systeme, deren Fachlogik erhalten bleiben soll | Mittlerer Aufwand, technische Altlasten bleiben teilweise bestehen | Gut, sofern Zielplattform, Verträge und Datenflüsse geprüft sind |
| Lift-and-Shift | Zeitkritische Verlagerung ohne sofortige funktionale Änderung | Niedrigerer initialer Eingriff, aber Risiken und Kosten können unverändert bleiben | Abhängig vom Cloud-Modell und der Datenverarbeitung |
| Refactoring | Wertvolle Anwendung mit modernisierbarem Code | Hoher Analyse- und Testaufwand, dafür bessere Wartbarkeit | Sehr gut, wenn Architektur und Betriebsmodell neu gestaltet werden |
| Composable Architecture | Häufig veränderte Prozesse und modulare Produktlandschaften | Anspruchsvoll in Integration und Governance, flexibel in der Weiterentwicklung | Gut, wenn jedes Modul eigene Datenschutz- und Betriebsanforderungen erfüllt |
Strangler Pattern für sensible Kernprozesse
Beim Strangler Pattern läuft die neue Lösung zunächst neben dem Altsystem. Ein klar abgegrenzter Prozess, etwa die Preislistenverwaltung oder ein Kundenportal, wird zuerst umgesetzt. Eine Routing- oder API-Schicht verteilt die Anfragen. Nach stabilen Tests und einem kontrollierten Parallelbetrieb kann die alte Funktion abgeschaltet werden.
Für DSGVO-relevante Prozesse bietet dieses Vorgehen einen praktischen Vorteil: Das Unternehmen kann Datenflüsse, Zugriffsrechte und Speicherorte je Domäne prüfen, bevor weitere Bereiche umziehen. Die neue Komponente muss dabei tatsächlich auf einer EU-Only-Infrastruktur betrieben werden. Supportzugriffe, Backups, Protokolle und Unterauftragnehmer gehören ebenfalls in die Prüfung.
Das Muster scheitert, wenn alte Module direkt auf dieselben Tabellen zugreifen oder fachliche Grenzen fehlen. Dann entstehen widersprüchliche Datenstände und eine zweite, schwer verständliche Betriebsarchitektur. Vor dem Start braucht das Team deshalb klare Verantwortlichkeiten, eine definierte Synchronisation und einen Plan für die Abschaltung.
Replatforming und Lift-and-Shift
Replatforming verschiebt die Anwendung auf eine modernere Laufzeit oder Infrastruktur, ohne die gesamte Fachlogik neu zu schreiben. Das passt zu stabilem Code, wenn Hardware, Betriebssystem oder der bisherige Rechenzentrumsbetrieb zum Problem werden. Schlechte Schnittstellen, unklare Berechtigungen und ineffiziente Datenmodelle bleiben jedoch erhalten.
Lift-and-Shift kann ein begrenztes Zeitfenster schließen, etwa wenn eine veraltete Betriebsumgebung kurzfristig ersetzt werden muss. Für die langfristige Modernisierung reicht es selten. Vorher sind Cloud-Modell, Datenverarbeitung, Unterauftragnehmer und Speicherorte von Backups und Logs zu dokumentieren. Bei Archivierungspflichten muss außerdem feststehen, wie historische Daten lesbar und nachweisbar verfügbar bleiben.
Für standardisierte Übergaben bei einem Geräte- oder Arbeitsplatzwechsel kann die Anleitung zum Move Pro ergänzend hilfreich sein. Sie ersetzt keine Architekturplanung, macht aber Prüfschritte und Verantwortlichkeiten greifbar.
Für die Vorbereitung von Integrationen und Ablösungen bietet Integrationen und Migrationen für Unternehmen in Münster und NRW einen passenden Praxisbezug. Nicht die modernste Strategie zählt, sondern eine, deren Risiken, Parallelbetrieb und rechtliche Pflichten das Unternehmen kontrollieren kann.
Datenmigration und Architekturentscheidungen sicher gestalten
Datenmigration scheitert selten an einem einzelnen Kopiervorgang. Sie scheitert an unklaren Bedeutungen. Im alten System kann ein Statusfeld je nach Modul etwas anderes bedeuten, Kundennummern können mehrfach vergeben sein, und historische Datensätze enthalten möglicherweise fehlende oder widersprüchliche Werte.
Der Prozess beginnt deshalb mit einer Dateninventur. Für jede Tabelle oder Datei werden Eigentümer, Zweck, Datenqualität, Aufbewahrung, Zugriffskreis und Zielverwendung dokumentiert. Erst danach entsteht das Mapping zwischen Quell- und Zielmodell. Ein Feld wird nicht übernommen, weil es existiert, sondern weil seine fachliche Bedeutung, sein Zweck und seine rechtliche Behandlung geklärt sind.
Der Ablauf von der Quelle bis zum Cutover
- Profiling: Wertebereiche, Dubletten, Pflichtfelder und historische Sonderfälle sichtbar machen.
- Cleansing: Fachlich verantwortete Regeln für Bereinigung und Vereinheitlichung definieren.
- Mapping: Quellfelder, Zielattribute, Transformationen und Ausnahmen dokumentieren.
- ETL oder API-Übertragung: Extraktion, Transformation und Laden wiederholbar automatisieren.
- Validierung: Summen, Datensatzanzahl, Referenzen und fachliche Stichproben vergleichen.
- Delta-Lauf: Änderungen seit der ersten Übernahme erfassen und kurz vor dem Cutover nachladen.
- Abnahme: Fachbereich und IT bestätigen gemeinsam, dass Daten vollständig und nutzbar sind.
Bei personenbezogenen Daten kommt die Datenschutzperspektive hinzu. Eine DSGVO-konforme Zielarchitektur braucht klare Zwecke, Rollen, Löschkonzepte, Protokollierung und kontrollierte Zugriffe. EU-Only bedeutet dabei mehr als einen Serverstandort in Europa. Verträge, Supportzugriffe, Subunternehmer, Backup-Orte und Administrationswege müssen zum gewünschten Souveränitätsmodell passen.
Was mit Altanwendungen und historischen Daten passiert
Ein mittelständisches Handelsunternehmen muss nach dem Cutover nicht jede historische Buchung in die neue ERP-Datenbank übertragen. Aktive Kunden, offene Vorgänge und für laufende Prozesse benötigte Stammdaten werden selektiv übernommen. Abgeschlossene Geschäftsjahre können in ein revisionssicheres Archiv überführt werden, während die Altanwendung in einem kontrollierten Read-only-Betrieb nur noch für Nachfragen und Prüfungen erreichbar bleibt.
Die rechtliche Bewertung muss das Unternehmen mit Steuerberatung, Rechtsabteilung oder Datenschutzverantwortlichen klären. Für Deutschland sind insbesondere handelsrechtliche und steuerliche Aufbewahrungspflichten relevant. Eine fachlich saubere Lösung trennt daher aktive Verarbeitung, Archivzugriff und Löschung, statt das alte System aus Bequemlichkeit dauerhaft vollständig weiterzubetreiben.
Für die Gestaltung der Zielkomponenten, API-Schichten und Betriebsgrenzen kann eine Beratung zur Software-Architektur in Münster und NRW sinnvoll sein. Microservices sind dabei kein Pflichtziel. Ein modularer Monolith mit sauber definierten Schnittstellen kann für ein mittelständisches Unternehmen wartbarer und betrieblich überschaubarer sein.
Test Rollout und Risiko Management in der Praxis
Ein mittelständischer Händler steht am Freitag vor dem ERP-Cutover. Bestellungen laufen weiter, das alte System muss für Rückfragen erreichbar bleiben, und die neue Lösung darf keine Buchung verlieren. Ein Go-Live ist deshalb kein einzelner Termin, sondern eine Folge überprüfbarer Entscheidungen. Die Absicherung reicht von technischen Tests bis zur Freigabe durch Fachbereich, Betrieb, Datenschutz und Notfallorganisation.
Teststufen mit klarer Verantwortlichkeit
Unit-Tests prüfen einzelne Funktionen und Transformationen, besonders bei Preis-, Steuer-, Status- und Berechtigungslogik. Integrationstests prüfen die Verbindungen zwischen ERP, Shop, Lager, Zahlungsdienst und Reporting. Danach folgen fachliche Prozesstests, in denen Anwender einen vollständigen Auftrag oder Monatsabschluss durchführen.
Performance- und Lasttests müssen reale Spitzen abbilden. Ein System kann mit wenigen Datensätzen stabil wirken und beim Monatsabschluss trotzdem an Datenbankabfragen, Batch-Jobs oder Schnittstellenlimits scheitern. Jede Teststufe braucht einen Verantwortlichen, definierte Eingangsdaten, erwartete Ergebnisse und eine dokumentierte Entscheidung bei Abweichungen.
Die Success Stories von Küstermann Media zeigen unterschiedliche digitale Vorhaben aus der Praxis. Für eine Migration zählt daran vor allem, ob Vorgehen, Dokumentation und Betriebsverantwortung auf die eigene Organisation übertragbar sind.
Parallelbetrieb statt blindem Umschalten
Bei geschäftskritischen Prozessen reduziert ein kontrollierter Parallelbetrieb das Risiko. Das alte System verarbeitet weiterhin produktiv, während die neue Lösung dieselben oder gezielt nachgebildete Vorgänge verarbeitet. Abweichungen werden technisch und fachlich bewertet. Ursachen liegen häufig in Rundungen, Statuslogik oder geänderten Stammdatenregeln.
Der Parallelbetrieb braucht ein Enddatum und Abschaltkriterien. Sonst bleibt die Übergangsarchitektur bestehen und erhöht den Betriebsaufwand. Für den Cutover müssen Teams Buchungsstopp, Delta-Lauf, Freigabe und Rollback-Bedingungen festlegen.
Rollback ist kein Zeichen mangelnden Vertrauens. Es ermöglicht, eine riskante Änderung kontrolliert zurückzunehmen.
Blue-Green-Deployment vereinfacht den technischen Umschaltpunkt. Die neue Umgebung wird vorbereitet, geprüft und erst danach aktiviert. Für Webanwendungen und APIs funktioniert das häufig gut. Bei zustandsbehafteten ERP-Prozessen müssen zusätzlich Datenkonsistenz, offene Transaktionen und externe Schnittstellen geregelt werden.
EU-Only-Betrieb und Risikoregister
In unseren Migrationsprojekten wählen Mittelständler häufig Private-Cloud-Modelle, weil Datenhoheit und kontrollierte Administration Vorrang haben. Für eine DSGVO-konforme und EU-Only-Architektur genügt das Etikett jedoch nicht. Datenflüsse, Supportzugriffe, Subunternehmer, Backup-Orte und Administrationswege müssen zum Souveränitätsmodell passen. Parallelbetrieb und Archivzugriffe gehören ebenfalls in die Prüfung, wenn Nachweis- und Aufbewahrungspflichten den Abschalttermin des Altsystems bestimmen.
Für den Rollout führe ich ein Risikoregister mit Eintrittsbedingung, Auswirkung, Verantwortlichem, Gegenmaßnahme und Rückfalloption. Kritisch sind fehlende Daten, nicht erreichbare Schnittstellen, falsche Berechtigungen, unvollständige Archivzugriffe und unklare Kommunikation. Erst wenn Tests oder verbindliche Verantwortungszusagen diese Punkte abdecken, ist der Cutover entscheidungsreif.
Fazit und nächste Schritte für deine Legacy System Migration
Eine erfolgreiche Legacy-System-Migration ist keine reine Ablösung alter Technologie. Sie ist eine kontrollierte Neuordnung von Geschäftslogik, Daten, Verantwortlichkeiten und Betrieb. Das Ziel besteht nicht darin, möglichst schnell aus dem alten Rechenzentrum herauszukommen. Das Ziel ist ein System, das fachlich belastbar, wartbar, integrierbar und unter den eigenen Datenschutzanforderungen betreibbar ist.
Für die Entscheidung helfen drei konkrete Schritte:
- Bestand in ein belastbares Bild bringen: Inventarisiere Anwendungen, Daten, Schnittstellen, Verantwortliche und rechtliche Bindungen. Markiere Systeme, deren Ausfall Geschäftsbetrieb oder Nachweispflichten unmittelbar berühren würde.
- Migrationswelle begründen: Entscheide pro System zwischen Ablösung, schrittweiser Modernisierung, Replatforming und Archivierung. Dokumentiere, warum eine Anwendung zuerst oder bewusst später migriert wird.
- Pilot mit Rückfalloption starten: Wähle einen abgegrenzten Prozess, baue Datenmapping und Tests auf, betreibe alte und neue Lösung kontrolliert parallel und definiere den Cutover einschliesslich Rollback.
Typische Fehler sind ein unvollständiges Assessment, ein ungeprüftes Lift-and-Shift, die Übernahme historischer Daten ohne Zweck und ein Parallelbetrieb ohne Abschaltkriterien. Ebenso problematisch ist es, Fachanwender erst am Ende einzubeziehen. Bei organisatorischen Veränderungen können Workshops zur Veränderung helfen, Rollen, Erwartungen und Arbeitsweisen früh zu klären.
Küstermann Media GmbH begleitet Unternehmen technologieoffen von Architektur und Datenmigration bis zu Integrationen, EU-Only-Infrastruktur und laufendem Betrieb. Die Arbeit reicht von Webanwendungen und SaaS-Lösungen bis zu Open-Source-ERP, CRM und SEO-relevanten Systemwechseln. Für Unternehmen aus Münster, NRW und dem DACH-Raum ist der pragmatische nächste Schritt ein strukturiertes Erstgespräch mit Systeminventar, Prozesslandkarte und den wichtigsten Compliance-Fragen. Sende diese Unterlagen an Küstermann Media und lass daraus eine priorisierte Migrationsskizze mit Risiken, Zielbild und erster Migrationswelle entwickeln.
