I början av en legacy-migrering ser tidsplanen alltid rimlig ut. Det gamla systemet är förstått, åtminstone av de personer som byggde det. Det nya systemet är designat. Omfattningen är definierad. Sex månader är en optimistisk uppskattning, men inte en orimlig sådan. Tolv månader är konservativt. Arton skulle vara pinsamt att erkänna för ledningen.
Tre år senare pågår migreringen antingen fortfarande, har i tysthet ställts in, eller har slutförts i en form som krävde så många kompromisser att en del av de ursprungliga problemen helt enkelt reproducerades i den nya kodbasen. Detta är inget ovanligt utfall. Det är det allra vanligaste.
Förklaringen som de flesta team tar till är teknisk: det gamla systemet var mer komplext än förväntat, den nya plattformen hade oväntade begränsningar, datamodellen kunde inte mappas rent. Detta är sant, och det bidrar till tidsåtgången. Men det är inte anledningen till att migreringar tar tre år. Anledningarna är nästan uteslutande organisatoriska.
Systemet du byter ut är aldrig fullt förstått
Legacy-system ackumulerar affärslogik på samma sätt som gamla byggnader ackumulerar bärande väggar. Något lades till för att hantera ett edge case 2009. Något annat patchades för att hantera ett kundundantag 2013. En beräkning justerades något 2017 eftersom någon märkte att siffrorna var fel på ett sätt som ingen riktigt kunde förklara. Personen som gjorde varje ändring kanske inte längre jobbar kvar på företaget. Anledningen till att det fungerar som det gör finns ofta inte nedskrivet någonstans.
Discovery-fasen av en migrering — den del där man tar reda på vad det gamla systemet faktiskt gör — är nästan alltid underscoped. Team ägnar två veckor åt discovery innan de påbörjar designen, hittar inga uppenbara överraskningar och drar slutsatsen att systemet är väl förstått. Sedan tillbringar de de kommande arton månaderna med att hitta överraskningar.
Ett mer ärligt tillvägagångssätt är att utgå från att legacy-systemet innehåller ungefär tre gånger så mycket odokumenterad affärslogik som någon för närvarande tror, och att planera discovery därefter. I praktiken innebär detta att man kör det gamla och det nya systemet parallellt längre än vad som känns bekvämt, accepterar att vissa edge cases endast kommer att dyka upp när riktiga användare stöter på dem i produktion, och behandlar legacy-systemets beteende som specifikationen snarare än kravdokumentet.
Personerna som kan det gamla systemet är aldrig fullt tillgängliga
Ämnesexperterna för en legacy-migrering — personerna som förstår varför systemet beter sig som det gör — är nästan alltid samma personer som ansvarar för den dagliga verksamheten. De kan inte helt omplaceras till ett migreringsprojekt utan att verksamheten som finansierar projektet försämras.
Det som vanligtvis händer är en kompromiss: ämnesexperter deltar i workshops, svarar på frågor vid behov och granskar leveranser när de har tid. Detta fungerar ganska bra under de tidiga stadierna, när frågorna är strategiska. Det blir en flaskhals under implementeringen, när frågorna är specifika: vad ska hända när detta fält är null? Är detta beteende avsiktligt eller en bugg? Vad betyder denna statuskod i kontexten av just detta workflow?
Dessa frågor är inte svåra. Var och en tar tio minuter att besvara. Men det finns tusentals av dem, de uppstår oförutsägbart, och var och en av dem kan blockera en sprint om rätt person inte är tillgänglig. Migreringen bygger upp väntetid i små inkrement som aldrig dyker upp som enskilda blockeringar i en statusrapport, men som sammantaget står för månader av kalendertid.
Samsynen bland intressenterna eroderar
Chefen som sponsrade migreringen hade ett tydligt motiv: minska driftskostnaderna, eliminera teknisk skuld, möjliggöra funktioner som det gamla systemet inte kunde stödja. Detta motiv var tillräckligt övertygande för att säkra en budget och en tidsplan. Arton månader in i projektet har denna chef gått vidare till en annan roll. Deras efterträdare ärvde projektet utan att ärva övertygelsen som motiverade det.
Detta är inte ett misslyckande hos individer. Det är en strukturell egenskap hos hur lång tid migreringar tar i förhållande till hur ofta organisationer förändras. Ett treårigt projekt kommer i genomsnitt att överleva anställningstiden för personen som beställde det. När det händer förlorar projektet sin organisatoriska sponsor i exakt det ögonblick då det som mest sannolikt behöver en — under den svåra mellanfasen när det gamla systemet fortfarande är igång, det nya systemet ännu inte är klart, och teamet ber om mer tid och pengar för att överbrygga klyftan.
De migreringar som överlever denna övergång är de som har ett distribuerat sponsorskap — där tillräckligt många personer på tillräckligt många nivåer förstår varför projektet finns för att det ska kunna överleva att en enskild förespråkare slutar. Detta är svårare att skapa än en enskild exekutiv sponsor och växer sällan fram naturligt. Det måste byggas upp medvetet, vanligtvis genom regelbunden kommunikation till en bredare målgrupp än projektets kärnteam.
Åttio procent klart är en fälla
Den farligaste milstolpen i en migrering är åttio procent klart. Vid den tidpunkten hanterar det nya systemet alla vanliga fall. De huvudsakliga workflows fungerar. En rimlig demo kan genomföras. De återstående tjugo procenten är en lista med edge cases, undantag och ovanliga scenarier som har skjutits upp för att hålla huvudspåret i rörelse.
Dessa tjugo procent representerar den samlade komplexiteten från år av produktionsanvändning. Varje punkt på listan finns där för att en riktig användare stötte på en verklig situation som standard-workflowet inte hanterade. Tillsammans kodar de in större delen av den institutionella kunskapen om hur verksamheten faktiskt fungerar i motsats till hur den är tänkt att fungera.
Att arbeta sig igenom dem är långsamt, eftersom varje punkt kräver samma cykel: förstå det ursprungliga scenariot, designa hanteringen, implementera den, validera den mot personerna som kan domänen. Det finns inga skalfördelar. Det hundrade edge caset är inte snabbare att hantera än det första. Och listan krymper inte i en jämn takt — den tenderar att växa allteftersom det nya systemet prövas i större utsträckning och för upp scenarier till ytan som man tidigare inte visste existerade.
Team som når åttio procent enligt tidsplanen upptäcker ofta att de återstående tjugo procenten tar lika lång tid som de första åttio. Detta är inte ett planeringsmisslyckande. Det är en matematisk egenskap av var komplexiteten i dessa system bor.
Vad de migreringar som blir klara har gemensamt
De legacy-migreringar som faktiskt blir klara delar några egenskaper som inte är uppenbara från början.
De behandlar cutover som en händelse att designa, inte som en tröskel att passera. Ögonblicket då det gamla systemet stängs av och det nya systemet blir system of record är den största riskpunkten i hela projektet. Organisationer som uttryckligen planerar för denna händelse — vem som kan göra rollback, under vilka omständigheter, vem som fattar beslutet, vad som utgör en framgångsrik första vecka — har mycket större chans att navigera den utan en kris som backar bandet för tidsplanen med ytterligare sex månader.
De kör det gamla och det nya systemet parallellt under en längre tid än de hade planerat. Detta är dyrt och driftmässigt obekvämt. Det för också upp de edge cases till ytan som automatiserade tester inte fångar, innan de blir produktionsincidenter i ett system som inte längre har någon fallback.
De avgränsar migreringen för att leverera värde inkrementellt i stället för att färdigställa den i en enda cutover. De värsta migreringarna är de där ingenting kan avvecklas förrän allt är färdigt. De bästa identifierar vilka delar av det gamla systemet som kan pensioneras oberoende av varandra och sekvenserar arbetet för att leverera synliga vinster innan projektet är tre år gammalt.
Och de är ärliga, tidigt, om hur tidsplanen faktiskt ser ut. Inte för att mörka, utan för att en organisation som vet att ett projekt kommer att ta tre år kan strukturera sig för att hålla ut. En organisation som tror att ett projekt kommer att ta sex månader, och gång på gång får höra att det nästan är klart, förlorar tålamodet i en takt som projektet inte kan överleva.