Der kritischste Punkt: Schema-Wandlung
Der eigentliche Risikofaktor einer Migration liegt nicht im Datentransfer, sondern im Schema.
Oracle ist nicht PostgreSQL.
Unterschiede bestehen unter anderem bei:
- Datentypdefinitionen
- Precision- und Scale-Logik
- Default-Werten
- Umgang mit NULL
- Sequenzen
- PL/SQL vs. PL/pgSQL
- Trigger- und Constraint-Verhalten
Gerade bei numerischen Feldern kann eine falsch übertragene Scale dazu führen, dass Nachkommastellen verloren gehen oder Berechnungsergebnisse abweichen. Was technisch als erfolgreich gemeldet wird, kann fachlich bereits verfälscht sein.
Deshalb beginnt eine Migration bei uns mit einer strukturierten Schema-Analyse.
Wir definieren ein belastbares Ziel-Schema und prüfen systematisch:
- Welche Datentypen müssen angepasst werden?
- Welche Constraints sind kompatibel?
- Welche Trigger-Logik muss refaktoriert werden?
- Welche Stored Procedures gehören in die Applikationsebene?
- Welche fachlichen Validierungen sind erforderlich?
Das AWS Schema Conversion Tool (SCT) unterstützt diesen Prozess, indem es bestehende Strukturen analysiert, konvertierbare Objekte automatisiert überführt und nicht kompatible Elemente transparent kennzeichnet.
Aber ein Tool ersetzt keine fachliche Bewertung.
Automatisierung beschleunigt – sie entbindet nicht von Verantwortung.
Migration mit AWS Database Migration Service (DMS)
Erst wenn das Ziel-Schema definiert und validiert ist, beginnt die eigentliche Datenmigration.
Hier setzen wir typischerweise auf den AWS Database Migration Service (DMS):
- Initialer Full Load
- Anschließende Change Data Capture (CDC)
- Kontinuierliche Synchronisierung zwischen Quelle und Ziel
- Validierung während der Laufzeit
Ein sauberes Migrationsmodell wird nicht in Dumps und Nachtfenstern gedacht.
Es denkt in kontrollierten Übergängen.
Klassische Big-Bang-Migrationen bedeuten häufig: monatelange Vorbereitung, Daten-Freeze, eng getaktete Cutover-Fenster und maximale Abhängigkeit vom Wochenende. Go/No-Go-Entscheidungen fallen unter Zeitdruck. Fallback-Szenarien müssen vorbereitet sein. Am Montagmorgen muss alles funktionieren.
Dieses Modell erzeugt Druck – technisch wie organisatorisch. Wir alle haben schon einmal erleben müssen, dass Druck eher zu Fehlern führt, statt zu sauberen und nachhaltigen Ergebnissen.
Mit einem strukturierten Einsatz von DMS und fortlaufende Synchronisierung von Datenänderungen verlagert sich dieses Risiko. Daten werden fortlaufend synchronisiert, Validierungen können parallel erfolgen und der finale Umschaltpunkt reduziert sich auf ein klar definiertes Zeitfenster.
Dabei beobachten und steuern wir Replikations-Lag, Transaktionsverhalten und Lastprofile gezielt. Gerade bei hochtransaktionalen Systemen oder großen LOB-Strukturen ist ein abgestimmtes Performance- und Monitoring-Konzept entscheidend, um Konsistenz und Stabilität während der Synchronisierung sicherzustellen.
Migration wird dadurch planbar – statt nervenaufreibend.
Für mich ist eine gute Migration kein Kraftakt mit verlängertem Wochenende, sondern ein sauberer Prozess. Wenn Daten kontinuierlich migriert werden, Skalierung flexibel bleibt und Security von Anfang an mitgedacht ist, wird aus Migration echte Weiterentwicklung.
Umgang mit LOBs und großen Datenvolumen
Eine besondere Herausforderung stellen große Binärdaten (LOBs) dar. Dokumente, Bilder oder Videos haben andere Anforderungen an Speicherung und Zugriff als relationale Datensätze.
Werden sie unreflektiert übertragen, entstehen Performance-Probleme, unnötige Speicherkosten oder lange Migrationsfenster.
In solchen Fällen prüfen wir gezielt, ob strukturierte Daten und große Objekte getrennt behandelt werden sollten – etwa durch die Überführung von LOBs in einen Objektspeicher wie Amazon S3, während relationale Daten nach Aurora PostgreSQL migriert werden.
Diese Entscheidung ist kein architektonisches Dogma, sondern eine Frage der fachlichen und betrieblichen Anforderungen.
Streaming als ergänzende Option
In bestimmten Projektsituationen reicht ein klassischer DMS-Ansatz nicht aus.
Wenn:
- extrem große Datenvolumen verarbeitet werden müssen
- Downtime faktisch ausgeschlossen ist
- eine event-basierte Weiterverarbeitung strategisch sinnvoll ist
Dann kann eine Streaming-Architektur die Migration sinnvoll ergänzen.
Ein möglicher Ansatz umfasst:
- Change Data Capture aus Oracle
- Verarbeitung über eine Kafka-basierte Plattform, z. B. Amazon MSK
- Einsatz von Debezium zur Erfassung von Datenänderungen
- Separate Extraktion großer Binärdaten über AWS Lambda
- Speicherung relationaler Daten in Aurora PostgreSQL
- Speicherung von LOBs in Amazon S3
Streaming erweitert damit den Lösungsraum. Es schafft Transparenz über Datenänderungen und ermöglicht eine entkoppelte, skalierbare Verarbeitung. Dabei ist wichtig, dass wir Streaming als eine Option und nicht als Selbstzweck betrachten.
Refactoring als Teil der Migration
Migration bedeutet nicht nur Übertragung.
Sie bedeutet auch technische Bereinigung.
In gewachsenen Oracle-Systemen ist Geschäftslogik häufig tief in Stored Procedures, Triggern oder datenbankseitigen Funktionen verankert. Eine 1:1-Übernahme würde diese Abhängigkeiten lediglich in eine neue Umgebung verschieben.
Deshalb prüfen wir gezielt:
- Welche Logik gehört weiterhin in die Datenbank?
- Welche Funktionalität sollte in Applikationsservices verlagert werden?
- Welche Transaktionsmuster müssen angepasst werden?
- Welche impliziten Annahmen sind im System verborgen?
Dabei betrachten wir insbesondere Transaktionsgrenzen, Locking-Verhalten und Konsistenzanforderungen. Wird Logik aus der Datenbank herausgelöst, muss sichergestellt sein, dass fachliche Gleichwertigkeit, Performance und Datenintegrität auch im verteilten Modell erhalten bleiben.
Refactoring ist damit kein Zusatzschritt, sondern Teil der fachlichen Absicherung.
Es stellt sicher, dass die neue Umgebung nicht nur technisch kompatibel, sondern auch strukturell tragfähig ist.
Was uns im Team wichtig ist
Als Berater & Entwickler bei PROTOS reizt uns an solchen Projekten nicht allein der technologische Wechsel. Entscheidend ist, dass aus einem gewachsenen System eine Plattform entsteht, die kontrollierbar, nachvollziehbar und langfristig tragfähig ist.
Architektur muss erklärbar bleiben. Komponenten dürfen keine Blackbox sein. Datenflüsse müssen transparent sein – technisch wie fachlich.
Wir definieren Infrastruktur konsequent als Code, integrieren Security von Beginn an in das Gesamtkonzept und bauen Monitoring als festen Bestandteil der Plattform auf.
So entsteht keine bloße Migration, sondern eine Umgebung, die sich verstehen, betreiben und weiterentwickeln lässt.
Was sich im Alltag konkret verändert
Nach der Migration steht nicht nur eine neue Datenbank.
Migrationen laufen kontrolliert und reproduzierbar.
Daten sind konsistent.
Fehler sind sichtbar.
Skalierung ist kein Projekt mehr, sondern eine Konfiguration.
Entwickler können neue Services anbinden, ohne bestehende Systeme zu gefährden.
DevOps-Teams betreiben eine Architektur, die sie beherrschen.
Und Management gewinnt Planungssicherheit.
Fazit
Eine Datenbankmigration ist dann erfolgreich, wenn sie mehr schafft als einen Systemwechsel. Sie muss fachlich korrekt sein, Risiken transparent machen und den operativen Betrieb nachhaltig entlasten.
Mit einer strukturierten Schema-Analyse, dem gezielten Einsatz von AWS SCT und DMS sowie – wo sinnvoll – ergänzenden Streaming-Architekturen entsteht kein technischer Kraftakt, sondern ein kontrollierter Übergang.
Für unsere Kunden bedeutet das Planungssicherheit, technische Klarheit und die Freiheit, neue digitale Vorhaben auf einer stabilen Grundlage umzusetzen.
Dafür stehen wir bei PROTOS.
