Dataflytning til Microsoft Dynamics 365 Business Central bliver ofte omtalt som en teknisk opgave. I praksis er det en forretningskritisk disciplin, hvor små beslutninger om datavalg, rækkefølge og validering kan afgøre, om go-live føles rolig eller kaotisk.
God datamigrering handler ikke om at få “alt” med. Det handler om at få det rigtige med, i den rigtige kvalitet, på det rigtige tidspunkt, og på en måde som kan gentages og kontrolleres.
Hvad skal migreringen egentlig sikre?
Før værktøjer, Excel-filer og pipelines kommer på bordet, giver det ro at sætte ord på målet. Er målet at skifte platform uden at ændre processer? Eller er målet at modernisere arbejdsgange, rydde op i stamdata og standardisere måden, man arbejder med dimensioner, moms og lagerstyring?
En migration er en chance for at få ejerskab på data. Hvem kan godkende kontoplanen? Hvem bestemmer, hvad et “aktivt” varenummer er? Og hvem må oprette nye debitorer fremover?
Det er her governance og forankring hos brugerne bliver lige så vigtigt som selve dataoverførslen.
Hvilke data bør flyttes, og hvad bør blive tilbage?
Business Central kan rumme mange års historik, men mere data er ikke altid bedre. Historiske poster kan skabe støj, gøre tests langsommere og forlænge cutover-vinduet.
Efter en kort foranalyse ender mange virksomheder med en pragmatisk opdeling: flyt stamdata og nødvendige saldi, og arkivér resten. Microsoft gennemgår, at systemtabeller, brugerkonti og permissions typisk ikke migreres som “data” på samme måde som forretningsdata, men bygges op i målmiljøet via opsætning og adgangsstyring (se Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-business-central-on-premises).
En konkret afgrænsning kan se sådan ud, efter at behovene er afklaret i økonomi, lager og salg:
- Debitorer, kreditorer, varer
- Kontoplan og bogføringsopsætning
- Dimensioner og dimension-værdier
- Åbne poster (debitor, kreditor, finans)
- Lagerbeholdning og relevante lagerposter
- Anlægsaktiver (hvis de bruges aktivt)
- Projektdata, hvis det er en central del af driften
Og så det, der ofte kræver et bevidst fravalg: gammel ordrehistorik, gamle finansposter og ældre “inaktive” varer, som kun sjældent slår igennem i daglig drift.
Strategi: et forløb der kan gentages
En robust strategi gør migreringen forudsigelig. Det betyder, at man kan køre flere gennemløb i test uden at opfinde processen på ny hver gang.
Det hjælper at tænke migreringen i faser, hvor hver fase har tydelige “done”-kriterier, ansvarlige og afstemninger. Microsoft anbefaler at arbejde med en detaljeret plan for tid, ressourcer og fremgangsmåde (https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-business-central-on-premises).
Her er et eksempel på et enkelt faseoverblik, som kan bruges som styringsværktøj:
Fase 1: Forberedelse– dataudtræk, screening, datadefinitioner, beslutninger om historik
- mapping-dokument og ejerskab pr. datadomæne Fase 2: Pilot i sandbox– første import af stamdata og opsætning
- test af afhængigheder og fejlmønstre Fase 3: Iterationer– gentagne migreringsruns med rensning, rettelser og forbedrede scripts/pakker
- begyndende brugertræning på realistiske data Fase 4: Cutover– frys af kildesystem, endelig udtræk, import, afstemning
- frigivelse til drift Fase 5: Hypercare– tæt opfølgning på afstemninger, fejlrettelser og arbejdsgange
Et kort cutover-vindue er sjældent et resultat af hast. Det er resultatet af gentagelser.
Værktøjer og metoder: vælg efter datamængde og kompleksitet
Business Central har flere veje ind, og det er normalt at kombinere metoder. De fleste projekter bruger en “standardvej” til stamdata og opsætning, og en mere automatiseret vej til større transaktionsmængder eller komplekse transformationer.
Nogle af de mest brugte muligheder er:
- RapidStart (konfigurationspakker) til kontoplan, debitorer, kreditorer, varer og opsætninger. Microsoft gennemgår brugen af konfigurationspakker til migrationsoverblik og import i tabeller (se fx dokumentation: https://bcdocs.staedean.com/md/en-US/admin-migrate-customer-data.md).
- Cloud Migration med Azure Data Factory, når der flyttes fra on-prem SQL til Business Central Online med behov for bulkflytning og reproducerbare pipelines. Intelligent Cloud / Intelligent Cloud Extensions bygger i praksis oven på denne tilgang via assisteret opsætning og datareplikering i cloud-scenarier (Microsoft Learn: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-business-central-on-premises og https://learn.microsoft.com/en-us/dynamics365/business-central/ui-extensions-data-replication).
- ETL/SSIS med connector, når der er flere kilder, avanceret transformation eller løbende synkronisering. Et eksempel er KingswaySofts værktøj, som understøtter OData/SOAP/REST end points til Business Central (https://www.kingswaysoft.com/connectors/api/dynamics365-nav-bc/data-integration).
- API og Power Automate til mindre volumener, valideringsflows og gentagne opdateringer i overgangsperioden.
Valget bør ikke styres af, hvad der er “smartest”, men af hvad der er kontrollerbart og til at supportere efter go-live.
Når man skal beskrive værktøjsvalget for en styregruppe eller en intern IT-funktion, kan det være nyttigt at formulere det som klare brugsscenarier:
- Stamdata og opsætning: RapidStart-konfigurationspakker, så import kan køre tabel for tabel med tydelig fejlliste.
- Stor volumen fra SQL: Cloud Migration (Azure Data Factory) med Intelligent Cloud Extensions, så pipelines kan køres igen og igen og logges.
- Mange kilder og tung mapping: ETL (SSIS/KingswaySoft), så transformationer ligger i en styrbar proces.
- Små rettelser og løbende opdateringer: API/Power Automate, så man undgår manuelle tasteopgaver.
Datakvalitet: rensning, normalisering og mapping
Hvis data er ujævne, bliver Business Central det også. Derfor giver det mening at planlægge datarensning som en selvstændig leverance, ikke som en “ting vi lige klarer” sidst i projektet.
Praktisk datarensning handler ofte om:
- dubletter (debitorer, leverandører, kontaktpersoner)
- manglende obligatoriske felter (betalingsbetingelser, bogføringsgrupper)
- inkonsistente formater (postnumre, landekoder, telefonnumre)
- koder der ikke længere giver mening (leveringsbetingelser, fragtmetoder, gamle dimensioner)
Brancheerfaring peger på, at man bør vurdere, rense og validere data før migreringen for at undgå fejl i målmiljøet (se fx EFOQUS om datakvalitetsudfordringer: https://www.efoqus.ca/resources/blog/overcoming-data-migration-challenges-in-business-central/).
Mapping er næste trin. Her er tommelfingerreglen, at mapping-dokumentet skal kunne læses af både forretning og teknik. Det skal vise, hvordan hvert felt bliver overført, og hvad der sker, når der mangler værdi, eller når værdien ikke passer ind i Business Centrals kodestandarder.
En enkel disciplin, der sparer mange timer: læg mapping og transformationer i et versioneret dokument, og aftal hvem der må ændre det.
Test og afstemning: det der gør go-live tryg
Migration uden test bliver et lotteri.
Det er ikke nok at teste, om importen “kørte igennem”. Man skal teste, om data kan bruges i processer: kan en ordre oprettes, leveres og faktureres? Stemmer momsberegning? Rammer dimensioner korrekt i rapporter? Og matcher finansielle afstemninger det, økonomi forventer?
En god testpakke rummer typisk både tekniske og forretningsnære kontroller:
- enhedscheck af import (antal rækker, fejllister, obligatoriske felter)
- proces-test i sandbox (ordre til faktura, indkøb til betaling, lagerregulering)
- afstemningsrapporter (kontosaldi, åbne poster, lagerværdi)
- UAT med superbrugere, som kender variationerne i hverdagen
Sandbox-test og brugeraccepttest reducerer risikoen for fejl ved go-live (https://www.aegissofttech.com/insights/business-central-data-migration/).
Et enkelt råd i praksis: kør afstemninger på samme måde hver gang. Hvis afstemningsmetoden ændrer sig fra iteration til iteration, er det svært at se, om projektet bliver bedre, eller bare anderledes.
Typiske faldgruber og hvordan de håndteres
De fleste problemer i en BC-migration kan spores tilbage til tre ting: manglende afhængigheder, forkert rækkefølge eller uklar ejerskab på data. Microsoft gennemgår, at tabeller kan fejle at migrere, hvis skemaet ikke passer eller ikke findes (https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/migrate-business-central-on-premises).
Her er et sæt klassiske faldgruber, som er værd at have på en fast tjekliste i projektet:
- Transaktioner før stamdata: importer først debitor/kreditor/varer, derefter åbne poster og lager.
- Uklare kodestandarder: aftal tidligt format på dimensioner, momsgrupper, landekoder og betalingsbetingelser.
- Skjulte dubletter: “samme kunde” med to numre giver hurtigt rod i kreditstyring og rapporter.
- Dato- og talformater: fejl i decimaler og datoformater stopper importer eller giver stille fejl.
- For stor historik: gamle poster øger datamængde og testtid uden at give værdi i drift.
Rollback og beredskab kræver en konkret fallback-plan. Best practice er at have fulde backups, tydelige gendannelsestrin og en aftalt beslutningsgrænse for, hvornår man ruller tilbage.
Sikkerhed og compliance under flytningen
Dataflytning handler om adgang, logning og transport.
Hvis persondata eller følsomme finansoplysninger indgår, bør man sikre krypteret overførsel, rollebaseret adgang og dokumentation af, hvem der har håndteret hvilke udtræk og filer. En praktisk tilgang er at arbejde med kryptering, adgangskontrol og løbende sikkerhedsrevisioner som faste dele af migrationsprocessen (https://www.efoqus.ca/resources/blog/overcoming-data-migration-challenges-in-business-central/).
I Business Central kan ændringslog og rettighedsmodeller bruges aktivt, men det kræver, at man planlægger det som en del af go-live og ikke som en eftertanke.
Forankring og drift: når data først er landet
Go-live er ikke det tidspunkt, hvor data “er færdige”. Det er tidspunktet, hvor data begynder at blive brugt, rettet og udbygget i nye rutiner.
En stabil drift efter migrering kræver, at man holder fast i governance. Det betyder, at man træffer konkrete beslutninger om ejerskab og regler for vedligehold:
- Hvem må oprette varer?
- Hvem ejer dimensioner?
- Hvornår rydder man op i inaktive kunder?
- Hvordan håndteres ændringsønsker, så løsningen forbliver opgraderbar?
Hos Naviteam er den praktiske tilgang ofte at kombinere struktureret implementering, tydelig styring og brugeradoption, så løsningen bliver taget i brug og kan udvikles kontrolleret over tid. Det passer godt til dataområdet, hvor små, velafgrænsede leverancer og målrettet træning af superbrugere kan gøre en stor forskel i kvaliteten af de data, der bliver skabt efter go-live.
Automatisering kan flytte fokus væk fra manuel indtastning og over på kontrol. Add-ons og partnerværktøjer som Continia, ForNAV og Little Beacon bliver i praksis ofte brugt til at effektivisere fakturahåndtering, dokumentflow og lagerprocesser omkring Business Central (Naviteam omtaler partnerskaberne her: https://www.navi-team.dk/). Det ændrer ikke selve migreringen, men det kan sænke presset på datafangst i hverdagen, når den nye løsning er i drift.
Det bedste tegn på en vellykket migrering er sjældent, at ingen finder fejl. Det er, at organisationen ved præcis, hvordan fejl findes, prioriteres og rettes, uden at driften går i stå.