Modernisering af gammelt system, én funktion ad gangen

Mange virksomheder kører forretningen på et system, der blev bygget for mange år siden. Det virker stadig, men ingen tør røre det. Den oprindelige udvikler er væk, serveren kører en version, der ikke længere får sikkerhedsopdateringer, og hver ny medarbejder skal læres op i genveje og workarounds. Denne side handler om, hvordan I kommer videre uden et big bang, der lukker driften ned i en uge, og uden at I betaler for at bygge det samme system igen med de samme fejl.

Hvornår er det tid til at udskifte et legacy system?

• Små ændringer tager uger, fordi ingen kender koden, og alle er bange for at ødelægge noget
• Systemet kører på software eller servere, der ikke længere bliver sikkerhedsopdateret
• Medarbejderne fører data i Excel ved siden af, fordi systemet ikke kan det, de har brug for
• Det kan ikke tale med jeres nye værktøjer, fx regnskab, CRM eller betaling
• Kun én person ved, hvordan det virker, og den person er på vej på pension eller er allerede væk

Genopbyg, refaktorer eller læg et API udenpå?

Der er grundlæggende fire veje. Valget afhænger mindre af teknologien og mere af, hvor sund datamodellen er, og hvor meget af forretningslogikken der stadig passer til den måde, I arbejder på i dag. Et system med rigtige data og forkerte skærme skal behandles helt anderledes end et system, hvor selve strukturen er forkert.

Sådan virker den faseopdelte udskiftning

Udviklere kalder det ofte strangler-mønsteret, opkaldt efter en figenplante, der vokser rundt om et træ, indtil træet kan fjernes. Det nye system bygges ved siden af det gamle og overtager en afgrænset funktion ad gangen. Brugerne mærker en række små skift i stedet for én stor skiftedag.

Datamigrering: det svære er ikke at flytte data

At kopiere tabeller fra en database til en anden er hurtigt. Det tidskrævende er at finde ud af, hvad data faktisk betyder. Felter, der hedder én ting og bruges til noget andet, dubletter af kunder, statusser ingen længere kan forklare, og fritekstfelter med halvdelen af forretningen i. Derfor starter vi altid med en prøvemigrering på en kopi af rigtige data, længe før skiftet.

• Beslut hvad der skal med, og hvad der kun skal arkiveres
• Ryd op i dubletter og døde statusser før migreringen, ikke efter
• Kør migreringen flere gange som script, så den kan gentages på skiftedagen
• Lad nøglebrugere tjekke stikprøver: kan de genkende deres egne kunder og ordrer?

Kan gammelt og nyt system køre parallelt?

Ja, og det er ofte den sikreste måde. I en periode skriver det nye modul data, mens det gamle system stadig kan læse dem, eller omvendt. Det kræver en klar regel om, hvilket system der er "sandheden" for hver type data, så ingen retter den samme ordre to steder. Parallel drift skal have en slutdato. Ellers ender I med at vedligeholde to systemer i stedet for ét.

Risici ved at udskifte et gammelt system

Hvad koster det at modernisere et gammelt system?

Det afhænger af, hvor mange moduler der skal flyttes, og hvor rodede data er. Vi har ikke en fast listepris for modernisering. I får en skriftlig fastpris pr. fase inden for 24 timer, når vi har set systemet. Som pejlemærke kan et afgrænset første modul holdes op mod vores webapp-pakker, der starter ved 18.000 kr. + 600 kr./md. med 12 funktioner og én integration. Er I i tvivl om, hvorvidt I overhovedet skal have noget skræddersyet, så læs skræddersyet software vs. standardsystem først.

Vi har bygget portaler, der samler data og arbejdsgange fra flere kilder, blandt andet IT-supportportalen til Mannaz og kundeportaler til Grundfos iGRID. Den nye kode er React, Next.js og TypeScript, og I ejer både kode og data. Læs mere om, hvordan vi bygger webapps.