Migrera data till Business Central med RapidStart: inbyggd validering – och Excels radgräns
Av Isak La Fleur EngdahlSka du sätta upp ett nytt Dynamics 365 Business Central-bolag är RapidStart Services verktyget Microsoft ger dig för att ladda in setup- och masterdata. Kärnan är konfigurationspaketet: du väljer de tabeller du bryr dig om, exporterar dem till Excel, fyller i dem och importerar tillbaka – och Business Central validerar varje post på vägen in, med samma logik som om en användare matat in den för hand.
Den valideringen är hela skälet att använda RapidStart i stället för att peta in data rakt i tabellerna. Men Excel-rundturen som gör det så lättillgängligt sätter också ett hårt tak, och på vilken verklig datamängd som helst slår du i det. Här är en ärlig titt på hur det fungerar, vad det är bra på, och var du måste dela upp datan för att få in den.
Så fungerar RapidStart: konfigurationspaket
Ett konfigurationspaket är en kurerad bunt tabeller plus fältvalet och reglerna för att ladda dem. Flödet är detsamma varje gång:
- Skapa paketet och lägg till de tabeller du behöver. Business Central känner tabellrelationerna och föreslår relaterade tabeller så att du inte missar ett beroende.
- Välj fält och sätt bearbetningsordning per tabell, markera obligatoriska fält, och koppla eventuellt konfigurationsmallar som fyller standardvärden automatiskt.
- Exportera till Excel – ett blad per tabell – eller till en
.rapidstart-fil (komprimerad XML). - Fyll i eller transformera datan i Excel. Det är den biten kunder och funktionskonsulter gillar: ett bekant verktyg, inte en databas.
- Importera filen tillbaka. Datan landar i paketets staging-yta, ännu inte i de skarpa tabellerna.
- Validera, och sedan applicera. Applicering skriver in datan i de riktiga Business Central-tabellerna och kör samma fältvalidering och affärslogik som manuell inmatning.
En viktig gräns, direkt från Microsoft: konfigurationspaket är till för att sätta upp ett bolag första gången, inte för att trycka in data i ett bolag som redan är i produktion.
Skälet att använda det: validering vid applicering
Det här är RapidStarts främsta fördel, och den är verklig. När du applicerar ett paket dumpar Business Central inte bara rader – det kör samma fältvalidering och tabellrelationskontroller som om någon knappat in varje post i gränssnittet. En kund som pekar på en betalningsvillkorskod eller bokföringsmall som inte finns blir avvisad med ett fel per post, inte tyst inskriven som trasig data.
I praktiken ger det en tight loop: importera → validera → läs felen → rätta dem i paketet → applicera om. Du städar data mot den faktiska Business Central-konfigurationen innan den ens blir skarp. Lägg till det:
- Ingen kod. Funktionskonsulter och kundens eget team kan driva det.
- Mallar applicerar konsekventa standardvärden på importerade masterposter.
- Bearbetningsordning låter dig respektera beroenden (setup- och referenstabeller före de master som refererar dem).
- Återanvändbarhet. Exportera paketet en gång och importera om det i ett annat bolag eller miljö – din "golden setup" blir flyttbar.
Taket alla slår i: Excels radgräns
Här är haken demona hoppar över. Eftersom datan stagas via Excel ärver du Excels begränsningar. Ett Excel-blad tar slut vid 1 048 576 rader, och ett blad rymmer en tabell. En stor tabell – en lång kund- eller artikellista, redovisnings- eller ingående poster – kan spränga den gränsen. Och långt innan det hårda taket blir Excel-importen långsam och minneshungrig; tiotusentals rader tynger redan.
Så på en verklig migrering delar du upp datan över flera filer och importerar dem en efter en in i samma paket. Varje import läggs till paketets staging, och du validerar och applicerar en gång på slutet. Praktiska sätt att dela en stor tabell:
- Efter ett naturligt intervall – ett nummerserieblock, ett datumintervall, en region eller ett dimensionsvärde.
- I jämnstora bitar (t.ex. 50–100k rader per fil) som importeras snabbt och är lätta att köra om ifall en fallerar.
Två sätt att helt undvika Excel-taket när en tabell är genuint enorm:
- Exportera/importera paketet som en
.rapidstart-fil i stället för Excel. Det är komprimerad XML och binds inte av bladets radgräns – du tappar bekvämligheten att redigera i Excel, men bär långt mer data. - Kliv utanför RapidStart för de tunga tabellerna – använd API:erna (eller den inbyggda Cloud Migration-funktionen, nedan) för volym, och behåll RapidStart för den kurerade setupen och masterdatan där dess validering gör nytta.
Var RapidStart passar bland alternativen
RapidStart är inte enda sättet data tar sig in i Business Central – det är rätt sätt för ett specifikt jobb:
- RapidStart-konfigurationspaket – setup-/konfigurationsdata, masterdata och ingående balanser för ett nytt bolag. Validerat, ingen kod, verksamhetsdrivet. Det här är förstavalet för en greenfield-implementation.
- Cloud Migration (Intelligent Cloud) – för att flytta en befintlig on-prem-databas i Dynamics GP, NAV, SL eller BC till Business Central online. Det replikerar data i sin helhet och kan köras upprepat (initial fullladdning, sedan delta) – ett annat jobb än RapidStarts kurerade förstagångssetup.
- API:er / automatisering – för stora volymer, repeterbara laddningar och integrationer, när du växt ur Excel-rundturen.
De flesta greenfield-implementationer lutar sig mot RapidStart; en uppgradering från on-prem GP/NAV lutar sig mot Cloud Migration. Välj medvetet.
Var RapidStart tar slut – och du tar över
Valideringen är genuint hjälpsam, men var tydlig med vad den fångar och inte:
- Den kontrollerar referenser, inte korrekthet. En post kan vara helt giltig – varje kod stämmer – och ändå vara fel. Valideringen säger inte att kundens kreditgräns eller momsuppsättning har fel värde.
- Kvalitet och mappning är uppströms. Dubbletthantering, städning och att mappa legacy-koder (kundgrupper, artikelkategorier, dimensioner) mot Business Central-setupen sker före paketet, inte inuti det.
- Ordningen spelar roll. Nummerserier, bokföringsuppsättningar och referenstabeller måste appliceras före de masterposter som beror på dem – planera bearbetningsordningen, upptäck den inte via fel.
- Historiken är ett scope-beslut. RapidStart lyser för setup, master och öppna poster; djup bokförd historik hör hemma i Cloud Migration eller lämnas i legacy-systemet. Bestäm tidigt – det styr din tidplan mer än verktyget gör.
- Avstämning är fortfarande manuell. En ren applicering bevisar att raderna gick in och validerade; att bevisa att antal och saldon stämmer med källan, och få sign-off, är din disciplin.
Sammanfattning
RapidStart-konfigurationspaket är rätt verktyg för att sätta upp ett nytt Business Central-bolag: valideringen vid applicering fångar trasiga referenser innan de blir skarp data, det kräver ingen kod, och ett paket är återanvändbart över bolag. Planera bara för Excel-taket – dela stora tabeller över flera filer som importeras in i ett paket, eller byt till .rapidstart-formatet eller API:er när volymen kräver det.
Och som alltid är verktyget sista milen. Att städa källan, mappa den mot Business Central-setupen, bestämma vilken historik som ska med, och stämma av resultatet – arbetet som avgör om migreringen lyckas – ligger utanför RapidStart.
Sätter ni upp Business Central och väger hur ni ska migrera? Hör av dig – jag berättar gärna hur jag arbetar.
Referenser: Microsoft Learn – Set up company configuration packages, Apply company configuration packages och Migrate on-premises data to Business Central online.