Hvornår skal et legacy-system skiftes ud — og hvornår ikke?

Legacy er et sløret ord. Nogle gange betyder det "skrevet i et sprog, de unge ikke vil røre". Nogle gange betyder det "den eneste kilde til sandhed om ordrer, kunder og lager". Det første er et rekrutteringsproblem. Det andet er jeres forretning. At blande de to er, hvordan omskrivninger spiser et år og stadig misser den ordretype, der betaler lønnen.

Modernisering sælges ofte som et teknologisk løft: ny ramme, nyt cloud, nyt UI. Det kan være rigtigt. Det er forkert som mål. Målet er, at I kan ændre en forretningsregel uden at bede den sidste person, der husker den, om at turde. Hvis I kan det i det gamle system — med tests, med dokumentation, med en afgrænset snitflade — er I allerede i gang med at modernisere, uden at have skiftet noget.

Omvendt: hvis I ikke kan ansætte ind, ikke kan integrere, ikke kan overholde en kontrakt, eller ikke kan slukke en manuel proces, der vokser med hver ny kunde, så er alder irrelevant. Så blokerer systemet. Så skal I handle. Handlingen er bare sjældent "byg det hele om bag et forhæng og skift over en weekend".

Det, I vælger her, er total cost of ownership over de næste år — ikke en følelse af at være moderne. En dyr omskrivning, der leverer et pænere UI oven på de samme uklare regler, er det dyreste sted at ende.

Den hyppigste smerte er viden, der sidder i hoveder. Koden er ikke nødvendigvis dårlig. Den er udokumenteret, uden tests, og den eneste, der har deployet den, er på ferie. Det er en drifts- og rekrutteringsrisiko. Den løses med karakteriseringstests, runbooks og parring — ikke automatisk med en ny stack.

Den næste er data, der kun er sande i det gamle system. Ordrer, priser, serienumre, kundekort. Alt nyt I bygger, skal enten læse derfra eller overtage sandheden. Hvis I ikke ved, hvilken tabel der vinder, når to systemer er uenige, er I ikke klar til at skifte. I er klar til at tegne et datakort.

Den tredje er kanterne: et UI, ingen kan holde ud, en integration der kun kører som natjob, en rapport der tager en formiddag, en onboarding der kræver tre mails til den interne specialist. Her er wrapping ofte det rigtige: et nyt lag foran, det gamle som kilde, indtil I har flyttet den ene strøm, der gør ondt.

Den fjerde er platformen selv: licenser I ikke kan forlænge, et OS der ikke får patches, en vendor der er væk, hardware I ikke kan købe. Det er en ægte deadline. Den retfærdiggør handling. Den retfærdiggør stadig ikke, at I omskriver forretningslogik, I ikke har karakteriseret.

Lad det stå, og reducer risikoen. Det er rigtigt, når kernen er stabil, smerten er sælden, og I kan isolere den med tests, overvågning og en navngiven ejer. "Lad det stå" uden ejer er bare udskydelse. Med ejer, backup og en plan for den dag det knækker, er det et voksent valg — især hvis I har vigtigere produktarbejde.

Wrap og strangle. I lægger et nyt lag omkring det gamle: et API, en portal, et nyt UI, en ny integration. Trafik og skrivninger flyttes strøm for strøm. Det gamle bliver mindre, indtil det kan slukkes eller efterlades som et arkiv. Det er rigtigt, når sandheden stadig bor i kernen, og I kan skære en snitflade. Det er forkert, når I wrapper uden at flytte skrivninger — så har I to sandheder og et synkroniseringsprojekt.

Erstat. I bygger det nye som kilden til sandhed for en afgrænset del, migrerer data, og slukker den del i det gamle. Det er rigtigt, når I kan pege på den del, når I har en cutover-plan, og når det gamle ikke kan bære den ændring, forretningen allerede har lovet. Det er forkert, når "erstat" betyder hele landskabet på én gang, fordi det føles renere på et slides.

De tre kan kombineres. Det, I ikke må, er at kalde et wrap for en erstatning, eller en erstatning for et "lille løft". Navngiv strategien. Så kan I sige nej til scope, der hører til en anden strategi.

Lad det stå, når blokeringen er hypotetisk, og kernen er sand. Et ældre ERP der faktisk afspejler lageret, er mere værd end et nyt UI der gætter. Jeres job er at gøre det mindre skrøbeligt: karakteriseringstests omkring de flows, I tør røre, overvågning på de jobs der fejler stille, og en runbook til den dag den sidste specialist er syg.

Lad det også stå, når I ikke har skåret en første strøm. Et erstatningsprojekt uden et v1-snit er et ønske om at være færdige med at skamme sig over stacken. Det er forståeligt. Det er ikke et projekt. Vent, indtil I kan sige: denne ordretype, denne rolle, denne integration — og alt andet venter.

Det, I ikke må, er at lade det stå uden at reducere risikoen. Ingen backups I har prøvet at genskabe, ingen dokumentation af de natjobs, ingen aftale om hvem der må ændre hvad. Det er ikke konservatisme. Det er at håbe, at ingenting går i stykker.

Hvis I senere skifter, har det arbejde stadig værdi. Tests og et datakort er det, en omskrivning ellers betaler dyrt for at genopdage. Modernisering starter ofte med at gøre det gamle forståeligt — ikke med at åbne et tomt repo.