Migracija Business Central se v slovenskih podjetjih najpogosteje začne ob enem od treh sprožilcev: Excel in pisarniška orodja ne zmorejo več obsega poslovanja, računovodski program ne pokriva zalog ali proizvodnje, ali pa star ERP ne sledi zahtevam e-računov in davčnega potrjevanja računov. Kdor želi preiti na Business Central, mora poleg izbire licenc rešiti dve vprašanju: kateri podatki gredo s podjetjem naprej in kako izvesti preklop, ne da bi se ustavila fakturacija.
Ta stran pokriva obe poti: prehod v Business Central iz drugega vira in selitev med različicami samega Business Central. Splošna načela selitev sistemov so v vodniku o migraciji ERP, tu pa so podrobnosti, značilne za ta produkt.
Od kod prihajate: izhodišča
Pot je odvisna od izvora. Razlike so večje, kot se zdi na prvi pogled.
| Izhodišče | Značilnost | Glavno tveganje |
|---|---|---|
| Excel in ročne evidence | Podatki so razpršeni, brez enotnih šifer | Podvojeni kupci in artikli, neenotni zapisi |
| Računovodski program | Urejena glavna knjiga, šibke zaloge in nabava | Kontni načrt in analitike se ne prenesejo enostavno |
| Star ERP ali lasten sistem | Veliko zgodovine in prilagoditev | Poslovna pravila, ki jih nihče več ne pozna |
| Starejša različica Business Central ali NAV | Podobna struktura, a stare razširitve | Nezdružljive razširitve in zastareli podatkovni model |
Iz Excela in ročnih evidenc
Excel je najlažji vir in hkrati najbolj zahteven za čiščenje. Nikjer ni vsiljene strukture, zato se v istem stolpcu mešajo oblike zapisov, kratice podjetij in napake v davčnih številkah. Pri Business Central se to uredi z uvoznimi predlogami in konfiguracijskimi paketi, še pred tem pa je treba odločiti, kaj je »en kupec« in kaj »ena podružnica«.
Iz računovodskega programa
Pri prehodu iz računovodskega programa je prva naloga preslikava kontnega načrta in dimenzij. Poglejte, kako je računovodstvo in finance v Business Central zasnovano, in šele nato odločite, katere analitike obdržite. Računovodja mora potrditi začetna stanja še pred prvim knjiženjem v novem sistemu.
Iz starega ERP
Pri starem ERP običajno ne gre samo za podatke, ampak za procese, ki so zraščeni s sistemom. Preden karkoli prenašate, naredite seznam poročil, izpisov in samodejnih opravil, na katera se podjetje dejansko zanaša. Pri tem pomaga tudi revizija obstoječega projekta, če je prejšnji projekt zastal.
Orodja Microsofta za selitev
Za prehod iz Business Central na strežniku v spletno različico Microsoft ponuja orodje za selitev v oblak. Po dokumentaciji ga je mogoče uporabiti za selitev iz Business Central na strežniku (neposredno od različice 25; različice od 15 do 24 je treba najprej nadgraditi vsaj na različico 25), iz Dynamics GP 2015 in novejših, iz Dynamics SL 2015 in novejših ter iz katerega koli drugega vira SQL z lastnimi migracijami.
Zahteve so tehnične, a pomembne za načrt:
- rešitev na strežniku mora uporabljati SQL Server 2016 ali novejši, s stopnjo združljivosti podatkovne zbirke najmanj 130;
- stranka z Dynamics NAV mora najprej preiti na Business Central na strežniku in šele nato v splet;
- pri viru, ki ni SQL, Microsoft svetuje konfiguracijske pakete in predloge za nalaganje podatkov v Business Central na strežniku, nato pa orodje za selitev v oblak.
Za uporabnike različice 14 na strežniku obstajata dve poti. Prva je popolna migracija: nadgradnja na strežniku vsaj na različico 25 in nato selitev. Druga je orodje za ponovno implementacijo Business Central 14, ki neposredno v oblak prenese le bistvene podatke: osnovne podatke, začetna stanja in nastavitve. Druga pot pogosto ustreza podjetjem, ki zgodovine ne potrebujejo in želijo čist začetek.
Znanja za te naloge so del Microsoftovega izpita MB-800, ki vključuje ustvarjanje družbe z vodenim namestitvenim čarovnikom, konfiguracijske liste in pakete, otvoritvene vknjižbe v dnevnikih in prenos podatkov v Business Central. Pri izbiri izvajalca je to koristen pokazatelj, kaj naj pričakujete od svetovalca; več o tem v članku o izbiri partnerja.
Katere podatke prenesti in katere pustiti
Najdražja napaka je prenos vsega »za vsak primer«. Podatke razdelite v skupine.
Šifranti (obvezno). Kupci, dobavitelji, artikli, kontni načrt, skladišča, davčne skupine DDV, bančni računi. Tu se izplača čiščenje: združite dvojnike, popravite davčne številke, opustite neaktivne zapise.
Odprte postavke in začetna stanja. Odprte terjatve in obveznosti, stanje zalog po skladiščih in lokacijah, začetna stanja v glavni knjigi, osnovna sredstva. Brez teh podjetje ne more poslovati od prvega dne.
Zgodovina (po presoji). Pretekla knjiženja, naročila in računi. Odločitev je odvisna od potreb po primerjavah, nadzoru in zakonskih rokih hrambe. Računovodja naj potrdi, kaj je treba hraniti v živem sistemu, kaj pa je dovolj v arhivu.
Zelo praktično je pravilo: če podatka nihče ne bo iskal v novem sistemu, ga ne prenašajte. Manj podatkov pomeni krajše testiranje, hitrejši preklop in manj napak.
Čiščenje pred prenosom
Čiščenje se naredi v izvornem sistemu, ne v Business Central. Za vsak šifrant določite lastnika, ki odloči o dvojnikih in neaktivnih zapisih. Posebno pozornost namenite artiklom z več merskimi enotami, kupcem z več naslovi dostave in dobaviteljem, ki se pojavljajo pod različnimi imeni. Pri trgovskih in proizvodnih podjetjih je pomemben tudi pregled kosovnic in zalog, kot je opisano v strani o zalogah in nabavi.
Slovenske posebnosti, ki jih migracija ne sme prezreti
Poslovanje v Sloveniji ima zahteve, ki jih je treba preveriti, še preden začnete prenašati podatke. Izdajanje in prejemanje e-računov, davčno potrjevanje računov pri FURS, obračun DDV in oddaja podatkov prek eDavki so procesi, ki morajo delovati od prvega dneva po preklopu, ne šele po nekaj tednih.
Microsoft lokalizacijo Business Central neposredno zagotavlja za izbrano skupino držav, za druge pa so na voljo lokalizacijske aplikacije partnerjev, ki jih najdete na tržnici Marketplace. Pred podpisom pogodbe zato od partnerja zahtevajte jasen odgovor, kako je za Slovenijo rešena lokalizacija, kdo jo vzdržuje in kaj se zgodi ob vsaki večji posodobitvi. Podrobneje je to opisano na strani o Business Central v Sloveniji.
Prav tako je pomembno vedeti, da se lokalizacije lahko spreminjajo. Microsoft je na primer v valu izdaj 2026 release wave 2 (različica 29) francosko različico preoblikoval v nabor razširitev nad mednarodno aplikacijsko osnovo W1. Za slovenskega uporabnika to pomeni predvsem eno: lokalizacijo obravnavajte kot živ del rešitve, ki ga je treba preizkusiti ob vsaki večji različici.
Strategija preklopa
Preklop je trenutek, ko stari sistem preneha biti vir resnice. Obstajata dva osnovna pristopa.
| Pristop | Kako deluje | Primerno za |
|---|---|---|
| Hkraten preklop | Stari sistem se zapre, novi prevzame vse naenkrat | Manjša podjetja z enostavnimi procesi |
| Fazen preklop | Po modulih, družbah ali lokacijah | Skupine podjetij, proizvodnja, več skladišč |
Preklop velja načrtovati ob koncu obračunskega obdobja, ko so odprte postavke najmanj. Dogovorite se, kdaj se v starem sistemu preneha knjižiti, kako se prenesejo še zadnji dokumenti in kdo je tisti, ki naredi končno primerjavo stanj. Računovodja podpiše, da sta saldakonti in glavna knjiga v obeh sistemih usklajena.
Če izberete fazen pristop, dobro premislite o vmesnem obdobju, ko dva sistema delujeta vzporedno. Povezave med njima so lahko zahtevne; glejte integracije Business Central.
Testiranje: poskusne selitve in sprejem
Prva selitev nikoli ni zadnja. Običajno jih je več, vsaka pa je boljša od prejšnje: poskusna selitev v testno okolje, popravki preslikave, ponovna selitev, nato uporabniški sprejemni testi.
Pri testih ne preverjajte samo, ali so zapisi prišli. Preverite, ali so rezultati enaki:
- vsote na kontih, saldakonti in odprte postavke se ujemajo s starim sistemom;
- vrednost zalog po skladiščih je enaka;
- DDV obračun za testno obdobje daje pričakovan rezultat;
- izdaja računa, plačilo in knjiženje potekajo od začetka do konca z dejanskim uporabnikom;
- poročila, ki jih podjetje uporablja za vodenje, dajejo iste številke.
Microsoft v spletni različici omogoča obnovo okolja na katero koli točko v zadnjih 28 dneh, do desetkrat na koledarski mesec, v isti regiji Azure in isti lokaciji, vendar le s plačljivo naročnino. To je odlična podlaga za ponovljive poskusne selitve: okolje po neuspešnem poskusu vrnete na znano točko.
Uporabniki naj se usposobijo, preden gredo v živo. Za načrtovanje glejte usposabljanje za Business Central.
Načrt povratka
Načrt povratka je dokument, ne občutek. Določiti mora več stvari: pogoj, pri katerem se odločite za vrnitev, rok, do katerega je vrnitev mogoča, in postopek, ki ga takrat izvedete.
Stari sistem naj po preklopu ostane dosegljiv vsaj v načinu branja, dokler ni potrjen prvi zaključek obdobja. Obnova okolja v oblaku ni povratek na stari sistem; je le varovalo znotraj Business Central. Če so se v novem sistemu že izdajali računi, je vrnitev bistveno bolj zapletena, zato je mejo odločanja treba postaviti zgodaj, ne po prvih tednih.
Selitev med različicami Business Central
Kdor je že v spletni različici, se z migracijo sooča drugače. Business Central v spletu izdaja dve večji posodobitvi na leto, aprila in oktobra, ter mesečne manjše posodobitve, ki vsebujejo tudi kritične popravke in regulatorne spremembe. Spletna različica sodi pod Microsoftovo politiko Modern Lifecycle Policy z neprekinjenimi posodobitvami storitve.
Razpored je pomemben za načrtovanje:
- obdobje posodobitve večje različice se začne ob splošni razpoložljivosti in traja pet mesecev;
- obstoječim okoljem je različica ponujena približno teden dni po izidu, nato sledi mesec dni odloga;
- predogledna peskovniška okolja se odprejo približno mesec dni pred izidom, marca in septembra, in se izbrišejo 30 dni po uradni izdaji;
- privzeto okno posodobitve je od 20. do 6. ure po lokalnem času države; skrbnik ga lahko spremeni, najmanj na šest ur, posodobitve, ki se v oknu ne končajo, pa se prekličejo in ponovno načrtujejo čez sedem dni.
V praksi to pomeni, da morate razširitve in prilagoditve preizkusiti v predogledni peskovnici, še preden se posodobitev dotakne produkcije. Podjetja z veliko lastnimi razširitvami naj vnaprej preverijo, kaj prinašajo prilagoditve in kako se obnašajo ob novi različici. Pregled izdaj je na strani o različicah Business Central, o gostovanju pa na strani o Business Central v oblaku.
Pogoste napake pri migraciji
Najpogostejše napake niso tehnične. Gre za organizacijo:
- Čiščenje je prepuščeno partnerju. Partner ne ve, kateri kupec je neaktiven; to ve vaša prodaja.
- Zgodovina se prenaša brez razloga. Vsak dodaten zapis podaljša testiranje.
- Začetna stanja niso podpisana. Brez potrditve računovodje se razlike odkrijejo šele ob zaključku obdobja.
- Preklop je v prometnem obdobju. Konec meseca ali leta je slab trenutek za prve korake v novem sistemu.
- Ni povratnega načrta. Ko gre kaj narobe, nihče ne ve, kdo odloča.
- Uporabniki se ne učijo vnaprej. Podjetje začne delati v sistemu, ki ga ne pozna.
Širši pregled najdete v članku o napakah pri ERP projektih. Za splošni potek uvedbe glejte implementacijo Business Central, stroške licenc pa na strani o cenah.
Kako do izkušenega partnerja
Migracijo izvede integrator, mi pa vas z njim povežemo. Pošljite opis izvornega sistema, obsega podatkov in želenega roka, mi pa poiščemo partnerja, ki ima izkušnje s podobnimi prehodi. Storitev je brezplačna in za vas nezavezujoča.
Pogosta vprašanja
Koliko časa traja migracija na Business Central?
Trajanja ne moremo navesti brez poznavanja podjetja, ker je odvisno od izvornega sistema, kakovosti podatkov, obsega zgodovine in števila uporabnikov. Excel z urejenimi šifranti je povsem druga zgodba kot star ERP z več gospodarskimi družbami. Realen rok vam po pregledu stanja poda izbrani partner.
Ali moram v Business Central prenesti vso zgodovino?
Ne nujno. Običajno se prenesejo šifranti, odprte postavke in začetna stanja, zgodovina knjiženj pa le toliko, kolikor jo potrebujete za primerjave in nadzor. Staro zgodovino lahko ohranite v arhivu ali v starem sistemu v načinu branja. Obveznosti hrambe knjigovodskih listin uskladite z računovodjo.
Kako Microsoft podpira prehod s Business Central na strežniku v oblak?
Microsoftovo orodje za selitev v oblak omogoča selitev iz Business Central na strežniku neposredno od različice 25 naprej; različice od 15 do 24 je treba najprej nadgraditi vsaj na različico 25. Podprta sta tudi Dynamics GP in Dynamics SL od leta 2015 naprej, druge vire SQL pa je mogoče prenesti z lastnimi migracijami. Stranka z Dynamics NAV mora najprej preiti na Business Central na strežniku.
Ali lahko po napačni migraciji obnovim prejšnje stanje?
V spletni različici je mogoče okolje obnoviti na poljubno točko v zadnjih 28 dneh, do desetkrat na koledarski mesec, v isti regiji Azure in isti lokaciji, in sicer le s plačljivo naročnino. To je koristno varovalo med poskusnimi preselitvami, vendar ne nadomešča načrta povratka na stari sistem do potrditve preklopa.
Kdo naj vodi migracijo: podjetje ali partner?
Najbolje deluje delitev dela. Partner pripravi preslikavo, orodja in preklop, vaša ekipa pa potrjuje pomen podatkov: računovodja stanja in kontni načrt, skladiščnik zaloge, nabava dobavitelje. Brez vaših odgovornih oseb v ekipi migracija hitro ostane tehnično pravilna, a vsebinsko napačna.
Viri
- Microsoft Learn – Migrate data to Business Central online
- Microsoft Learn – Backup and restore environments
- Microsoft Learn – Update rollout timeline
- Microsoft Learn – Update management in the admin center
Imena programske opreme so blagovne znamke njihovih izdelovalcev in so navedena zgolj informativno. Spletno mesto je neodvisno in ni povezano z nobenim izdelovalcem.