Migrationsassistent (Daten-/Schemamigration)

Du migrierst Daten/Schema. Ist es homogen oder heterogen, und wie hoch ist deine Downtime-Toleranz? Plane Schritt für Schritt: bewerten → migrieren → verifizieren. Probe den Cutover zuerst hier.

Von wo nach wo migrierst du?

Homogen: dieselbe Datenbank-Engine (z. B. Oracle 19 → Oracle 23 oder PostgreSQL auf einen anderen Server). Heterogen: eine andere Engine (z. B. Oracle → PostgreSQL, MySQL → SQL Server). Heterogene Migrationen erfordern deutlich mehr Kompatibilitätsarbeit (Datentypen, Funktionen, PL/SQL).

• Gleiche Engine, neuer Server/neue Version (homogen)
• Zu einer anderen Engine (heterogen)
• Ich bin in der Planungsphase; wie gehe ich vor?

Wie hoch ist deine Downtime-Toleranz?

Das bestimmt die Migrationsmethode. Gibt es ein Wartungsfenster, ist Dump/Restore der einfachste Weg. Ist nahezu keine Downtime erlaubt, lädst du die initialen Daten, hältst sie mit kontinuierlicher Replikation (CDC) synchron und führst einen kurzen Cutover durch.

• Es gibt ein Wartungsfenster (Downtime ist akzeptabel)
• Nahezu keine Downtime erlaubt

Hast du die Schema- und Typkompatibilität bewertet?

Bei einer heterogenen Migration liegt die eigentliche Arbeit nicht im Kopieren der Daten, sondern im Auflösen der Unterschiede: Datentypen (VARCHAR2↔TEXT), Funktionen (NVL↔COALESCE), Auto-Increment-Werte, PL/SQL ↔ PL/pgSQL, entfernte/abweichende Features.

• Ich habe die Schema-/Typunterschiede zugeordnet
• Ich habe sie noch nicht bewertet

Zuerst die Kompatibilität bewerten

Ordne vor der Migration die Unterschiede zwischen Quelle und Ziel zu; wird dieser Schritt übersprungen, bleibt die Migration auf halbem Weg stecken.

Offline-Migration (Dump / Restore)

Die einfachste und zuverlässigste homogene Methode: ein konsistentes Backup erstellen, ins Ziel laden, prüfen, umschalten.

Minimale Downtime (CDC / Replikation)

Die initialen Daten laden und das Ziel dann über kontinuierliche Replikation mit der Quelle synchron halten; Downtime entsteht nur während des kurzen Cutovers.

Heterogene Migration (auf eine andere Engine)

Schema konvertieren, Daten übertragen, Logik anpassen, prüfen. In Phasen vorgehen; nicht alles auf einmal migrieren.