Vores team hos Alpha Solutions byggede for nylig en komplet datamigreringsløsning i forbindelse med et skift af commerce-platform. Millioner af poster. Fire dage. Vi havde aldrig arbejdet med kildesystemet før. Vi havde aldrig engang set det.
Der var ingen legacy-eksperter på teamet. Ingen ugers forretningsanalyse. Ingen lange kravspecifikationer, før vi kunne begynde.
Jeg vil gennemgå præcis, hvad vi gjorde, fordi det illustrerer noget vigtigt om, hvordan AI ændrer den måde implementeringsarbejde faktisk ser ud på i praksis.
For få år siden ville et migrationsprojekt som dette være startet med nogle helt andre spørgsmål. Hvem på teamet har arbejdet med dette legacy-system før? Kan vi finde en konsulent med erfaring i den platform? Hvor lang tid vil det tage at kortlægge datastrukturerne, før vi kan skrive en eneste linje migrationslogik?
Bare jagten på den rette ekspertise kunne tage uger. Og selv når man havde de rette mennesker, var processen med at forstå et udokumenteret legacy-system – at finde ud af, hvordan data var struktureret, hvor edge cases gemte sig, og hvad de forretningsregler, der lå begravet i databasen, egentlig betød – langsom, manuel og dyr. Historisk set var det netop her, projektbudgetter ofte blev brugt op, før der overhovedet var skrevet en eneste linje migrationskode.
Vi gjorde det anderledes.
Vi brugte AI til at læse og forstå legacy-systemet fra bunden. Første skridt var at indlæse systemets struktur i Claude Code og GitHub Copilot og lade dem kortlægge dataene. Men kortlægningen var kun begyndelsen. Det, der fulgte, lignede mere en samtale. Vi begyndte at stille AI’en direkte spørgsmål om det, den så: Kan du gennemgå denne tabel og fortælle, hvad der ligger i den? Er der afhængigheder? Kan du gennemgå datatyperne? Svarene kom tilbage struktureret, klart og umiddelbart brugbart. Vores team gik fra at stirre på et ukendt system til at have en fungerende forståelse af det på få timer i stedet for dage.
Hvor den centrale forretningslogik lå i API’er, var Claude Code særligt effektiv. Den gennemgik kodebasen og oversatte logikken til almindeligt sprog, som vi brugte som grundlag for vores forretningskrav. Det er arbejde, der normalt kræver ugers workshops og møder. Vi havde det på en brøkdel af tiden, hvilket betød, at når vi satte os ned med forretningsteamet for at verificere det, gik samtalen hurtigt. Et struktureret dokument er langt lettere at gennemgå end en rå kodebase. Færre møder, skarpere beslutninger.
Vi bad også AI analysere systemet og fremhæve anomalier og edge cases. Den gjorde et grundigt stykke arbejde. Noget af det, den fandt, lå før den samlede viden hos størstedelen af kundens team – adfærd og undtagelser, der havde været indbygget i systemet i årevis, og som ingen på det nuværende team vidste eksisterede. Vi dokumenterede det hele, før vi skrev et eneste script. Det betød, at vi kunne designe til edge cases fra starten i stedet for at opdage dem midt i migreringen.
Vi gennemgik edge cases med forretningen, fik hele migrationsplanen gennemgået og godkendt og brugte derefter AI til at skrive migrationsscripts. Da dataene var flyttet, brugte vi AI til at sammenligne det migrerede datasæt med kildedataene. Valideringsrapporten gav os præcis det, vi havde brug for til at justere mappings. Vi itererede processen, adresserede det analysen fremhævede, ryddede op og kørte igen. Hver gennemgang blev renere. Til sidst var det på plads.
Fire dage til planlægning og scripting. En migrering, der under den gamle model ville have krævet ugers analyse og udvikling.
Den ærlige forklaring på, hvorfor det virkede, er, at AI ikke stod for tænkningen. Den komprimerede den tid, det tager at udføre de mekaniske dele af processen – forståelse, mapping, scripting og validering – så vores team næsten udelukkende kunne fokusere på vurderingerne. Hvad betyder disse data i en forretningsmæssig kontekst? Er denne edge case en reel undtagelse eller et datakvalitetsproblem? Bevarer denne mapping integriteten af den oprindelige logik? Det er stadig spørgsmål, der kræver menneskelig erfaring og ekspertise. AI betød bare, at vi kunne komme hurtigere frem til dem uden først at bruge uger på forarbejdet.
Hvis du planlægger en platformmigrering i 2026, kan dine antagelser om tidslinje og omkostninger være markant forkerte, hvis de er baseret på, hvordan denne type arbejde tidligere blev udført. De faser, der historisk har taget mest tid, er præcis de faser, hvor AI har størst effekt. Det betyder, at den samlede omkostningskurve for en veludført migrering i dag er betydeligt lavere, end den var for bare to år siden.
Det er gode nyheder for budgettet. Men det rejser også et spørgsmål, der er værd at stille jeres implementeringspartner direkte: Hvordan bruger I AI i jeres migrationsworkflow – og hvad betyder det for min tidsplan og mine omkostninger?
Hvis de ikke kan give et konkret svar, er det værd at finde ud af hvorfor.
