Modernisierung von Legacy-Datenbanken: Vorgehen, Kosten und Dauer

April 2, 2026 - By Eugene Afonin

Die eine Unterscheidung, die über Aufwand und Risiko entscheidet — und warum nicht das Datenvolumen den Preis bestimmt.

Transparenzhinweis. legacy-modernisierung.de wird von der Chudovo OÜ betrieben. Die Kosten- und Zeitangaben in diesem Leitfaden sind die Spannen, die Chudovo aus eigenen abgeschlossenen Projekten veröffentlicht — Referenzwerte eines Anbieters auf Basis osteuropäischer Engineering-Raten, keine Branchendurchschnitte. Die zitierten Vorgehensweisen stammen von AWS und Microsoft.

Die Unterscheidung, die alles entscheidet

Die meisten Leitfäden beschreiben Datenbankmodernisierung mit dem Vokabular der Anwendungsmigration — Rehost, Replatform, Refactor. Diese Einteilung ist entliehen und verdeckt die Frage, die Aufwand, Dauer und Risiko tatsächlich bestimmt:

Bleiben Sie auf derselben Datenbank-Engine oder wechseln Sie sie?

Homogene Migration — Oracle 11g auf Oracle 19c, SQL Server 2008 auf Azure SQL Database, selbst betriebenes PostgreSQL auf Amazon RDS. SQL-Dialekt, Datentypen und prozedurale Sprache bleiben dieselben.
Heterogene Migration — Oracle auf PostgreSQL, SQL Server auf MySQL, DB2 auf irgendetwas. Die Engine wechselt, und mit ihr der Dialekt, das Typsystem und jede Zeile prozeduraler Code.

Der Unterschied ist kein gradueller. Eine homogene Migration einer mittelgroßen Datenbank ist eine Termin- und Validierungsaufgabe. Dieselbe Datenbank heterogen zu migrieren ist ein Code-Konvertierungsprojekt mit einer Datenmigration im Anhang.

Dieselbe Datenbank, zwei Wege. Die Datenmenge ist in beiden Fällen identisch — der Unterschied im Aufwand entsteht fast vollständig in den beiden rot markierten Zeilen.

AWS dokumentiert die Trennung in seiner Anleitung zur heterogenen Datenbankmigration; Microsoft beschreibt den homogenen Weg nach Azure in der SQL-Server-Migrationsanleitung.

Wovon in der Praxis migriert wird

Engine	Typische Altversionen, die noch produktiv laufen
Oracle Database	8i bis 19c
Microsoft SQL Server	2000 bis 2019
IBM DB2	Mainframe und LUW
MySQL	4.x–5.x
PostgreSQL	Versionen vor 10
Teradata	On-Premise-Data-Warehouses
SAP HANA	On-Premise
Microsoft Access	Abteilungslösungen, die geschäftskritisch wurden

Versionen wie Oracle 11g, SQL Server 2008/2012 und IBM DB2 aus den 2010er-Jahren werden vom Hersteller nicht mehr unterstützt. Für neu entdeckte Sicherheitslücken gibt es keine Updates mehr.

Der eigentliche Kostentreiber: gespeicherte Prozeduren

Datenbankmigrationen werden üblicherweise nach Datenvolumen geschätzt. Das Datenvolumen ist selten das, was sie teuer macht.

Teuer macht sie prozeduraler Code: gespeicherte Prozeduren, Trigger, Funktionen, Packages. In einem lange gewachsenen System liegt ein erheblicher Teil der Geschäftslogik dort und nicht in der Anwendung — geschrieben in einem Dialekt, der sich nicht portieren lässt.

Oracle PL/SQL zu PostgreSQL PL/pgSQL: ähnlich in der Form, unterschiedlich im Detail — Cursor, Exception-Handling, Package-Struktur und autonome Transaktionen brauchen alle Überarbeitung
T-SQL zu PL/pgSQL: unterschiedlich genug, dass Konvertierung Neuschreiben bedeutet, nicht Übersetzen
Beliebig zu einem Dokumentenspeicher: die prozedurale Schicht hat dort kein Gegenstück und muss in die Anwendung wandern

Ein praktischer Test vor der Schätzung: Zählen Sie die gespeicherten Prozeduren und die Gesamtzahl der Zeilen prozeduralen Codes in der Quelldatenbank. Ein Schema mit 40 Tabellen und keinen Prozeduren ist ein anderes Projekt als ein Schema mit 40 Tabellen und 300 Prozeduren — bei identischem Datenvolumen. Die meisten Budgetüberschreitungen lassen sich darauf zurückführen, dass diese Zahl zum Angebotszeitpunkt unbekannt war.

Wohin migriert wird

Open-Source-Engines: PostgreSQL, MySQL, MariaDB — die üblichen heterogenen Ziele, gewählt zum Ausstieg aus Lizenzkosten. Für Enterprise-Versionen von Oracle oder IBM DB2 fallen Lizenzkosten pro CPU-Kern an.

