Ved gradvis udskiftning flytter I produktet over på ny teknologi stykke for stykke, mens det hele tiden er i drift. Begynd med et afgrænset stykke, der giver mening at flytte, og som ikke er det mest kritiske. Sæt et lag foran, der styrer, om hver forespørgsel går til det gamle eller det nye, og aftal fra starten, hvornår det gamle slukkes. Metoden fungerer, så længe flytningen bliver ved. Den fejler, når I ender med to systemer for altid. Om I skal vælge denne vej, afgøres i skal produktet skrives om?. Her handler det om, hvordan den udføres.
Metoden kort
Fagfolk kalder mønstret strangler fig efter en figen, der vokser op omkring et værtstræ og efterhånden står alene. Det nye vokser rundt om det gamle, indtil det gamle kan fjernes.
Tre ting skal være på plads. Et skæringspunkt, hvor forespørgsler kan sendes den ene eller anden vej, for eksempel et lag foran produktet eller et sted i brugerfladen. Klare grænser for, hvad der flyttes. Og en måde at sammenligne gammelt og nyt på, så I ved, at de gør det samme.
Det første stykke
Det første stykke skal bevise vejen, og det bør derfor have disse egenskaber:
- Afgrænset. Få forbindelser til resten af produktet og helst sine egne data.
- Virkelig i brug. Det skal bruges af rigtige kunder, ellers lærer I intet om drift.
- Med en gevinst. Et område, der ændres ofte, eller hvor en kommende funktion ellers ville være besværlig.
- Tåleligt, hvis det går galt. Fakturering og forretningens kerne venter til senere.
Gode kandidater er tit rapporter, notifikationer, en administrationsside eller en enkelt integration. Det kritiske kommer, når teamet har lært metoden. Bed teamet om at foreslå tre muligheder og forklare, hvad hver af dem vil lære jer. Er området for rodet til at skille ud, skal det først gøres sikkert at ændre, se artiklen om kode, ingen tør røre.
To systemer side om side
Perioden med begge systemer er den sværeste del, og den varer længere, end I håber. Aftal fire regler, før I begynder.
Hvem ejer data? For hvert stykke data skal der være ét sted, der er det rigtige. To systemer, der begge skriver i de samme tabeller, er en klassisk kilde til problemer. Har det gamle og det nye brug for de samme data, skal det ene have dem fra det andet, med en fast retning.
Ingen nye funktioner i det, der flyttes. Et stykke, der er under flytning, må ikke samtidig ændre sig i det gamle. Det kræver disciplin af salg og produktansvarlig.
Sammenlign før skiftet. I en periode kan begge systemer regne på samme input, mens kun det gamle svarer kunden. Forskellene viser jer de skjulte regler, I havde overset.
Hav en vej tilbage. Flyt en lille gruppe kunder først, og vær i stand til at sende dem tilbage inden for få minutter. Går det godt, flyttes resten.
Rytme og styring
Sæt rytmen, så teamet flytter noget med faste mellemrum, og giv et af de stærke teams ansvaret. Bliver det en opgave for dem, der lige har tid, går det i stå.
Følg arbejdet med én enkel måling: hvor meget af trafikken og af kundernes arbejde, der nu kører på det nye. Det er et mere ærligt billede end en liste over færdige opgaver. Sæt det på den tekniske køreplan, og vis det ved ledelsesmøderne. Rykker målingen sig ikke i løbet af nogle kvartaler, skal der tages en ny beslutning.
Forvent, at det sidste stykke er det sværeste. De lette dele flyttes først, og tilbage står den mest indviklede kerne og de kunder, der er sværest at flytte. Det er her, mange projekter stopper med begge systemer i gang.
Dagen, hvor det gamle slukkes
Det gamle slukkes ikke af sig selv. Planlæg det som en selvstændig opgave med egen ejer.
- Hvilke kriterier skal være opfyldt? Ingen trafik i en aftalt periode, alle kunder flyttet, alle job og integrationer fundet.
- Hvad skal gemmes? Data, som aftaler eller regler kræver opbevaret, skal arkiveres, og I skal vide, hvordan de hentes frem. Spørg revisor eller advokat, hvis der er tvivl.
- Hvad skal lukkes? Servere, adgange, nøgler, licenser, overvågning, dokumentation.
- Hvem skal have besked? Kunder, der stadig har en integration, support og de leverandører, der er involveret.
Sluk først for adgangen, vent, og slet derefter. Ofte dukker der et glemt månedligt job op. Fejr dagen, for teamet har arbejdet længe på noget, kunderne aldrig har set. Kunderne, der ikke vil med, har deres egen artikel.
Det skal I lade være med
- At begynde med den mest kritiske del for at vise mod · de første stykker skal lære teamet metoden.
- At lade begge systemer skrive de samme data · så bliver det uklart, hvad der er sandt.
- At holde op, når de lette dele er flyttet · to systemer er dyrere end ét gammelt.
Det skal I kræve af den eksterne
- ☐ Et forslag til første stykke med begrundelse.
- ☐ Klare regler for dataejerskab i overgangen.
- ☐ En enkel måling af, hvor meget der kører på det nye.
- ☐ Kriterier og en plan for slukning, fastlagt før arbejdet begynder.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Fra installeret software til SaaS · Tjeklister og skabeloner
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
