Datenmigration ohne Ausfall planen und sicher umsetzen

Ein geplanter Systemwechsel scheitert selten an der eigentlichen Datenkopie. Kritisch wird es dort, wo Altsystem, neue Anwendung, Schnittstellen und operative Prozesse gleichzeitig weiterlaufen müssen. Wer eine Datenmigration ohne Ausfall planen will, braucht deshalb mehr als ein Export-Import-Skript: erforderlich sind eine belastbare Zielarchitektur, klare Verantwortlichkeiten und ein Übergang, der fachlich wie technisch kontrollierbar bleibt.

Das betrifft nicht nur große ERP- oder SAP-Landschaften. Auch beim Wechsel einer Web-Anwendung, beim Aufbau einer SaaS-Plattform oder bei der Ablösung eines gewachsenen Backends können wenige Minuten Ausfall Umsatz, Produktivität oder Vertrauen kosten. Besonders anspruchsvoll wird die Migration, wenn Daten in mehreren führenden Systemen liegen, externe Partner angebunden sind oder die Datenqualität über Jahre gelitten hat.

Warum Migrationen im laufenden Betrieb anspruchsvoll sind

Eine Migration unter Betriebsbedingungen ist kein einmaliges technisches Ereignis, sondern ein gesteuerter Veränderungsprozess. Während Teams Datenstrukturen übertragen, ändern Mitarbeitende weiterhin Kunden-, Auftrags- oder Stammdaten. Gleichzeitig erwarten Nutzer, dass Anwendungen erreichbar bleiben und Prozesse ohne manuelle Umwege funktionieren.

Das zentrale Problem ist die Datenkonsistenz. Werden Daten zu früh kopiert, ist der Zielbestand beim Go-live bereits veraltet. Werden Änderungen parallel in zwei Systemen gepflegt, entstehen Abweichungen. Und wenn Schnittstellen nicht auf die neue Datenlogik vorbereitet sind, kann eine formal erfolgreiche Migration operative Fehler erzeugen - etwa doppelte Bestellungen, fehlende Berechtigungen oder unvollständige Statusinformationen.

Eine echte Null-Ausfall-Migration ist nicht in jedem Szenario wirtschaftlich sinnvoll. Bei kleineren, intern genutzten Anwendungen kann ein klar kommuniziertes Wartungsfenster die einfachere und sicherere Entscheidung sein. Sobald jedoch geschäftskritische Prozesse, Kundenportale, Produktion, Logistik oder Service-Prozesse betroffen sind, lohnt sich die Investition in eine Architektur, die den Übergang ohne Unterbrechung ermöglicht oder die Downtime auf wenige, kontrollierbare Sekunden reduziert.

Datenmigration ohne Ausfall planen: Erst das Zielbild klären

Bevor Migrationstools, Datenbankjobs oder APIs ausgewählt werden, muss feststehen, was nach der Umstellung fachlich und technisch gelten soll. Das Zielsystem darf nicht lediglich eine Kopie des Altsystems sein. Es sollte die künftigen Prozesse, Integrationen, Sicherheitsanforderungen und Wachstumsszenarien abbilden.

Dazu gehört zunächst ein vollständiges Dateninventar. Welche Datenobjekte existieren? Welches System ist jeweils führend? Welche Attribute werden noch benötigt, welche nur aus regulatorischen Gründen archiviert? Gerade historisch gewachsene Systeme enthalten oft Felder, Tabellen und Sonderlogiken, deren Bedeutung nicht mehr dokumentiert ist. Diese Altlasten ungeprüft zu übernehmen, verlagert technische Schulden direkt in die neue Plattform.

Ebenso wichtig ist eine Migrationsstrategie pro Datenklasse. Stammdaten wie Kunden, Produkte oder Organisationseinheiten lassen sich häufig frühzeitig und wiederholbar übertragen. Bewegungsdaten, offene Vorgänge oder Transaktionen erfordern dagegen eine präzise Betrachtung: Welche Daten müssen bis zum Cutover synchron bleiben? Welche können später nachgeladen werden? Und welche bleiben rechtssicher im Altsystem verfügbar, ohne den operativen Betrieb zu beeinträchtigen?