Managed Cloud Services: Amazon RDS, Amazon Aurora, Azure SQL Database, Azure Database for PostgreSQL, Google Cloud SQL — die üblichen homogenen Ziele, gewählt zum Ausstieg aus dem Betriebsaufwand. Hardware-Bereitstellung, Betriebssystem-Updates und Backup-Verwaltung sind enthalten.

Analytische Plattformen: Amazon Redshift, Google BigQuery, Azure Synapse Analytics — das Ziel, wenn das Altsystem ein Data Warehouse war.

Nicht-relational: MongoDB, DynamoDB, Cosmos DB, Cassandra, Redis, Elasticsearch — richtig, wenn das Zugriffsmuster tatsächlich nicht relational ist; falsch, wenn es gewählt wird, weil das relationale Schema schlecht entworfen war. Ein schlechtes Schema in einen Dokumentenspeicher zu migrieren erhält das schlechte Schema und entfernt die Constraints, die bisher Fehler abgefangen haben.

Die fünf Vorgehensweisen, nach Aufwand geordnet

1. Versionsupgrade im Bestand. Oracle 11g auf 19c, SQL Server 2012 auf 2022. Herstellersupport und Sicherheitsupdates kehren zurück, die Architektur bleibt. Die günstigste Option und häufig die richtige.

2. Umzug auf einen Managed Service. Dieselbe Engine, fremder Betrieb. Beseitigt Patch-Zyklen, Backup-Verwaltung und Hardware-Beschaffung. Verändert nichts am Schema.

3. Schema-Refactoring. Normalisierung, Indizierung, Partitionierung, Entfernen gewachsener Altlasten — ohne Engine-Wechsel. Lohnt, wenn die Leistungsprobleme im Schema liegen und nicht in der Plattform.

4. Heterogene Engine-Migration. Der Code-intensive Fall. Hier entscheidet der prozedurale Bestand über Aufwand und Dauer.

5. Ablösung. Die Datenbank wird nicht migriert, sondern durch eine Standardlösung ersetzt, die ihre eigene Datenhaltung mitbringt. Wie immer die günstigste Antwort, wenn sie überhaupt infrage kommt — und wie immer die, die am seltensten geprüft wird.

Cutover ohne Downtime: wie es tatsächlich funktioniert

Für die meisten Datenbanken ist ein Umschalten ohne Ausfallzeit machbar. Der Mechanismus lohnt sich zu verstehen, weil er den Zeitplan bestimmt.

Die Quelle bleibt bis zum Cutover produktiv. Der einzige Moment ohne Schreibzugriffe ist so lang wie die restliche Replikationsverzögerung.

Initiale Massenkopie. Die Daten werden zu einem Stichzeitpunkt kopiert. Das kann Stunden oder Tage dauern und läuft, während die Quelle produktiv bleibt.
Change Data Capture. Laufende Änderungen werden fortlaufend von der Quelle zum Ziel repliziert, sodass das Ziel aufholt.
Validierung im laufenden Betrieb. Zeilenzahlen, Prüfsummen, fachliche Abgleiche — gegen ein bewegliches Ziel, weshalb dieser Schritt Automatisierung braucht und keine Stichproben. Bei heterogenen Migrationen wird die Anwendung in dieser Phase gegen beide Datenbanken getestet.
Cutover. Schreibzugriffe auf die Quelle werden für die Dauer der verbleibenden Replikationsverzögerung gestoppt, die Anwendung wird umgelenkt, der Betrieb läuft weiter. In Minuten gemessen, nicht in Stunden.
Rückweg warm halten. Rückreplikation für einen definierten Zeitraum, damit eine unter Druck getroffene Entscheidung umkehrbar bleibt.

Der Engpass ist fast immer Schritt 3. Die Quelldatenbank bleibt aktiv, bis die Validierung vollständig abgeschlossen ist.

Kosten und Dauer

Veröffentlichte Spannen von Chudovo für Datenbankmigration, auf Basis typischer Engineering-Raten in Osteuropa:

Umfang	Dauer	Kosten
Kleine Datenbank, einfaches Schema	1–3 Wochen	5.000–20.000 €
Mittelgroße Produktionsdatenbank mit gespeicherten Prozeduren, komplexem Schema und Anwendungsabhängigkeiten	1–3 Monate	20.000–80.000 €
Große Data-Warehouse-Systeme oder Datenbanken mit regulatorischen Validierungsanforderungen	3–6 Monate oder länger	ab 80.000 €

Für eine belastbare Zeitplanung ist eine technische Bewertung erforderlich. Was eine Datenbank aus der ersten in die zweite Zeile verschiebt, ist in aller Regel nicht ihre Größe, sondern die Zahl der gespeicherten Prozeduren und der Anwendungen, die direkt auf sie zugreifen.

Planungsreihenfolge

1. Abhängigkeiten kartieren, vor allem anderen. Welche Anwendungen, Reports, ETL-Jobs, Integrationen und geplanten Tasks lesen diese Datenbank? Die Liste ist immer länger als die, die das Team aus dem Gedächtnis erstellt. Ein vergessener nächtlicher Report, der drei Wochen nach dem Cutover bricht, ist der charakteristische Fehler dieser Phase.

2. Inventar des prozeduralen Codes. Zählen und klassifizieren. Daraus entsteht die Schätzung.

