Datenbankmigration: Was bei der Migration zwischen Versionen schiefgehen kann

Eine Datenbankmigration klingt nach einem Klick. Sie starten ein Skript, die neue Version läuft, die Anwendung reagiert wie vorher. Fertig, könnte man meinen.

Die Datenbankmigration Risiken zeigen sich aber selten sofort. Sie zeigen sich Wochen später, wenn ein Bericht falsche Zahlen ausgibt oder eine Suche plötzlich Treffer verpasst, die früher gefunden wurden. Bis dahin ist unklar, wie viele Datensätze schon betroffen sind.

Dieser Artikel zeigt die häufigsten Fallen bei der Migration zwischen Datenbankversionen und was Sie tun können, damit aus einer scheinbar erfolgreichen Migration keine stille Datenkatastrophe wird.

Warum eine Migration "funktioniert" und trotzdem schiefgeht

Eine Migration lässt sich technisch in wenigen Minuten durchführen: Dump erstellen, neue Version installieren, Dump einspielen. Das Skript läuft durch, keine Fehlermeldung erscheint, die Anwendung startet.

Genau das ist das Problem. Ein Migrationsskript ohne Fehlermeldung sagt nichts darüber aus, ob die Daten danach noch dasselbe bedeuten wie vorher. Viele der größten Risiken entstehen nicht durch einen Absturz, sondern durch stille Abweichungen, die kein Tool automatisch meldet.

Die häufigsten Fallen bei der Datenbankmigration

Datentypen verhalten sich anders als erwartet

Ein INT ist nicht immer ein INT. Zwischen Datenbankversionen und erst recht zwischen Datenbanksystemen ändern sich Wertebereiche, Rundungsverhalten und die Behandlung von Nullwerten. Ein Feld, das in der alten Version stillschweigend abgeschnitten hat, kann in der neuen Version einen Fehler werfen, oder umgekehrt: Wo früher ein Fehler kam, wird jetzt klaglos gerundet.

Besonders tückisch sind Datums- und Zeitfelder. Ein Zeitstempel ohne Zeitzoneninformation wird von manchen Systemen als lokale Zeit interpretiert, von anderen als UTC. Nach der Migration verschieben sich dann Uhrzeiten um mehrere Stunden, ohne dass eine einzige Fehlermeldung erscheint.

Constraints, die niemand mehr auf dem Schirm hat

Ältere Datenbanken haben oft über Jahre Constraints angesammelt, die inzwischen niemand mehr dokumentiert hat: Fremdschlüssel, die nur informell galten, Eindeutigkeitsregeln, die in der Anwendung geprüft wurden statt in der Datenbank. Bei der Migration werden solche impliziten Regeln leicht übersehen.

Fehlt eine Constraint nach der Migration, verhindert nichts mehr, dass doppelte oder widersprüchliche Daten entstehen. Das fällt oft erst auf, wenn ein Bericht plötzlich mehr Kunden zählt als tatsächlich existieren.

Zeichensatzkodierung als stiller Datenverderber

Wechselt die Zeichensatzkodierung, etwa von latin1 auf utf8mb4, können Umlaute, Sonderzeichen oder Emojis in bestehenden Feldern falsch interpretiert werden. Das Ergebnis sind kryptische Zeichenfolgen anstelle von "ä" oder "ß", oft erst sichtbar, wenn ein Kunde seinen eigenen Namen falsch geschrieben auf der Rechnung sieht.

Bei einer Migration von MySQL auf PostgreSQL verschärft sich das Problem zusätzlich, weil beide Systeme Zeichensätze unterschiedlich handhaben.

Undokumentierte Abhängigkeiten zwischen Tabellen

In gewachsenen Anwendungen gibt es fast immer Verbindungen zwischen Tabellen, die nirgends aufgeschrieben sind: ein Trigger, der beim Einfügen eines Datensatzes eine andere Tabelle aktualisiert, eine gespeicherte Prozedur, die niemand mehr im Detail kennt. Wird bei der Migration nur das Datenschema übertragen, bleiben diese Mechanismen zurück.

Die Anwendung läuft danach weiter, aber bestimmte Abläufe funktionieren nicht mehr. Wer nicht genau weiß, was vor der Migration alles vorhanden war, merkt das erst, wenn ein Prozess plötzlich ausbleibt.

Performance-Annahmen, die nicht mehr gelten