Ein belastbares Zielbild beantwortet außerdem Architekturfragen. Wird das neue System schrittweise neben dem bestehenden betrieben? Werden Funktionen über eine API-Schicht entkoppelt? Ist eine Event-basierte Synchronisation sinnvoll, damit Änderungen zuverlässig übertragen werden? Die richtige Antwort hängt von Datenvolumen, Änderungsrate, Integrationsdichte und Risikotoleranz ab.

Die passende Übergangsstrategie wählen

In der Praxis haben sich mehrere Vorgehensweisen etabliert. Sie können auch kombiniert werden, wenn unterschiedliche Bereiche eines Systems unterschiedliche Anforderungen haben.

Bei einer Blue-Green-Umstellung existieren alte und neue Umgebung parallel. Der Traffic wird erst nach erfolgreicher Prüfung auf die neue Version geleitet. Das reduziert das technische Umschalt-Risiko deutlich und erlaubt einen schnellen Rückwechsel. Die Methode eignet sich besonders für Web-Anwendungen und containerisierte Cloud-Umgebungen. Schwieriger wird sie, wenn beide Umgebungen während der Übergangszeit auf denselben veränderlichen Datenbestand zugreifen müssen.

Eine schrittweise Migration verlagert Funktionen, Mandanten oder Nutzergruppen nacheinander. Ein neues Kundenportal kann beispielsweise zunächst für eine ausgewählte Gruppe starten, während der Rest auf dem alten System arbeitet. Dieser Ansatz reduziert die Größe eines einzelnen Go-live-Risikos. Dafür benötigt er klare Regeln, welche Plattform für welchen Prozess führend ist, und eine gute Nutzerkommunikation.

Bei hohen Änderungsraten ist Change Data Capture häufig die entscheidende Technik. Nach einem initialen Datenabzug werden nachfolgende Änderungen aus Datenbankprotokollen, Events oder APIs fortlaufend in das Zielsystem übertragen. Kurz vor der Umschaltung bleibt dann nur noch ein kleiner Restbestand zu validieren. Ob dies über Datenbank-Replikation, Messaging oder Integrationsservices erfolgt, richtet sich nach der vorhandenen Architektur und den Anforderungen an Nachvollziehbarkeit.

Das Strangler-Pattern bietet sich an, wenn eine monolithische Anwendung über längere Zeit abgelöst wird. Neue Funktionen werden um das Altsystem herum aufgebaut und übernehmen schrittweise Verantwortung. So entsteht kein riskanter Big Bang. Der Nachteil: Für eine Übergangsphase steigen Architektur- und Betriebsaufwand, weil beide Welten sauber integriert und überwacht werden müssen.

Datenqualität ist ein Go-live-Kriterium, kein Aufräumprojekt danach

Eine Migration macht sichtbar, was im Tagesgeschäft oft verborgen bleibt: Dubletten, unvollständige Pflichtfelder, widersprüchliche Statuswerte und fehlerhafte Referenzen. Werden diese Probleme ignoriert, übernimmt das neue System nicht nur Daten, sondern auch deren Fehlerbilder.

Deshalb sollten fachliche Validierungsregeln früh definiert werden. Dazu zählen etwa eindeutige Kundenkennungen, gültige Beziehungen zwischen Aufträgen und Positionen, zulässige Wertebereiche sowie Anforderungen an Pflichtdaten. Technische Checks allein reichen nicht aus. Eine Datenbank kann alle Fremdschlüssel korrekt abbilden, obwohl ein Auftrag fachlich dem falschen Kundenkonto zugeordnet ist.

Hilfreich ist ein abgestimmter Kriterienkatalog mit Fachbereich, IT, Datenschutz und Betrieb. Darin wird festgelegt, welche Abweichungen einen Go-live verhindern, welche bereinigt werden müssen und welche als akzeptierte Restpunkte dokumentiert bleiben dürfen. Diese Transparenz verhindert, dass unter Zeitdruck über Risiken entschieden wird, die vorher längst hätten geklärt werden können.

Testmigrationen schaffen Entscheidungssicherheit

