Opgraderingen – fra nødvendig ondskab til strategisk mulighed

Opgraderingen er ikke et spørgsmål om 1:1 – men om kontrol

Et af de spørgsmål jeg oftest hører, når vi taler opgraderinger, er:

“Kan vi opgradere alt - altså 1:1?”

Det rigtige spørgsmål er ikke om 1:1 - det er om vi forstår konsekvenserne.

I praksis stiller Microsoft rigtig gode redskaber til rådighed, så vi som partner reelt set kan konvertere funktionalitet 1:1. Jeg har ofte brugt disse redskaber, men kun anbefalet det, hvis det giver forretningsmæssig mening.
En opgradering er i mine øjne en oplagt mulighed for at stille et mere værdifuldt spørgsmål:

Når vi arbejder struktureret, kan både 1:1-konvertering og målrettede forbedringer gennemføres kontrolleret og sikkert. Det kræver blot, at vi flytter fokus fra kode til adfærd og processer. Det kan også give mening at rydde op i gammel kode og struktur, og derefter konvertere 1:1.
Mulighederne er mange og processen bør være drivankeren i opgaven.

Når vi tester, som forretningen arbejder

Her kommer BDD – Behavior Driven Development ind i billedet.

I stedet for at tage udgangspunkt i historisk kode og gamle tekniske detaljer, tager BDD udgangspunkt i hvordan forretningen reelt bruger systemet i dag – og giver samtidig mulighed for med jævne mellemrum at gentænke arbejdsgange og processer.

Fokus er altså ikke på, hvordan løsningen er bygget for år tilbage, men på hvordan systemet skal opføre sig i praksis, når det understøtter forretningen her og nu.

Det betyder, at krav og forventninger formuleres som konkrete forretningsscenarier, for eksempel:

• Givet en bestemt forudsætning

• Når en bruger udfører en handling

• Så skal systemet reagere på en bestemt måde

Det er et sprog, som både forretning og IT kan forstå – og blive enige om.

I praksis betyder det også, at vi ofte starter med 1:1 datakonvertering, så alle data flyttes sikkert med i skyen.
Forretningslogikken derimod genopbygges og valideres trin for trin med BDD, så den afspejler den måde, systemet faktisk skal bruges fremadrettet – ikke nødvendigvis den måde, det engang blev bygget på.

Få tests – men de rigtige

I en Business Central-løsning er det hverken realistisk eller fornuftigt at teste alt manuelt, hver gang der ændres noget. Ingen udvikler, og ingen kunde, tester en hel applikation, blot fordi der er løst én enkelt opgave.

Med BDD udvælger vi i stedet de forretningskritiske scenarier, som absolut ikke må ændre adfærd.

Det kan for eksempel være 30, 40 eller 50 tests – men det er de vigtigste 50.

Og det afgørende er dette:
Disse tests lever videre sammen med løsningen. De bliver ikke kasseret efter godkendelsen, men bliver en fast del af appen og køres automatisk igen og igen.

Kvalitet der vokser over tid

Hver gang der ændres noget – ved ny funktionalitet, oprydning i kode eller en opgradering – bliver de samme forretningsscenarier testet igen.

Det betyder:

• at tidligere funktionalitet ikke forsvinder i stilhed

• at fejl opdages tidligt

• og at løsningen kan udvikles videre med langt større sikkerhed

Det er kvalitetssikring i en helt anden liga – QA i n. potens – fordi viden om forretningen er indbygget i løsningen og ikke kun ligger i hoveder eller dokumenter.

Oprydning uden at miste fodfæste

Det er netop denne tilgang, der gør det muligt at arbejde struktureret med både opgraderinger og videreudvikling.

Når forretningskritiske scenarier er beskrevet og testet, bliver de et fast referencepunkt for al fremtidig udvikling. Hver ændring – stor som lille – kan vurderes op imod den adfærd, systemet skal bevare.

Det skaber en kontinuerlig cyklus, hvor tests, udvikling og forbedringer hænger sammen, og hvor kvalitet ikke er noget, der tilføjes til sidst – men noget, der bygges ind fra starten.

Når vi tager udgangspunkt i forretningsadfærd frem for tekniske detaljer, får vi via de definerede tests et klart billede af, hvad løsningen skal gøre. Det betyder, at vi kan se, om noget er gået galt, før kunden opdager det. Det er vigtigt, fordi mange problemer ikke bliver synlige før lang tid efter en leverance — og det er netop den klassiske faldgrube næste afsnit handler om.

Den klassiske faldgrube – og hvorfor den opstår

I praksis ser vi ofte det samme mønster:
En opgave bliver løst, testet og godkendt. Alt fungerer som forventet her og nu.

Men systemet er stort og bruges på mange forskellige måder i hverdagen. Derfor kan der gå dage, uger eller måneder før en ældre funktion eller et særligt scenarie bliver brugt igen. Når det sker, opdager man pludselig, at noget ikke længere virker.

Det er sjældent fordi noget er “lavet forkert”. Det skyldes ganske enkelt, at manuelle tests og enkeltstående godkendelser ikke kan dække alle de måder, et Business Central-system anvendes på over tid.

Ingen udvikling uden automatiserede tests

Det er en grundregel, vi står fast på:

Den automatiserede test driver udviklingen.

Simpelthen fordi det er den eneste realistiske måde at sikre stabilitet i komplekse løsninger - også når man udvikler systemet over flere år.

Når tests er forankret i systemet:

• bliver ændringer mere trygge

• bliver opgraderinger mere forudsigelige

• og bliver vedligeholdelse billigere over tid

Test som en forretningsmæssig investering

En opgradering af Business Central er ikke bare en teknisk opgave. Det er en strategisk mulighed for at få styrket både kvalitet, forretningsproces og fremtidig udvikling.

Når vi arbejder struktureret med forretningsbaserede tests, sikrer vi:

• at løsningen opfører sig som forventet — hver gang

• at viden om kritiske processer er integreret i systemet

• at ændringer og opgraderinger bliver trygge og forudsigelige

Automatiserede tests skaber både forretningssikkerhed og en teknisk sikkerhed. De flytter fokus fra “Gik det galt?” til “Hvordan gør vi det endnu bedre næste gang?”

Med den rette struktur bliver opgraderinger til noget man udnytter til at løfte kvalitet og værdi. Det er ikke bare god udviklingspraksis. Det er god forretningspraksis.