3. Datenklassifizierung. Was ist reguliert, was muss aus Compliance-Gründen aufbewahrt werden, was lässt sich archivieren statt migrieren. Vor der Migration zu archivieren ist häufig die günstigste Einzelentscheidung des gesamten Projekts.

4. Zielauswahl. Getrieben vom Zugriffsmuster und der Betriebsfähigkeit des Teams — nicht von der Plattform, über die der Architekt zuletzt gelesen hat.

5. Pilot auf einem echten Ausschnitt. Kein Beispielschema, sondern ein realer Teil mit echten Prozeduren und echten Datenformen.

6. Validierungsprogramm. Vor der Migration definiert, automatisiert, fortlaufend ausgeführt. Zeilenzahlen sind die Untergrenze, nicht der Test.

Wo Datenbankmodernisierungen schiefgehen

Nach Datenvolumen geschätzt. Der teure Teil ist prozeduraler Code und Validierung.

Validierung als letzter Haken. Einen Typkonvertierungsfehler drei Wochen nach dem Cutover zu entdecken, in Daten, die seitdem beschrieben wurden, verwandelt eine Migration in ein Datenrettungsprojekt.

Die Reporting-Schicht wurde vergessen. Dashboards, BI-Extrakte und regulatorische Reports greifen weit häufiger direkt auf die Datenbank zu, als irgendwo dokumentiert ist. Sie brechen still.

Zeichenkodierung und Sortierreihenfolge. Alte Datenbanken tragen über Jahre gewachsene Kodierungsentscheidungen mit sich. Eine abweichende Collation zeigt sich als Sortierung, die subtil falsch ist — schlimmer als ein Fehler, weil es monatelang niemandem auffällt.

Zeitzonen und Datumsbehandlung. Daten ohne Zeitzone in einem System, das mehrere Regionen umfasste, erzeugen eine Fehlerklasse, die erst nach dem Cutover auftritt und mühsam zu entwirren ist.

NULL- und Leerstring-Semantik. Oracle behandelt einen leeren String als NULL, die meisten anderen Engines nicht. Bei einer heterogenen Migration verändert das Abfrageergebnisse still — über die gesamte Anwendung hinweg.

FAQ

Was ist der Unterschied zwischen homogener und heterogener Datenbankmigration? Bei einer homogenen Migration erfolgt der Wechsel innerhalb derselben Datenbank-Engine, zum Beispiel von einer älteren SQL-Server-Version auf eine neue Version. Bei einer heterogenen Migration wird die Datenbank auf eine andere Engine übertragen, etwa von Oracle zu PostgreSQL. Migrationen zwischen unterschiedlichen Datenbanksystemen sind komplexer, da sich SQL-Dialekte, Datentypen, gespeicherte Prozeduren und Transaktionsmechanismen unterscheiden.

Wie lange dauert eine Datenbankmigration? Kleine Datenbanken mit einfachen Schemata benötigen in der Regel ein bis drei Wochen. Eine mittelgroße Produktionsdatenbank mit gespeicherten Prozeduren, komplexem Schema und Anwendungsabhängigkeiten dauert meist ein bis drei Monate. Große Data-Warehouse-Systeme oder Datenbanken mit regulatorischen Validierungsanforderungen können drei bis sechs Monate oder länger dauern.

Kann eine Datenbank ohne Downtime migriert werden? Ja, für die meisten Datenbanken. Während der Migration wird eine kontinuierliche Replikation zwischen Quell- und Zieldatenbank eingerichtet. Das Cutover erfolgt, sobald die Replikationsverzögerung nahezu null erreicht.

Wie wird Datenverlust während der Migration verhindert? In jeder Migrationsphase werden Anzahl der Datensätze, Prüfsummen und referenzielle Integrität zwischen Quell- und Zieldatenbank geprüft. Bei heterogenen Migrationen wird die Anwendung während der Validierungsphase gegen beide Datenbanken getestet. Die Quelldatenbank bleibt aktiv, bis die Validierung vollständig abgeschlossen ist.

Warum kostet eine Migration mehr, als das Datenvolumen vermuten lässt? Weil der Aufwand im prozeduralen Code steckt. Gespeicherte Prozeduren, Trigger und Funktionen enthalten Geschäftslogik in einem Dialekt, der sich beim Engine-Wechsel nicht portieren lässt, sondern neu geschrieben werden muss.

Lohnt sich der Wechsel auf eine Open-Source-Datenbank? Wenn Lizenzkosten pro CPU-Kern der Treiber sind, in der Regel ja. Der Wechsel ist allerdings heterogen, also der aufwendigste Weg — die Einsparung muss gegen ein Code-Konvertierungsprojekt gerechnet werden, nicht gegen einen Umzug.

Sollte eine Altdatenbank auf einen Dokumentenspeicher migriert werden? Nur wenn das Zugriffsmuster tatsächlich nicht relational ist. Wird die Entscheidung getroffen, weil das relationale Schema schlecht entworfen war, bleibt das schlechte Schema erhalten und die Constraints, die bisher Fehler abgefangen haben, fallen weg.