Avstämning: att bevisa att migreringen blev rätt

Det kommer ett ögonblick sent i varje migrering då någon säger "laddningen gick rent – vi är klara." Det är en fälla. En ren laddning bevisar att datan gick in. Den säger ingenting om huruvida datan är rätt. Det som täpper till det gapet – och det som faktiskt får en migrering godkänd – är avstämning: att bevisa, med bevis, att det som landade i det nya systemet troget representerar det som lämnade det gamla.

Avstämning är den minst glamorösa delen av en migrering och den del revisorer och ekonomichefer bryr sig om mer än någon annan. Det är också där jag har sett flest "lyckade" migreringar i det tysta visa sig vara trasiga. Så här fungerar det faktiskt.

Varför "det laddades" inte är "det är korrekt"

En laddning kan lyckas och ändå vara fel på sätt ingen fellogg visar dig:

• Rader tyst tappade. Ett filter, en join som inte matchade, en avvisad batch du inte märkte – 1 000 000 rader lämnade, 998 400 anlände, och inget kastade ett fel.
• Värden felaktigt transformerade. Belopp laddade i fel valuta eller skalade med 100, datum med månad och dag omkastade, en statuskod mappad till fel målvärde. Varje rad är "giltig"; datan är nonsens.
• Dubblering. En omkörning som la till i stället för att ersätta, så att saldon är dubblerade.
• Trunkering och teckenkodning. Ett namn klippt till målfältets längd, å/ä/ö förvanskade av en teckenuppsättningskonflikt.

Var och en av dessa passerar en "laddades det"-kontroll. Avstämning finns för att fånga dem innan verksamheten gör det.

Avstämningens lager

Avstämning är inte en kontroll – det är en stapel, från billig-och-grov till precis-och-dyr. Du vill ha allt, eftersom varje lager fångar en annan klass av fel.

1. Postantal

Den första och grövsta frågan: kom samma antal saker över? Räkna källposter, räkna målposter, redovisa varje skillnad. Nyckelordet är redovisa – talen stämmer sällan exakt, och det är okej om varje gap är förklarat:

• Rader medvetet filtrerade utanför scope (avslutade konton, urgammal historik).
• Poster sammanslagna av dubblettrensning (tre dubblettkunder blev en – antalet sjunker med två, med flit).
• Rader legitimt avvisade och parkerade för åtgärd.

En oförklarad antalsskillnad är en defekt. En fullt avstämd antalsskillnad är bevis på kontroll. "Vi laddade 998 400 av 1 000 000; 1 400 var avslutade konton utanför scope och 200 dubblettrensades – här är listan" är precis hur bra ser ut.

2. Kontrollsummor

Antal fångar saknade rader; de missar felaktiga värden. För det summerar du sakerna som måste balansera och jämför källa mot mål:

• Finansiella summor – total kundreskontra, total leverantörsreskontra, saldobalanssummor, reskontrasummor per konto. Dessa måste stämma till öret.
• Kvantiteter – totalt lagerantal per lagerplats, total öppen ordervolym.
• Hash-summor – även summor av en i övrigt meningslös numerisk nyckel, för att upptäcka drift i fält som inte har en naturlig "summa".

Kontrollsummor är där fel-valuta-, fel-skala- och dubbleringsfel kommer upp till ytan, eftersom de flyttar summan även när varje enskild rad ser trovärdig ut.

3. Finansiell avstämning och bokslutet

För allt som rör ekonomi måste avstämningen tillfredsställa redovisningen, inte bara dataingenjörskonsten. De migrerade ingående balanserna måste stämma med legacy-systemets utgående balanser, reskontrorna (kund, leverantör, lager, anläggningstillgångar) måste stämma mot huvudboken, och det nya systemet måste kunna producera en saldobalans som balanserar. Det här är lagret revisorer granskar, och det är det som låter ekonomin lita på det första bokslutet på det nya systemet. Få det fel och migreringens problem landar rakt på ekonomichefens skrivbord.

4. Kontroller på urvals- och radnivå

Summor kan dölja kompenserande fel – ett konto för högt, ett annat för lågt, summan oförändrad. Så du drar också urval och jämför fält för fält, källrad mot målrad: högvärdeskonton, de största kunderna, ett slumpmässigt urval för täckning, och kända specialfall (kunden med skyddad identitet, ordern med varje frivilligt fält ifyllt). Det här är lagret som fångar det omkastade datumet och det trunkerade namnet som en summa seglar rakt förbi.

5. Verksamhets- och funktionsvalidering

Det sista lagret är ingen jämförelse alls – det är huruvida den migrerade datan fungerar. Kan ekonomin köra bokslutet? Kan en användare lägga en order mot en migrerad kund och få den att bokföras korrekt? Producerar rapporterna verksamheten faktiskt förlitar sig på vettiga tal? Det är acceptanstestets jobb, och det validerar att datan inte bara är troget kopierad utan användbar.

Gör det till bevis, inte känsla

Resultatet av avstämning är inte "ser bra ut" – det är ett underlag: en avstämningsrapport som anger, per objekt, vad som var i scope, käll- och målantalen, kontrollsummorna och eventuell förklarad avvikelse, den finansiella avstämningen och urvalsresultaten. Den signeras av de som äger datan, inte bara de som flyttade den. Den rapporten är vad som förvandlar "lita på oss" till "här är beviset", och det är vad revisorn kommer att be om.

Tre saker gör den pålitlig:

• Stäm av mot källan, inte mot sig själv. Att räkna din egen output bevisar ingenting; jämförelsen måste vara mot legacy-systemet.
• Automatisera det och kör det varje provkörning. Avstämning du bara gör en gång, på slutet, är avstämning du inte hinner åtgärda. Bygg kontrollerna tidigt, kör dem på varje provladdning, och se avvikelserna krympa mot driftsättning – den trenden är din beredskapssignal.
• Definiera "acceptabelt" i förväg. Finansiella summor stämmer till öret; vissa beskrivande fält kan tolerera en känd, dokumenterad avvikelse. Kom överens om trösklarna med verksamheten och ekonomin före driftsättning, inte i diskussionen efteråt.

Var det sitter i projektet

Avstämning är inte en fas på slutet – det är ett ramverk du bygger tidigt och kör kontinuerligt. Varje provkörning producerar en avstämningsrapport; avvikelserna talar om vad som fortfarande är trasigt; du åtgärdar mappningen eller tvätten och kör igen. Vid den riktiga driftsättningen är avstämning inte en nervös upptäckt – det är bekräftelsen av något du redan bevisat tre gånger. Den upprepade, belagda överensstämmelsen mellan källa och mål är, till slut, den enda ärliga definitionen av en lyckad migrering.

En ren laddning är ett påstående. Avstämning är beviset. Godkänn inte påståendet.

Planerar du en migrering och vill ha avstämning inbyggd från start, inte påklistrad på slutet? Hör av dig – jag delar gärna med mig av hur jag arbetar.

---

Vidare läsning: Varför datamigreringar misslyckas och De första 30 dagarna i ett migreringsprojekt.