Sådan kommer du ud af dit legacy-system
Udskift et legacy-system trinvis i stedet for i én stor omlægning. Med strangler fig-mønstret erstatter du én funktion ad gangen mens det gamle system lever videre, hvilket holder risikoen lav og driften kørende. Kortlæg skjulte afhængigheder og tavs viden først, og beskyt forretningskontinuiteten gennem hele overgangen.
Et legacy-system er sjældent i stykker. Det er netop derfor det stadig er der. Det virker, forretningen stoler på det, og ingen tør rigtig røre ved det. Men gammel teknologi bliver dyrere at vedligeholde, sværere at bemande og til sidst en bremse for alt nyt I vil gøre. Spørgsmålet er ikke om I skal ud af det, men hvordan I gør det uden at standse forretningen undervejs.
Hvorfor trinvis næsten altid slår big bang
Den fristende plan er en ren omlægning: Byg det nye system færdigt, vælg en weekend, flyt alt over og sluk det gamle. På papiret er det hurtigt og enkelt. I virkeligheden er det noget af det mest risikable en organisation kan gøre.
Problemet er at en big bang-migrering ikke kan afprøves i skarp drift før i det øjeblik hvor alt skal fungere. Et enkelt overset specialtilfælde kan så stoppe fakturering, ordrer eller produktion, uden nogen nem vej tilbage. Trinvis migrering vender regnestykket om: Du flytter lidt ad gangen, verificerer i reel brug og har altid det gamle system i baghånden som sikkerhedsnet.
Strangler fig-mønstret: erstat bid for bid
Den gennemprøvede metode til det kaldes strangler fig-mønstret. Idéen er at det nye system vokser rundt om det gamle og overtager én funktion ad gangen indtil det gamle til sidst ikke laver noget og kan lukkes ned.
I praksis foregår det sådan her:
- Sæt en dirigent foran. Et lag der sender hvert kald enten til det gamle eller det nye system.
- Flyt en afgrænset funktion. Vælg noget med klare grænser, f.eks. en rapport eller et flow, og byg det på ny.
- Omdirigér trafikken. Lad dirigenten pege netop den funktion mod det nye system, og sæt den i skarp drift.
- Verificér og gå videre. Virker det, så tag den næste funktion. Driller noget, så peg tilbage mod det gamle.
- Sluk det gamle. Når intet længere peger derhen, kan legacy-systemet afvikles i ro og mag.
Hvert trin er lille nok til at forstå, teste og om nødvendigt rulle tilbage. Risikoen spredes ud over tid i stedet for at blive koncentreret i én skæbnesvanger nat.
Kortlæg skjulte afhængigheder og tavs viden
Den største fare ved gamle systemer er ikke den kode du ser, men den du ikke ved findes. Efter mange år er der ofte vokset integrationer, natlige jobs, eksportfiler og undtagelser frem som aldrig er blevet dokumenteret.
| Hvad du leder efter | Hvor det ofte gemmer sig |
|---|---|
| Integrationer til andre systemer | Planlagte jobs, filoverførsler, gamle API’er |
| Forretningsregler og specialtilfælde | I koden og i hovedet på erfarne brugere |
| Rapporter og eksporter | Manuelle rutiner der køres ved månedsskift |
| Adgangsrettigheder og undtagelser | Udokumenterede løsninger for enkelte afdelinger |
Teknisk analyse finder en del, men langtfra alt. Meget af logikken lever som tavs viden hos få personer. Sæt dig sammen med dem der bruger systemet hver dag, og spørg hvad det gør som ingen har skrevet ned. Den time sparer uger med fejlsøgning senere.
Hold forretningen kørende hele vejen
Et konkret eksempel: En virksomhed skulle udskifte sit gamle ordresystem. I stedet for at skifte alt på én gang flyttede de først kun ordreregistreringen mens lager og fakturering blev i det gamle. Da den del havde bevist sit værd i skarp drift i nogle uger, tog de den næste. Forretningen kørte videre under hele forløbet, og da det gamle system til sidst blev slukket, var det en ikke-begivenhed.
Sådan skal en migrering føles: udramatisk. Planlæg overgange til roligere perioder, hav altid en vej tilbage, og kommunikér tydeligt med dem det berører.
Hvorfor gamle systemer får lov at leve for længe
Et rimeligt spørgsmål er hvorfor man ikke bare skifter i tide. Svaret er at et legacy-system sjældent udløser en tydelig krise. Det forfalder langsomt. Udgifterne til at vedligeholde det stiger gradvist, kompetencerne til at passe det bliver stadig sværere at finde, og hver ny idé tager længere tid at gennemføre fordi det gamle fundament står i vejen. Ingen enkelt dag føles akut nok til at begrunde et skifte, og så bliver det udskudt år efter år.
Netop derfor er det værd at træffe beslutningen før man bliver tvunget til det. En planlagt, trinvis migrering er altid tryggere end en nødevakuering når det gamle system til sidst bryder sammen eller den sidste person der forstår det, siger op. At begynde mens systemet stadig virker, giver dig roen til at flytte i dit eget tempo.
Tag et lille skridt først
Den bedste måde at komme ud af beslutningslammelsen på er at gøre migreringen lille og konkret. Udvælg én enkelt afgrænset funktion, flyt den efter strangler fig-mønstret og lær af forløbet. Det første skridt beviser at metoden virker i netop jeres miljø, afslører de skjulte afhængigheder I overså, og opbygger tillid til at resten kan gøres på samme måde.
Har I brug for hjælp til at kortlægge et gammelt system og lægge en migreringsplan der holder forretningen kørende, laver vi hos Weapp gerne en teknisk gennemlysning og kan derefter drive migreringen i kontrollerede trin.
Ofte stillede spørgsmål
Hvad er strangler fig-mønstret?
Det er en migreringsstrategi hvor du bygger det nye system rundt om det gamle og flytter én funktion over ad gangen. Trafikken omdirigeres gradvist indtil det gamle system ikke længere bruges og kan lukkes ned. Navnet kommer fra kvælerfigen, der vokser rundt om sit værtstræ indtil den overtager det helt.
Hvorfor er big bang-migrering så risikabel?
Fordi alt skiftes på én gang, kan det ikke testes i skarp drift før hele systemet skal tages i brug. En enkelt uventet fejl kan stoppe hele forretningen, og der er ingen nem vej tilbage. Trinvis migrering begrænser hver risiko til en lille del og bevarer altid en fungerende fallback.
Hvordan finder vi skjulte afhængigheder i det gamle system?
Kombinér teknisk kortlægning med interviews. Gamle systemer har ofte integrationer, planlagte jobs og specialtilfælde som ingen har dokumenteret. Tal med dem der bruger systemet dagligt. Meget af logikken lever som tavs viden hos få personer snarere end på skrift.
Kan forretningen fortsætte som normalt under migreringen?
Ja, det er hele pointen med en trinvis tilgang. Fordi det gamle system lever videre indtil hver del er erstattet og verificeret, mærker brugerne sjældent skiftet. Planlæg overgange til roligere perioder, og hav altid en vej tilbage hvis en delmigrering ikke opfører sig som forventet.
Hvor lang tid tager en legacy-migrering?
Det afhænger helt af systemets størrelse og hvor indviklet logikken er, men trinvis migrering tager bevidst længere kalendertid end big bang. Til gengæld er risikoen lavere, og forretningen kan bruge systemet hele vejen. Se det som en kontrolleret udfasning over måneder snarere end en enkelt weekend.