Datenbank-Migration planen, Ausfälle vermeiden

Ein Datenbankwechsel scheitert selten daran, dass Daten nicht kopiert werden können. Kritisch wird es meist am Wochenende des Go-Live: Ein Batch verarbeitet Daten doppelt, ein Reporting greift noch auf das Altsystem zu oder die Anwendung akzeptiert die geänderte Zeichencodierung nicht. Wer eine Datenbank-Migration planen muss, braucht deshalb mehr als ein Export-Skript. Entscheidend ist ein belastbarer Ablauf, der Geschäftsprozesse, Datenqualität, Architektur und Betrieb gemeinsam betrachtet.

Datenbank-Migration planen: Das Zielbild zuerst festlegen

Eine Migration ist kein Selbstzweck. Sie soll ein konkretes Problem lösen: etwa auslaufende Herstellerunterstützung, zu lange Release-Zyklen, Performance-Engpässe, Lizenzkosten oder fehlende Hochverfügbarkeit. Ohne ein messbares Zielbild wird aus dem Vorhaben schnell eine technische Verlagerung mit neuen Risiken, aber ohne erkennbaren Geschäftsnutzen.

Formulieren Sie deshalb vor der Toolauswahl, welche Verbesserungen nach der Migration erreicht sein müssen. Das können ein definierter Recovery Point, schnellere Abfragen unter Last, geringere Betriebskosten oder eine standardisierte Bereitstellung per Infrastructure as Code sein. Ebenso wichtig: Legen Sie fest, welche Anwendungen und Teams betroffen sind. Eine Datenbank ist fast nie isoliert. APIs, ETL-Strecken, Reporting, Archivierung, Identitätsdienste und externe Partner können Abhängigkeiten erzeugen, die in Architekturdiagrammen oft fehlen.

Eine belastbare Bestandsaufnahme beantwortet mindestens diese Fragen:

• Welche Datenbanken, Schemata, Tabellen, Datenvolumen und Wachstumsraten sind betroffen?
• Welche Anwendungen lesen oder schreiben Daten und mit welchen Lastprofilen?
• Welche Anforderungen gelten für Verfügbarkeit, Datenschutz, Aufbewahrung und Wiederherstellung?
• Welche Abhängigkeiten bestehen zu Jobs, Reports, Schnittstellen und manuellen Betriebsprozessen?
• Welche fachlichen Zeitfenster erlauben Wartung oder einen kontrollierten Schreibstopp?

Diese Analyse ist keine Bürokratie. Sie legt fest, ob eine Migration mit kurzer Unterbrechung möglich ist oder ob kontinuierliche Replikation, ein Parallelbetrieb und eine schrittweise Umschaltung erforderlich werden.

Nicht jede Migration ist gleich

Die Migrationsmethode hängt von Quelle, Zielplattform und Risikotoleranz ab. Bei einem Versionswechsel innerhalb derselben Datenbankfamilie lassen sich häufig native Upgrade-Werkzeuge und Replikationsmechanismen nutzen. Beim Wechsel von proprietären Systemen auf PostgreSQL, von On-Premises in eine Managed-Cloud-Datenbank oder von einem monolithischen Schema zu klar abgegrenzten Services steigen dagegen die fachlichen und technischen Anforderungen deutlich.

Ein Offline-Umzug mit Export, Import und Wartungsfenster ist einfach zu steuern, aber nur vertretbar, wenn die Ausfallzeit zum Geschäft passt. Replikationsbasierte Verfahren reduzieren den Cutover auf ein kurzes Zeitfenster, erhöhen jedoch Komplexität und Testaufwand. Bei sehr großen oder geschäftskritischen Datenbeständen kann ein Parallelbetrieb mit schrittweiser Umschaltung sinnvoll sein. Dann müssen Konflikte bei Schreibzugriffen, Datenabgleich und Rückweg sauber geregelt werden.

Auch die Zielarchitektur verlangt klare Entscheidungen. Eine Managed Database nimmt dem Team viele Routineaufgaben ab, etwa Patching, Backups und Teile des Failovers. Dafür gelten Vorgaben des Cloud-Anbieters bei Versionen, Erweiterungen, Netzwerk und Wartungsfenstern. Self-Managed-Varianten bieten mehr Kontrolle, benötigen aber nachweisbar verfügbare Betriebskompetenz. Die richtige Wahl richtet sich nicht nach einem Technologie-Label, sondern nach Compliance, Lastprofil, vorhandener Expertise und dem gewünschten Verantwortungsmodell.

Datenmodell und Semantik prüfen

Besondere Risiken entstehen beim Wechsel des Datenbanksystems. Datentypen, Sortierungen, Zeitzonen, Zeichensätze, Transaktionsisolierung und SQL-Dialekte verhalten sich nicht überall identisch. Eine Spalte, die technisch migriert wurde, kann fachlich dennoch falsche Werte liefern. Typische Fehler sind abgeschnittene Dezimalstellen, falsch interpretierte Zeitstempel oder eine abweichende Groß- und Kleinschreibung in Suchabfragen.

Prüfen Sie deshalb nicht nur Zeilenanzahlen und Prüfsummen. Definieren Sie fachliche Validierungen: Stimmen Salden, Bestellstatus, Berechtigungen, offene Vorgänge und aggregierte Kennzahlen? Für kritische Tabellen sind Vergleichsregeln sinnvoll, die automatisch gegen Quelle und Ziel ausgeführt werden. So wird Datenqualität vor dem Go-Live nachgewiesen statt im Produktivbetrieb vermutet.

