Warum Datenbank-Migration kein reines IT-Projekt ist
Eine Datenbank Migration betrifft das gesamte Unternehmen — nicht nur die Serveradministration. Wenn Reporting abbricht, Fachabteilungen den Zugriff verlieren und die IT unter Druck steht, zeigt sich schnell: Wer die Migration als IT-Ticket behandelt, zahlt doppelt. Einmal in verlorener Produktivität, einmal in Nacharbeit.
Im Mittelstand wiegt das besonders schwer. Anders als Konzerne verfügen die meisten Unternehmen nicht über dedizierte Migrationsteams. Die Verantwortung landet bei der IT-Leitung, die ohnehin ausgelastet ist. Genau deshalb braucht eine Datenbank Migration von Anfang an einen klaren Plan — mit definierten Phasen, Verantwortlichkeiten und Erfolgskriterien.
Die häufigsten Auslöser für eine Migration: End-of-Life der bestehenden Datenbank, Wechsel in die Cloud, Konsolidierung nach Unternehmenszusammenschlüssen oder schlicht Performance-Probleme, die sich mit Tuning nicht mehr lösen lassen.
Die fünf Phasen einer sauberen Datenbank Migration
Phase 1: Analyse und Dateninventar
Bevor eine einzige Zeile migriert wird, steht die Bestandsaufnahme. Welche Datenbanken gibt es? Welche Daten enthalten sie? Wer nutzt sie — und wofür? Das klingt trivial, ist in der Praxis aber der Punkt, an dem die meisten Projekte bereits scheitern.
Ein vollständiges Dateninventar umfasst:
- Datenquellen und Schemas: Alle Tabellen, Views, Stored Procedures und deren Abhängigkeiten
- Datenflüsse: Welche ETL-Prozesse, Schnittstellen und Anwendungen greifen auf die Datenbank zu?
- Datenqualität: Gibt es bekannte Probleme wie Duplikate, fehlende Werte oder inkonsistente Formate?
- Zugriffsrechte: Wer hat welche Berechtigungen — und werden diese in der neuen Umgebung übernommen?
Zeitaufwand: Je nach Komplexität zwei bis vier Wochen. Diese Phase zu überspringen spart keine Zeit — sie verschiebt die Probleme nur nach hinten.
Phase 2: Strategie und Architekturentscheidung
Nicht jede Migration verläuft gleich. Die grundlegende Entscheidung lautet: Lift-and-Shift (1:1 Übernahme) oder Re-Platforming (Anpassung an eine neue Architektur).
Lift-and-Shift ist schneller und günstiger, aber Sie nehmen bestehende Probleme mit. Re-Platforming dauert länger, bietet jedoch die Chance, technische Schulden abzubauen. Für den Mittelstand empfiehlt sich oft ein Mittelweg: Die Struktur weitgehend übernehmen, aber offensichtliche Probleme im gleichen Zug bereinigen.
Weitere Entscheidungen in dieser Phase betreffen die Zielplattform (PostgreSQL, Azure SQL, Amazon RDS, Google Cloud SQL), die Migrationsmethode (offline vs. online, Big-Bang vs. schrittweise) und das Tooling (AWS DMS, Azure Database Migration Service, pgLoader, ora2pg).
Phase 3: Pilot und Validierung
Ein Teilbereich wird zuerst migriert — idealerweise ein abgeschlossenes System mit überschaubarer Komplexität. Die Ergebnisse werden systematisch gegen die alte Datenbank validiert. Erst wenn die Zahlen stimmen, geht es weiter.
Die Validierung prüft drei Dimensionen: Vollständigkeit (Sind alle Datensätze vorhanden?), Korrektheit (Stimmen die Werte?) und Performance (Laufen Abfragen in akzeptabler Zeit?). Automatisierte Vergleichsscripts sparen hier erheblich Zeit gegenüber manuellen Stichproben.
Phase 4: Rollout und Cutover
Die eigentliche Datenbank Migration erfolgt schrittweise mit definierter Fallback-Option. Der kritische Moment ist der Cutover — der Zeitpunkt, an dem die neue Datenbank produktiv geht und die alte abgeschaltet wird.
Best Practices für den Cutover:
- Wartungsfenster klar kommunizieren — intern und an Kunden
- Parallelbetrieb für mindestens 48 Stunden aufrechterhalten
- Monitoring der Performance und Datenqualität in Echtzeit
- Rollback-Plan getestet und dokumentiert bereithalten
Phase 5: Nachbereitung und Optimierung
Nach dem Go-Live ist vor der Optimierung. Indizes anpassen, Abfragen tunen, Monitoring dauerhaft etablieren. Diese Phase wird regelmäßig unterschätzt, obwohl sie über den langfristigen Erfolg der Migration entscheidet.
Typische Fehler bei der Datenbank Migration
Aus der Praxis mit mittelständischen Unternehmen sehen wir immer wieder dieselben Muster:
- Migration ohne Dateninventar starten — Der Klassiker. Führt unweigerlich zu Überraschungen in der Produktivphase.
- Keine Rollback-Strategie definieren — Wenn etwas schiefgeht (und irgendetwas geht immer schief), muss der Weg zurück klar sein.
- Fachabteilungen nicht einbinden — Die IT migriert die Technik, aber die Fachbereiche kennen die Daten. Ohne deren Input fehlen kritische Zusammenhänge.
- Performance-Tests vergessen — Eine Datenbank, die im Testsystem funktioniert, kann unter Produktivlast versagen.
- Zeitplan ohne Puffer — Datenbank-Migrationen dauern erfahrungsgemäß 30-50% länger als geplant. Ein realistischer Zeitplan rechnet das ein.
- Schnittstellen übersehen — Jede Anwendung, die auf die alte Datenbank zugreift, muss umgestellt werden. Vergessene Schnittstellen führen zu stillen Datenverlusten.
Kosten und Zeitrahmen realistisch planen
Die Kosten einer Datenbank Migration im Mittelstand hängen von drei Faktoren ab: Komplexität der Quelldatenbank, Zielplattform und interne vs. externe Durchführung.
Als Richtwerte für eine mittelgroße Datenbank (50-200 Tabellen, 10-50 GB Datenvolumen):
- Analyse und Planung: 8.000 — 15.000 EUR
- Durchführung und Test: 15.000 — 40.000 EUR
- Nachbereitung und Optimierung: 5.000 — 12.000 EUR
- Gesamtdauer: 8 bis 16 Wochen
Dazu kommen Lizenzkosten für die Zielplattform und eventuell Cloud-Infrastruktur. Ein Wechsel von Oracle zu PostgreSQL spart langfristig oft sechsstellige Beträge an Lizenzgebühren — die Migrationskosten amortisieren sich entsprechend schnell.
Tools und Technologien für die Migration
Die Wahl der richtigen Werkzeuge beschleunigt die Datenbank Migration erheblich. Hier eine Übersicht bewährter Lösungen:
- AWS Database Migration Service (DMS) — Vollständig verwalteter Service für kontinuierliche Replikation. Unterstützt heterogene Migrationen (z.B. Oracle zu PostgreSQL). Besonders geeignet für Cloud-Migrationen in die AWS-Umgebung.
- Azure Database Migration Service — Microsofts Pendant für Azure-Zielplattformen. Gute Integration mit bestehenden Microsoft-Landschaften.
- pgLoader — Open-Source-Tool für Migrationen nach PostgreSQL. Schnell, zuverlässig und kostenfrei. Ideal für Mittelständler, die Lizenzkosten sparen wollen.
- ora2pg — Spezialisiert auf Oracle-zu-PostgreSQL-Migrationen. Konvertiert Schemas, Daten und sogar PL/SQL-Prozeduren.
- Flyway und Liquibase — Nicht für die Migration selbst, aber für die Versionierung von Datenbankänderungen danach. Unverzichtbar für nachhaltige Datenbankentwicklung.
Wichtig bei der Tool-Auswahl: Kein Werkzeug ersetzt die fachliche Planung. Tools automatisieren die Ausführung, aber die Entscheidungen über Mapping, Transformation und Validierung bleiben menschliche Aufgaben.
Wann Sie migrieren sollten — und wann nicht
Eine Datenbank Migration ist sinnvoll, wenn:
- Die aktuelle Plattform End-of-Life erreicht und kein Support mehr verfügbar ist
- Lizenzkosten unverhältnismäßig hoch sind
- Performance-Grenzen erreicht sind, die sich nicht durch Optimierung lösen lassen
- Eine Cloud-Strategie umgesetzt werden soll
- Nach einer Übernahme oder Fusion Systeme konsolidiert werden müssen
Sie sollten nicht migrieren, wenn:
- Das einzige Argument Technologie-Hype ist (jede Datenbank hat ihre Berechtigung)
- Keine klaren Anforderungen an die Zielplattform definiert sind
- Die bestehende Datenbank stabil läuft und die Lizenzkosten vertretbar sind
Fazit: Datenbank Migration ist planbar
Eine Datenbank Migration ist kein Abenteuer — sie ist ein planbares Projekt mit bekannten Risiken und bewährten Methoden. Der Schlüssel liegt in gründlicher Vorbereitung, realistischer Zeitplanung und konsequenter Einbindung aller Beteiligten.
Wer die fünf Phasen sauber durchläuft, reduziert das Risiko auf ein Minimum. Wer sie abkürzt, bezahlt die Zeitersparnis später mit Mehraufwand. Die Erfahrung zeigt: Investierte Zeit in Phase 1 und 2 spart ein Vielfaches in Phase 4 und 5.
