De migratie zelf is het makkelijke deel. De afstemmingsstap die u bent vergeten, is waar de valkuilen schuilgaan.

Een gegevensmigratie — het verplaatsen van gegevens van het ene systeem naar het andere, of van de ene vorm naar de andere binnen hetzelfde systeem — lijkt op een transformatie. Uit de bron lezen, transformeren, naar de bestemming schrijven, het verkeer omleiden. Het team stemt over de transformatie. De transformatie is doorgaans het kleinste onderdeel van het verhaal. De valkuilen zitten in de zaken die de transformatie over het hoofd ziet: records die er op het eerste gezicht goed uitzien, maar verwijzen naar gegevens die niet zijn overgezet; records die er kapot uitzien, maar in feite correct zijn op een manier die niet in de specificatie is vastgelegd; en randgevallen die alleen standhielden omdat het oude systeem ze tolereerde, terwijl het nieuwe systeem dat niet doet.

Dit is een ander probleem dan een databasemigratie. Bij een schemamigratie wordt de structuur van één database gewijzigd, terwijl de gegevens daarin al aanwezig zijn. Bij een gegevensmigratie worden gegevens tussen systemen verplaatst, en de vraag is niet „is de ALTER-opdracht op tijd voltooid?“ — maar „wat doen we met de rijen die aan geen van beide kanten overeenkomen?“ Het grootste deel van het werk bestaat uit afstemming, de omschakelingsstrategie en het terugdraaien van wijzigingen. De transformatiecode is het deel dat u het snelst schrijft en als laatste afrondt.

Wat er in de kamer wordt gezegd

Backend: “Het is een script. Lezen, toewijzen, schrijven. Maximaal twee dagen.”

Data eng: “Hebben we al gekeken hoe vervuild de bron is?”

SRE: “Hoe verloopt de overgang — via een ‘big bang’ of via ‘dual-write’?”

Kop: “Wie lost de problemen op bij rijen die niet correct worden gemigreerd?”

Premier: “Wanneer wordt het oude systeem afgeschaft?”

De vraag van de premier is bepalend voor de schatting. Als het oude systeem over een maand verdwijnt, heeft u een strategie nodig die 100% nauwkeurig is; als het nog twee kwartalen naast het nieuwe systeem blijft bestaan, kunt u het zich veroorloven om de ‘long tail’ voor later te laten liggen. De schatting heeft geen betrekking op de transformatie, maar op de strategie.

Vragen die u zich het beste kunt stellen voordat u gaat stemmen

  • Hoe is de kwaliteit van de brongegevens — schoon, vervuild of onbekend?
  • Overgangsstrategie: big bang, dual-write, shadow read, geleidelijk?
  • Hoe lang zullen beide systemen naast elkaar blijven bestaan? Is er een einddatum?
  • Wie zorgt ervoor dat de rijen die niet correct worden gemigreerd, worden afgestemd, en op welk niveau?
  • Wat zijn de gevolgen van een terugdraaiing als het nieuwe systeem na de overgang onjuiste gegevens ontvangt?
  • Zijn er downstream-gebruikers (rapporten, integraties) die gelijktijdig moeten worden gemigreerd?

Als het team een 5 stemt en iemand zegt: „Wacht even, hoe zit het dan met de auditlogboekgegevens?”, dan had u geen probleem met de schatting; u had twee stories die deden alsof ze één waren. Splits het op: de transformatie is één ticket, het afstemmings- en overgangsplan is een ander ticket.

Stem over de strategie, niet over de transformatie. De transformatie duurt twee dagen. De strategie geldt voor het hele kwartaal.

Zie het inschatten van een databasemigratie voor de variant waarbij het schema binnen één systeem wordt gewijzigd, en de andere praktijkvoorbeelden van schattingen. Start een gratis planning poker-sessie zodra de overgangsstrategie in grote lijnen is uitgewerkt.