Die Migration selbst ist der einfache Teil. Der Abgleichschritt, den Sie vergessen haben, ist der Punkt, an dem die Tücken liegen.

Eine Datenmigration – also 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 in der Story. Die Schwierigkeiten liegen in den Dingen, die die Transformation nicht erkennt: 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, wenn auch in einer Weise, die in der Spezifikation nicht erfasst wurde; sowie Randfälle, die nur deshalb erhalten 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 eines Speichers mit den darin bereits vorhandenen Daten geändert. Bei einer Datenmigration werden Daten zwischen Systemen verschoben, und die Frage lautet nicht: „Wird der ALTER-Befehl rechtzeitig abgeschlossen?“, — sondern „Was machen wir mit den Zeilen, die auf keiner der beiden Seiten ü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 unvollständig die Quelle ist?“

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

Leitartikel: „Wer gleicht die Zeilen ab, die nicht einwandfrei 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 läuft, 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 Abschaffung?
  • Wer gleicht die Zeilen ab, die nicht einwandfrei migriert werden, und anhand welcher Schwelle?
  • 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 erstreckt sich über das gesamte Quartal.

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