Die produktive Migration sollte nie der erste vollständige Durchlauf sein. Mehrere Testmigrationen liefern belastbare Erkenntnisse zu Dauer, Datenqualität, Systemlast und manuellen Arbeitsschritten. Sie zeigen auch, ob Abhängigkeiten übersehen wurden - beispielsweise Batch-Jobs, Reporting-Tools, Berechtigungskonzepte oder Integrationen mit SAP, Zahlungsdienstleistern und Drittsystemen.

Ein sinnvoller Test endet nicht mit der erfolgreichen Übertragung von Datensätzen. Entscheidend sind fachliche End-to-End-Szenarien: Kann ein Kunde einen Auftrag auslösen? Wird dieser korrekt verarbeitet? Erscheint der richtige Status im angebundenen System? Funktionieren Rollen, Benachrichtigungen, Reports und Archivzugriffe? Für kritische Prozesse sollten Fachverantwortliche die Ergebnisse explizit abnehmen.

Parallel dazu braucht es Performance- und Lasttests. Eine neue Anwendung kann mit Testdaten sauber funktionieren, im Produktivbetrieb aber durch parallele Anfragen, Synchronisationsjobs oder große Datenmengen an Grenzen stoßen. Monitoring für Datenbank, APIs, Queues und Infrastruktur muss vor dem Go-live eingerichtet sein. Erst dann lassen sich Auffälligkeiten während des Übergangs früh erkennen und einordnen.

Der Cutover braucht einen operativen Ablaufplan

Auch bei einer Migration ohne spürbaren Ausfall gibt es einen Cutover: den Zeitpunkt, an dem das neue System verbindlich die Führung übernimmt. Dieser Moment darf nicht von Einzelwissen oder spontanen Entscheidungen abhängen. Ein Runbook beschreibt deshalb jeden Schritt, die verantwortliche Rolle, erwartete Prüfergebnisse und den Zeitpunkt für Eskalationen.

Zum Ablauf gehören die finale Synchronisation, die Umschaltung von Schnittstellen und Routing, fachliche Smoke-Tests sowie die Freigabe durch klar benannte Entscheider. Ebenso wichtig ist ein Rollback-Plan. Er definiert nicht nur, wie technisch zurückgeschaltet wird, sondern auch, welche Daten seit dem Umschaltpunkt behandelt werden müssen. Ohne diese Regel kann ein Rückfall ins Altsystem neue Inkonsistenzen erzeugen.

In der Hypercare-Phase nach dem Go-live sollte ein interdisziplinäres Team kurzfristig verfügbar sein. Fachbereich, Entwicklung, Betrieb und gegebenenfalls externe Systempartner brauchen einen gemeinsamen Kommunikationskanal und eine priorisierte Fehlerbearbeitung. Kleinere Auffälligkeiten sind normal. Entscheidend ist, dass sie nachvollziehbar erfasst werden und kein kritischer Prozess unbemerkt beeinträchtigt bleibt.

Betrieb und Weiterentwicklung von Anfang an mitdenken

Eine moderne Zielplattform muss nach der Migration wartbar bleiben. Dazu zählen dokumentierte Schnittstellen, automatisierte Deployments, nachvollziehbare Datenflüsse, Berechtigungskonzepte, Backups und Wiederherstellungstests. Gerade bei individuellen Anwendungen entscheidet diese Betriebsfähigkeit darüber, ob die Investition langfristig Skalierbarkeit schafft oder nur ein neues Abhängigkeitsverhältnis erzeugt.

entrcode begleitet solche Vorhaben nicht nur bei der technischen Umsetzung, sondern entlang der gesamten Kette aus Zielarchitektur, Migration, Cloud-Betrieb und Weiterentwicklung. Der Vorteil eines langfristig eingebundenen Technologiepartners liegt dabei weniger in einem einzelnen Tool als in durchgängiger Verantwortung für Schnittstellen, Qualität und Betrieb.

Eine gut geplante Migration beendet nicht einfach ein Altsystem. Sie schafft die technische Grundlage, auf der neue Prozesse, Automatisierungen und digitale Produkte verlässlich wachsen können.