Business Central migrations-tjekliste: fra plan til drift

De fleste migrationer går ikke galt på selve weekenden. De går galt, fordi nogen opdager i marts, at åbne poster fra C5 er kommet over som én samlet saldo, eller at NAS-jobbet, der sendte ordrer til lageret, aldrig blev genskabt i BC online.

Det her er tjeklisten, vi selv bruger, når vi flytter kunder fra C5, NAV og on-prem Business Central til BC online. Brug den som udgangspunkt, og streg det ud, der ikke gælder jer.

Fase 1: Vurdering og planlægning

Start to-tre måneder før go-live. Det meste af arbejdet er at finde ud af, hvad I faktisk har.

Vurdering af nuværende miljø

• Hvilket system og hvilken version: C5 2012, NAV 2009, NAV 2018, BC 14 eller nyere
• Liste over alle tilpasninger: hvad bruges stadig, og hvad blev bygget til en proces, der ikke findes mere
• Liste over integrationer: webshop, bank, EDI, lagersystem, løn — og hvordan de kører i dag (filer, NAS, webservices)
• Databasestørrelse og hvor mange års historik der ligger i den
• De rapporter, folk faktisk bruger hver måned

Cloud-parathedsvurdering

• C/AL-tilpasninger skal omskrives til AL-udvidelser. Der findes ingen konverteringsknap, der gør det for jer
• Direkte SQL-adgang, .NET-komponenter og filer på en netværksmappe virker ikke i BC online
• Microsofts cloud-migreringsværktøj kræver on-prem BC version 25 eller nyere. Ældre versioner skal opgraderes eller genimplementeres
• Licensbehov: Essentials eller Premium, fulde brugere og Team Members

Interessent-tilpasning

• Én beslutningstager på kundesiden, der kan sige ja og nej
• Én superbruger pr. område: bogholderi, salg, lager
• Hvad betyder succes? Typisk: første momsafregning og første månedsafslutning uden overraskelser
• Fortæl organisationen tidligt, hvornår systemet lukker, og hvad der ændrer sig for dem

Udvikling af migrationsstrategi

• Fuld migrering med al historik, eller genimplementering med åbne poster, saldi og stamdata
• Go-live-dato: et årsskifte eller en periodestart gør afstemning meget lettere end midt i en måned
• Fra C5: Microsofts C5-migreringsværktøj flytter stamdata, åbne poster og finanshistorik — men samler ældre posteringer pr. konto
• Hvad sker der med historikken, der ikke flyttes? Den skal kunne fremfindes i fem år efter bogføringsloven
• En plan B: Hvornår beslutter vi at udskyde?

Vores erfaring viser, at for hver time brugt på grundig planlægning sparer du cirka tre timer i migrationsudførelse og fejlfinding.

Fase 2: Førmigrationsforberedelse

En til to måneder før go-live. Her bliver de fleste problemer fundet — eller ikke fundet.

Tekniske forberedelser

• Opret produktions- og sandbox-miljø i BC online i den rigtige landeversion
• Omskriv de tilpasninger, der skal med, til AL-udvidelser — og drop resten
• Flyt integrationer til BC's API'er med OAuth. Gamle SOAP-webservices og brugerlogins skal ud
• Erstat NAS-jobs med opgavekøposter
• Sæt e-fakturering, betalinger og Continia-apps op i det nye miljø

Dataforberedelse

• Ryd op i stamdata før, ikke efter: spærrede debitorer, dubletter, varer uden salg i fem år
• Afstem åbne debitor- og kreditorposter i det gamle system, så I ved, hvad tallene skal være
• Beslut, hvad der arkiveres frem for at blive flyttet
• Lav mindst én fuld prøvemigrering til sandbox og afstem den

Brugerforberedelse

• Kommer brugerne fra C5, er alt nyt. Kommer de fra NAV, er det mest webklienten og nye sider
• Træn på jeres egne data i sandbox, ikke på Cronus
• Superbrugerne er første linje i den første uge
• Aftal, hvem brugerne ringer til efter go-live

