Einschätzung des Aufwands für eine Datenmigration

Die Migration selbst ist der einfache Teil. Der Abgleich, den Sie vergessen haben, ist der Schritt, bei dem die Tücken liegen.

Eine Datenmigration (die Übertragung von Daten von einem System in ein anderes oder von einer Struktur in eine andere innerhalb desselben Systems) gleicht einer Transformation. Aus der Quelle lesen, transformieren, in das Ziel schreiben, den Datenverkehr umleiten. Das Team stimmt über die Transformation ab. Die Transformation ist in der Regel der kleinste Arbeitsschritt innerhalb der Story. Die Schwierigkeiten liegen in den Aspekten, die die Transformation nicht berücksichtigt: Datensätze, die auf den ersten Blick in Ordnung erscheinen, aber auf Daten verweisen, die nicht übertragen wurden; Datensätze, die fehlerhaft wirken, aber tatsächlich korrekt sind – allerdings in einer Weise, die in der Spezifikation nicht erfasst wurde; sowie Randfälle, die nur deshalb bestehen blieben, weil das alte System sie tolerierte, das neue jedoch nicht.

Dies ist ein anderes Problem als eine Datenbankmigration. Bei einer Schemamigration wird die Struktur einer Datenbank mit den darin bereits enthaltenen Daten verändert. Bei einer Datenmigration werden Daten zwischen Systemen verschoben, und die Frage lautet nicht: „Wird der ALTER-Befehl rechtzeitig abgeschlossen?“, sondern: „Wie gehen wir mit den Zeilen um, die auf keiner Seite übereinstimmen?“ Der Großteil der Arbeit besteht aus Abgleich, Umstellungsstrategie und Rollback. Der Transformationscode ist der Teil, den Sie am schnellsten schreiben und als Letztes fertigstellen.

Was in dem Raum gesagt wird

Backend: „Es ist ein Skript. Lesen, zuordnen, schreiben. Höchstens zwei Tage.“

Daten-Eng: „Haben wir uns angesehen, wie ungenau die Quelle ist?“

SRE: „Wie sieht die Umstellung aus – Big-Bang-Methode oder Dual-Write?“

Leitartikel: „Wer gleicht die Datensätze ab, die nicht fehlerfrei migriert werden?“

PM: „Wann wird das alte System auslaufen?“

Die Frage des Projektleiters ist ausschlaggebend für die Schätzung. Wenn das alte System in einem Monat abgeschafft wird, benötigen Sie eine Strategie, die eine 100-prozentige Genauigkeit gewährleistet; wenn es noch zwei Quartale lang parallel zum neuen System besteht, können Sie es sich leisten, den „Long Tail“ auf später zu verschieben. Die Schätzung bezieht sich nicht auf die Transformation, sondern auf die Strategie.

Fragen, die man sich vor der Stimmabgabe stellen sollte

• Wie ist die Qualität der Quelldaten: einwandfrei, fehlerhaft oder unbekannt?
• Umstellungsstrategie: Big-Bang, Dual-Write, Shadow-Read, schrittweise?
• Wie lange werden beide Systeme nebeneinander bestehen? Gibt es einen Stichtag für die Einstellung?
• Wer gleicht die Zeilen ab, die nicht einwandfrei migriert werden, und ab welchem Schwellenwert?
• Wie sieht das Rollback aus, falls das neue System nach der Umstellung fehlerhafte Daten erhält?
• Gibt es nachgelagerte Verbraucher (Berichte, Integrationen), die zeitgleich migriert werden müssen?

Wenn das Team eine 5 abstimmt und jemand sagt: „Moment mal, was ist mit den Einträgen im Audit-Protokoll?“, dann hatten Sie kein Problem bei der Schätzung; Sie hatten zwei Stories, die so taten, als wären sie eine. Teilen Sie es auf: Die Transformation ist ein Ticket, der Abgleich und der Umstellungsplan ein weiteres.

Entscheiden Sie über die Strategie, nicht über die Umstrukturierung. Die Umstrukturierung dauert zwei Tage. Die Strategie betrifft das gesamte Quartal.

Weitere Informationen zur Variante mit Schemaänderung in einem einzelnen System finden Sie unter Schätzung einer Datenbankmigration sowie zu weiteren Beispielen für durchgerechnete Schätzungen. Starten Sie eine kostenlose Planning-Poker-Sitzung, sobald die Umstellungsstrategie skizziert ist.