Warehouse-Migration: was wirklich Arbeit macht

Wer eine Migration plant, schätzt zuerst das Datenvolumen. Das ist verständlich und führt in die Irre. Ein Terabyte über eine 10-Gigabit-Leitung ist eine Frage von Stunden. Die vier Wochen, die eine Migration typischerweise braucht, gehen für etwas anderes drauf.

Was tatsächlich Zeit kostet

SQL-Dialekte: die Unterschiede sind unspektakulär und zahlreich

Ein automatischer Übersetzer bringt den Großteil der Objekte durch. Was übrig bleibt, ist selten exotisch, sondern zahlreich: Fensterfunktionen mit anbieterspezifischen Rahmenklauseln, Datumsarithmetik, implizite Typumwandlung, Sortierung von NULL-Werten, das Verhalten bei Division durch Null.

-- Sortierung von NULL: nicht überall gleich
SELECT kunde FROM umsatz ORDER BY betrag DESC;
-- Standard: NULLS FIRST bei DESC. Manche Systeme: NULLS LAST.
-- Ein Bericht mit "Top 10" liefert damit andere Zeilen.

-- Division durch Null
SELECT summe / anzahl FROM kennzahlen;
-- Fehler, NULL oder Unendlich – je nach System.

-- Explizit ist billiger als überrascht:
SELECT kunde FROM umsatz ORDER BY betrag DESC NULLS LAST;
SELECT summe / nullif(anzahl, 0) FROM kennzahlen;

Keiner dieser Unterschiede erzeugt einen Fehler. Sie erzeugen andere Zahlen – und das ist der schlimmere Fall, weil es niemandem auffällt, bis es jemandem auffällt.

Rechte sind Archäologie

In einem gewachsenen Warehouse existieren typischerweise mehr Rollen als Fachbereiche, weil über Jahre für Einzelfälle Rollen angelegt wurden. Beim Umzug rächt sich das: eine 1:1-Übernahme kopiert den Wildwuchs, eine Neuordnung braucht Entscheidungen von Menschen, die keine Zeit haben.

Der pragmatische Weg ist eine Bestandsaufnahme aus der Query-Historie statt aus dem Rechtemodell: welche Rolle hat in den letzten sechs Monaten tatsächlich auf welche Tabellen zugegriffen? Rollen ohne Zugriffe sind Kandidaten zum Streichen, und diese Liste diskutiert sich leichter als ein Rechtekonzept.

Zeitzonen: die stillste Fehlerquelle

Warehouses behandeln Zeitstempel unterschiedlich: mit Zeitzone, ohne Zeitzone, implizit in UTC, implizit in der Sitzungszeitzone. Beim Umzug verschieben sich dadurch Tagesgrenzen. Ein Umsatz, der um 23:40 Uhr Ortszeit gebucht wurde, landet je nach Auslegung im Vortag.

Tagesgrenzen sind der Ort, an dem Migrationen scheitern, nachdem sie für erfolgreich erklärt wurden.

Die Prüfung ist einfach und wird selten gemacht: für jede Faktentabelle die Tagessummen der letzten dreißig Tage in beiden Systemen vergleichen. Eine Verschiebung um genau einen Tag bei genau den Randstunden ist das Muster.

Der Abgleich ist die Freigabe

Technisch ist die Migration fertig, wenn Abfragen laufen. Organisatorisch ist sie fertig, wenn jemand unterschreibt. Dazwischen liegt der Abgleich, und der braucht Parallelbetrieb: beide Systeme laufen, dieselben Berichte werden gegen beide gefahren, Abweichungen werden erklärt.

1. 1Die zwanzig wichtigsten Berichte auswählen – nicht alle, sondern die, auf die Entscheidungen gestützt werden.
2. 2Jeden Bericht auf beiden Systemen mit identischen Parametern fahren, Ergebnisse Zeile für Zeile vergleichen.
3. 3Jede Abweichung erklären. „Rundung“ ist keine Erklärung, „Sortierung von NULL-Werten in Zeile 7“ ist eine.
4. 4Erst danach die BI-Verbindungen umstellen und das Altsystem abschalten.

Schritt drei ist der, den man auslassen möchte. Er ist auch der, der die Migration verantwortbar macht: eine unerklärte Abweichung ist keine Toleranz, sondern ein unbekannter Fehler.

Was daraus für die Planung folgt

Vier Wochen sind realistisch, wenn Woche eins der Bestandsaufnahme gehört – Metadaten, Query-Historie, tatsächliche Rechtenutzung – und Woche vier dem Abgleich. Die technische Arbeit liegt in der Mitte und ist der planbare Teil. Wer mit der Installation anfängt, verschiebt die Unsicherheit nur nach hinten.