Migrarea sistemelor legacy într-o platformă care modelează munca altfel

Pierderea de rânduri într-o migrare nu e un risc de administrat, e un eșec. Cazul mai greu e când toate rândurile ajung și datele sunt totuși greșite.

În patru ani am mutat aproape două milioane de înregistrări din zece sisteme legacy diferite într-o singură platformă. Sursele nu erau versiuni mai vechi ale aceluiași produs. Erau sisteme comerciale distincte, de la producători diferiți, fiecare cu schema lui și cu propria părere despre ce este înregistrarea centrală, plus convențiile locale pe care orice organizație le adaugă peste software-ul pe care l-a cumpărat. Fiecare a cerut maparea lui, și fiecare a fost o discuție nouă despre ce înseamnă de fapt un anumit câmp.

Cea mai mare parte a muncii se petrece la nivel de câmp și nu are nimic spectaculos. Pe un sistem, analistul clientului mi-a cerut să mapez un câmp care, la verificare, nu exista în tabelul pe care îl numise. Exista unul apropiat, scris altfel, iar eu am întrebat înainte să scriu ceva, în loc să aleg tăcut varianta care semăna. Pe altul, adresa trebuia asamblată din cinci coloane sursă. Concatenarea naivă lasă spații duble oriunde o coloană e goală, așa că fiecare fragment își poartă propriul spațiu de după în interiorul verificării de null și contribuie doar dacă există cu adevărat. Asta e textura acestei munci: zeci de decizii mărunte, fiecare invizibilă când e corectă și permanentă când e greșită.

Eșecurile care contează sunt tăcute. Un script care citește suma implicită definită pe tipul unei taxe în loc de suma înregistrată pe elementul individual va importa o categorie întreagă de taxă ca sumă zero, iar din afară nimic nu arată greșit: toate rândurile sunt acolo, iar totalurile se potrivesc cu o sursă citită greșit în exact același fel. Tabelele de opțiuni care conțin rânduri globale, neaparținând niciunui tenant, vor scrie în tăcere, dacă filtrezi doar pe tenant, stări pe care niciun dropdown din destinație nu le oferă. Un drept de acces fără coloană de tenant înseamnă că o revocare scrisă pentru o organizație ajunge la conturile de personal din toate celelalte organizații unde acei oameni lucrează. Iar destinația continuă să genereze identificatori proprii în timp ce importul rulează, așa că numerotarea trebuie verificată de două ori: o dată când se scrie scriptul și încă o dată în tranzacția care scrie.

Unele înregistrări rămân pe loc în mod deliberat, iar cifra aceea trebuie publicată alături de cea migrată. Raportată separat, mai târziu, se citește ca ceva pierdut, nu ca o decizie luată.

Ce face munca repetabilă nu sunt scripturile, ci cadrul din jurul lor. O verificare preliminară construită exact ca importul pe care îl păzește, ca să măsoare aceleași rânduri, nu un strat de deasupra lor. Mai mult de un recenzent, fiindcă la ultima migrare trecerea mea a găsit trei defecte serioase, iar un al doilea recenzent a mai găsit trei pe care nu le văzusem. Și un rollback care chiar a fost rulat cap-coadă pe volume reale, fiindcă un rollback pe care nu l-a executat nimeni e un paragraf într-un document, nu o cale de întoarcere.