Eine Abfrage, die auf der alten Version in Millisekunden lief, kann auf der neuen Version deutlich langsamer sein, wenn sich der Abfrageplaner anders verhält oder ein Index bei der Migration nicht korrekt übernommen wurde. Das merkt man oft erst unter echter Last, nicht im Test mit wenigen Datensätzen.

Auch Sortierreihenfolgen können sich verschieben. Was in der alten Datenbank alphabetisch geordnet war, erscheint nach der Migration in einer anderen Reihenfolge, weil sich die Collation-Einstellung geändert hat. Für einen Menschen fällt das schnell auf. Für eine automatisierte Auswertung, die auf eine bestimmte Reihenfolge angewiesen ist, kann es zu falschen Ergebnissen führen, ohne dass ein Fehler auftritt.

Rollback-Pläne, die niemand testet

Viele Teams planen eine Migration nur in eine Richtung: vorwärts. Ein Rollback-Plan wird zwar oft erwähnt, aber selten tatsächlich durchgespielt. Wenn sich nach der Migration zeigt, dass Daten beschädigt wurden, fehlt dann die Übung, schnell und ohne weiteren Schaden zur alten Version zurückzukehren.

Ein getesteter Rollback-Plan gehört deshalb genauso zur Vorbereitung wie die Migration selbst. Er sollte vor dem eigentlichen Termin einmal geprobt werden, nicht erst im Ernstfall.

Was passiert, wenn diese Risiken unentdeckt bleiben

Die Konsequenzen einer missglückten Migration zeigen sich meist zeitversetzt. Berichte weichen leicht von der Realität ab, ohne dass jemand sofort misstrauisch wird. Kunden melden vereinzelt Probleme, die als Einzelfall abgetan werden. Erst wenn sich solche Meldungen häufen, wird nach der Ursache gesucht, und dann liegt die Migration oft schon Monate zurück.

Bis dahin sind zwei Dinge geschehen: Die fehlerhaften Daten haben sich in Auswertungen, Exporten und möglicherweise auch in Kundenkommunikation verbreitet. Und die alte Datenbank, die zum Vergleich helfen könnte, ist häufig schon abgeschaltet oder überschrieben.

Wie Sie eine Migration sicher durchführen

Der wirksamste Schutz ist eine strukturierte Vorbereitung statt eines einzelnen Migrationsskripts.

Erstellen Sie zuerst eine vollständige Bestandsaufnahme: welche Tabellen, Trigger, Prozeduren und Constraints tatsächlich vorhanden sind, nicht nur was dokumentiert ist. Prüfen Sie dann jedes Feld auf Typkompatibilität zwischen alter und neuer Version, besonders bei Datums-, Zeit- und Textfeldern.

Führen Sie die Migration zunächst in einer Testumgebung mit einer echten Kopie der Produktionsdaten durch, nicht mit synthetischen Testdaten. Vergleichen Sie danach Stichproben zwischen alter und neuer Datenbank: Zeilenanzahl pro Tabelle, Summen in wichtigen numerischen Feldern, ein Blick auf Datensätze mit Sonderzeichen.

Wer eine geordnete Vorgehensweise für diesen Vergleich sucht, findet sie in unserer Checkliste für Software-Migrationen. Für Systeme, die schon seit Jahren auf einer älteren MySQL-Version laufen, lohnt sich zusätzlich ein Blick auf die besonderen Fallstricke bei der Wartung älterer MySQL-Versionen, da viele der genannten Risiken genau dort ihren Ursprung haben.

Bewahren Sie außerdem die alte Datenbank noch einige Wochen nach der Migration auf, auch wenn sie nicht mehr aktiv genutzt wird. Nur so lässt sich im Zweifel nachvollziehen, ob eine Abweichung durch die Migration entstanden ist oder schon vorher bestand.

Fazit: Eine Migration ist erst dann erfolgreich, wenn die Daten stimmen

Ein durchlaufendes Skript ist kein Beweis für eine gelungene Migration. Erst der Abgleich zwischen alten und neuen Daten zeigt, ob wirklich alles übertragen wurde, so wie es gemeint war.

Gerade bei Altsystemen, die über Jahre gewachsen sind, lohnt sich eine gründliche Vorbereitung mehr als ein schneller Umzug. Sprechen Sie uns an. Das Erstgespräch ist kostenlos, und wir sagen Ihnen ehrlich, worauf es bei Ihrer konkreten Datenbank ankommt.