Testmiljø

• Kopi af produktionsdata i en sandbox
• Testscenarier skrevet af brugerne: fra ordre til faktura, fra købsfaktura til betaling, månedsafslutning
• Test med brugernes rigtige rettigheder, ikke som SUPER
• Test hver integration med rigtige data: en ordre fra webshoppen, en betalingsfil, en OIOUBL-faktura

Fase 3: Migrationsudførelse

Typisk en weekend. Hvis fase 2 er gjort ordentligt, er det mest en øvelse i at følge planen.

Endelig forberedelse

• Gennemgå planen med alle, der har en opgave i weekenden
• Bekræft, at alle åbne punkter fra testen er lukket
• Fuld backup af det gamle system
• Brugerne ved, hvornår systemet lukker, og hvornår det nye åbner

Datamigration

• Luk for bogføring i det gamle system
• Kør den endelige migrering eller sidste delta-kørsel
• Afstem: balance pr. skæringsdato, åbne debitor- og kreditorposter, lagerantal og lagerværdi
• Gem afstemningen — revisor vil se den

Konfiguration og opsætning

• Brugere og rettigheder flyttes ikke med. Opret dem via sikkerhedsgrupper i Entra ID
• Installer jeres egne apps og AppSource-apps i den rigtige rækkefølge
• Slå integrationer til og test, at første ordre kommer igennem
• Opsæt Universal Print eller udskrivning via mail — printeren i kælderen kan ikke ses fra skyen
• Opsæt dokumentafsendelse, fx Continia Document Output, så fakturaer går ud korrekt fra dag ét

Validering og test

• Bogfør en faktura, en kreditnota og en indbetaling
• Kontroller, at e-fakturaer og betalingsfiler går igennem
• Kontroller rettigheder med en almindelig bruger
• Go/no-go søndag aften med beslutningstageren

Fase 4: Post-migrationsaktiviteter

De første fire uger afgør, om brugerne stoler på systemet.

Umiddelbar post-migrationssupport

• Konsulenten er tilgængelig — gerne fysisk — de første dage
• Én liste over fejl og spørgsmål, som alle kan se
• Hold øje med opgavekøen og integrationsloggene dagligt
• Prioritér det, der stopper fakturering og betalinger, over det, der er irriterende

Systemoptimering

• Find langsomme sider og rapporter med telemetri i Application Insights
• Ryd op i opgavekøposter, der kører for ofte
• Gennemgå rettigheder igen, når brugerne har arbejdet i systemet et par uger
• Dokumentér opsætningen, så den ikke kun lever i konsulentens hoved

Brugeradoption og træning

• Spørg brugerne, hvad der tager længere tid end før — og ret det
• Ekstra træning, hvor der er behov, typisk i månedsafslutning og rapportering
• Skriv de nye arbejdsgange ned
• Luk de Excel-ark, der lever videre ved siden af BC

Langsigtet planlægning

• Microsoft opdaterer BC online to gange om året, i april og oktober. Test jeres apps i sandbox før
• Hold styr på, hvem der har adgang, og hvilke licenser I betaler for
• Lav en liste over det, der blev parkeret til "efter go-live"
• Kig efter manuelle rutiner, der nu kan automatiseres

Den egentlige gevinst kommer i månederne efter go-live, når de manuelle rutiner forsvinder. Planlæg den fase lige så grundigt som selve migreringen.

Konklusion

En migration til BC online er mest et spørgsmål om forberedelse: kend jeres tilpasninger og integrationer, ryd op i data før flytningen, og afstem alt, både i testen og på dagen.

Brug tjeklisten som udgangspunkt. Ikke alle punkter gælder for alle, men de punkter, der bliver sprunget over, er som regel dem, der dukker op igen i den første månedsafslutning.