Der Migrationsplan braucht überprüfbare Gates

Ein guter Plan beschreibt nicht nur Termine und Zuständigkeiten. Er definiert klare Kriterien, wann ein Schritt abgeschlossen ist und wann das Team nicht weitermachen darf. Damit lassen sich Risiken früh sichtbar machen, statt sie unter Zeitdruck im Cutover zu diskutieren.

1. Analyse und Architekturentscheidung

In dieser Phase werden Abhängigkeiten erhoben, Daten klassifiziert und die Zielplattform ausgewählt. Das Ergebnis sollte eine nachvollziehbare Entscheidungsgrundlage enthalten: Zielarchitektur, Sicherheitsmodell, Netzwerkkonzept, Backup- und Restore-Strategie, Kapazitätsannahmen sowie Kostenmodell. Gerade in der Cloud sind nicht nur Compute-Kosten relevant. Datenübertragung, Storage, Backups, Replikate und Observability verursachen laufende Kosten, die in der Planung sichtbar sein müssen.

2. Migration in einer realitätsnahen Umgebung

Die erste vollständige Migration ist ein Testlauf, kein Nebenprojekt. Nutzen Sie möglichst produktionsnahe Datenmengen und anonymisieren Sie personenbezogene Daten dort, wo es erforderlich ist. Messen Sie Dauer, Durchsatz, Sperrzeiten und Ressourcenverbrauch. Testen Sie nicht nur den Import, sondern auch die Anwendung unter repräsentativer Last, Hintergrundjobs, Wiederherstellungen und Sicherheitskontrollen.

Aus dem Testlauf entsteht ein Runbook: eine präzise Abfolge mit Verantwortlichen, Kommandos, Prüfschritten, Zeitvorgaben und Eskalationswegen. Wenn zentrale Schritte nur im Kopf einzelner Spezialisten existieren, ist der Plan nicht betriebsreif.

3. Cutover mit Rückfallplan

Der Cutover braucht einen klaren Point of No Return. Bis zu diesem Punkt muss feststehen, wie die Anwendung auf das Ziel umgeschaltet wird, wie Datenänderungen synchronisiert werden und welche fachliche Freigabe erforderlich ist. Danach muss eindeutig sein, ob und wie ein Rollback möglich bleibt.

Ein Rückfallplan bedeutet nicht einfach, ein Backup zu besitzen. Er beschreibt, welche Daten nach dem Umschalten entstanden sind, wie sie behandelt werden und wie lange ein Rückweg realistisch dauert. Bei bidirektionalen Änderungen kann ein Rollback teuer oder fachlich nicht vertretbar sein. In diesem Fall ist es häufig sinnvoller, die Umschaltung in kleinere, kontrollierbare Schritte zu zerlegen.

4. Stabilisierter Betrieb nach dem Go-Live

Die Migration endet nicht mit einer erfolgreichen Verbindung zum Zielsystem. In den ersten Tagen müssen technische und fachliche Kennzahlen eng beobachtet werden: Fehlerraten, Latenzen, Lock-Waits, Replikationsverzug, Cache-Hit-Raten, Datenbankgröße, Backup-Erfolg und Kostenentwicklung. Ebenso wichtig sind Rückmeldungen aus Fachbereichen, etwa zu Reports, Suchfunktionen oder periodischen Abrechnungen.

Definieren Sie vorab eine Hypercare-Phase mit erreichbaren Verantwortlichen und festen Entscheidungswegen. Anschließend gehört die Datenbank in den regulären Betriebsprozess: Monitoring, Alarmierung, Patch-Management, Restore-Tests, Kapazitätsplanung und dokumentierte Zugriffsverfahren. Ein Backup ohne regelmäßig getestete Wiederherstellung ist kein belastbarer Schutz.

Automatisierung reduziert Risiko, ersetzt aber keine Entscheidungen

Wiederholbare Abläufe sollten automatisiert werden. Infrastructure as Code verhindert, dass Netzwerkregeln, Parametergruppen oder Verschlüsselungseinstellungen zwischen Umgebungen abweichen. CI/CD-Pipelines können Schemaänderungen versioniert ausliefern und vorab gegen Testdaten prüfen. Observability macht sichtbar, ob eine Migration die Antwortzeiten oder Fehlerquote der Anwendung verändert.

Automatisierung löst jedoch keine ungeklärten fachlichen Fragen. Sie kann einen fehlerhaften Datentyp sehr schnell in jede Umgebung transportieren. Daher braucht jede Pipeline Qualitätsgates: Schema-Checks, Migrations-Tests, Sicherheitsprüfungen und fachliche Stichproben. Die Kombination aus automatisierten Kontrollen und klarer technischer Verantwortung macht den Unterschied zwischen einer schnellen und einer kontrollierten Migration.

Für mittelständische Unternehmen ist der pragmatische Weg meist der beste: erst Risiken und Abhängigkeiten transparent machen, dann die passende Zielarchitektur wählen und den Ablauf mehrfach unter realen Bedingungen erproben. Wer die Datenbank-Migration so plant, gewinnt nicht nur eine modernere Plattform, sondern einen Betrieb, der Releases, Wachstum und neue Anforderungen verlässlich tragen kann.