Migreringsplanen: vad som migreras, och när

Det som avgör om en driftsättning blir lugn eller kaotisk är sällan själva ETL:en, utan om någon, veckor i förväg, skrev ner exakt vilken data som flyttas in i det nya systemet — och vilken dag.

Det de flesta kallar en "migreringsplan" är egentligen ett fältmappnings-Excel: den här källkolumnen ska till det där målfältet. Den mappningen är viktig — den är ett av stegen i min 8-stegsmetod per dataobjekt — men den svarar bara på hur ett enskilt objekt översätts, inte på vad som flyttas när. Migreringsplanen ligger ett steg ovanför: den övergripande tidslinjen över alla dataobjekt — vad som laddas när, vem som fryser vad, och när verksamheten måste sluta skapa data i det gamla systemet. Så här ser den ut.

En notis om beteckningarna: TGL är technical go-live — punkten där systemet är driftsatt, migrerat och klart ur ett IT-perspektiv, men innan användarna börjat. BGL, business go-live, är när verksamheten faktiskt går över och börjar jobba i det, ofta morgonen efter (TGL en söndag kväll, BGL måndag morgon). Alla avstånd här räknas bakåt från TGL, för det är datumet migreringen måste träffa.

Bulkladdning först, sedan deltaladdning

Du flyttar inte allt i en enda heroisk nattkörning. Du fasar in det.

En bulkladdning är den första fulla laddningen av ett objekt, gjord i god tid före go-live. En deltaladdning är allt som lagts till eller ändrats i källan sedan bulkladdningen — du kör i kapp differensen. Så du laddar master data veckor i förväg, låter folk fortsätta jobba i det gamla systemet och accepterar att din kopia blir inaktuell direkt. Det är okej: att köra i kapp differensen är precis vad deltat är till för. Nära go-live migrerar du transaktions- och lagerdatan — de öppna ordrarna plus lagersaldon och lagervärde — stämmer av och går live.

Att fasa in det så förvandlar en omöjlig natt till en serie hanterbara steg — och, viktigast, det låter dig repetera. En bulkladdning du kan köra en månad i förväg är en bulkladdning du kan köra två gånger.

Master data och transaktioner fryses på olika datum

Det här är den del de flesta planer missar, och hela anledningen till att planen behöver datum snarare än en checklista.

Master data — artiklar, kunder, leverantörer, priser, produktstrukturer — är stabilt och förlåtande. Det ändras, men långsamt och förutsägbart, vilket är varför ett delta hanterar det bekvämt. Så du kan frysa det tidigt: säg en vecka före go-live, inga nya artiklar, inga kundändringar. Precis innan frysen kör du en sista deltaladdning av all master data, så att den frusna kopian är komplett och aktuell — därefter är master data klart, och själva cutovern behöver bara flytta transaktioner.

Transaktionsdata — öppna ordrar, balanser, dokument i rörelse — lever ända in i det sista. En post som var rätt på tisdagen är fel på fredagen. Så den får en senare, egen brytpunkt, några dagar ut: fönstret där verksamheten slutar skapa nya ordrar och tar hand om de öppna. Konkret i en retail-miljö: lager och butiker måste göra färdigt all godsmottagning före brytpunkten, och efter det datumet får de inte göra några lagerflyttar eller andra transaktioner i systemen. Det är en skarp, fysisk deadline — inte en mjuk rekommendation.

Två datatyper, två frysdatum. Säg båda till verksamheten tidigt och tydligt, för det är reella operativa begränsningar — folk kan inte bara fortsätta jobba som vanligt — och alla kommer att glömma vilket datum som gäller vad. En frys är inte en teknisk händelse. Det är ett beslut om när användarna måste sluta skapa och ändra data, och det ägs av verksamheten, inte av migreringsteamet.

Det renaste sättet att migrera ett svårt objekt är att inte migrera det

De svåraste objekten att migrera är öppna transaktioner. Så töm dem i verkligheten före transaktionsstoppet, så finns det inget kvar att migrera.

På en nyligen genomförd retail-driftsättning var regeln för öppna kundordrar precis den: lagret tog ägarskap för att rensa bordet — skeppa allt skeppbart, avbryt varje rad som inte ska skeppas — så att det på migreringsdagen i praktiken inte fanns några kvar att ta med. Det stökigaste dataobjektet löstes operativt, av dem som äger processen, inte tekniskt, av ett skript. (För ett konkret exempel på vad "öppen" verkligen betyder på radnivå — delvis mottagen, delvis fakturerad — se migrera data till Infor M3.)

Det är tankeskiftet: en del av dina värsta dataproblem är inte dataproblem. En restorder är verklig kundefterfrågan — du kan inte bara "stänga" den i ett skript utan att antingen tappa efterfrågan eller knappa in den på nytt i det nya systemet, och det är ett verksamhetsbeslut, inte en ETL-regel. Så du skjuter de besluten till processägarna, tidigt, och krymper den tekniska migreringen till bara det som verkligen måste flyttas.

Planen är en daterad runbook med namngivna ägare

Lägg ihop de två idéerna och artefakten skriver nästan sig själv. För varje dataobjekt, en rad:

• vad det är (kunder, öppna inköpsordrar, ingående balanser i huvudboken),
• hur det flyttas (bulk, delta, eller "stängt i källan, migreras inte"),
• när — kalenderdagen relativt go-live,
• vem som äger det — en namngiven person, inte ett team.

Det är planen. Inte ett mappnings-Excel — en runbook. Och den är medvetet ett pågående arbete: du utkastar den tidigt, går igenom den med verksamheten, upptäcker att ekonomiavslutet behöver en extra dag för fakturamatchning, att restordrar inte har någon tydlig ägare, att historik som ingen kommit överens om att arkivera tyst antas migrera. Var och en av dem är en fråga du vill svara på i ett planeringsmöte, inte klockan tre på cutover-natten.

Stäm av varje körning också — på värde, inte bara radantal, så att du fångar laddningen som "lyckades" men bar fel siffra. Det förtjänar en egen genomgång: bevisa att migreringen blev rätt.

Vad du ska ta med dig

Teamen som kämpar behandlar migrering som en teknisk lift-and-shift och möter verksamhetsfrågorna på cutover-natten. Teamen som glider igenom har redan tagit de obekväma samtalen — vilket är frysdatumet för master data, vilket är transaktionsstoppet, vem rensar restordrarna, var bor historiken egentligen — veckor tidigare, när det fortfarande fanns tid att svara på dem.

Bestäm tidigt vad som flyttas och när, ge master data och transaktioner var sitt frysdatum, och rensa de svåraste objekten i verkligheten innan du migrerar något. Skriv ner det som en daterad runbook med namngivna ägare.

Gör det tråkiga planeringsarbetet. Migreringen är den enkla biten.

Står du inför en driftsättning och vill ha en migreringsplan som håller på natten? Hör av dig — jag delar gärna med mig av hur jag arbetar.

---

Vidare läsning: Migrera data till Infor M3 · Migrera data till Business Central med RapidStart · Big bang eller fasad migrering · Avstämning: bevisa att migreringen blev rätt.