Migrarea Datelor în Business Central: Ce Se Întâmplă De Fapt Când Treci De Pe Vechiul Sistem

Majoritatea oamenilor cred că migrarea datelor înseamnă „export din sistemul vechi, import în cel nou, gata.” Dacă ai trecut deja printr-o migrare ERP, probabil râzi — sau te strâmbi.

Migrarea datelor este etapa unei implementări Business Central în care iese la iveală adevărul incomod despre datele tale moștenite. Furnizori duplicați. Articole fără cost. Clienți inactivi din 2012. Plan de conturi cu înregistrări pe care doar Mariana le înțelegea, iar Mariana a plecat acum trei ani.

Acest ghid acoperă exact ce se întâmplă în timpul unei migrări de date în Business Central — ce se mută, ce nu, cât durează cu adevărat, de ce eșuează atât de multe migrări și ce trebuie să faci înainte să înceapă procesul. Fără cosmetizări. Doar ce am învățat din zeci de migrări făcute din NAV, QuickBooks, SAP Business One, Excel, Sage și sisteme custom.

Ce Înseamnă De Fapt „Migrarea Datelor” în Business Central

Migrarea datelor nu e o copiere de fișiere. Nu e un backup-restore de bază de date. Este un proces structurat de extragere a datelor din sistemul vechi, mapare pe modelul de date Business Central, transformare pentru compatibilitate, curățare a ce nu e conform, validare a rezultatelor și încărcare într-un mediu țintă curat.

Business Central își organizează informația într-un mod propriu. „Fișa clientului” din vechiul tău sistem nu se potrivește unu-la-unu cu cardul de client din BC. BC are posting groups, dimensiuni, serii de numere și reguli de validare pe care vechiul sistem poate nu le impunea — sau le impunea diferit. Un cod de client care funcționa perfect în QuickBooks poate fi invalid în BC pentru că BC cere un format anume sau nu acceptă caractere speciale tolerate de vechiul sistem.

De asta abordarea „export în Excel și import” eșuează. Poți să bagi rândurile în sistem, dar vor da eroare la înregistrare în clipa în care cineva încearcă să le folosească — pentru că lipsesc dimensiunile, posting groups sunt greșite sau conturile G/L nu se leagă de planul de conturi.

O migrare corectă implică:

• Extracția: Scoaterea datelor din sistemul sursă, preferabil prin API sau export din baza de date, nu copy-paste din CSV
• Maparea: Stabilirea exactă a corespondenței dintre câmpurile sursă și câmpurile BC — inclusiv câmpurile BC care au nevoie de valori implicite pentru că sursa nu are echivalent
• Transformarea: Conversia formatelor de date, separarea sau unirea câmpurilor, recalcularea valorilor
• Curățarea: Eliminarea duplicatelor, corectarea inconsistențelor, dezactivarea înregistrărilor obsolete
• Validarea: Verificarea faptului că soldurile, balanțele de verificare și cantitățile de stoc se reconciliază corect

Dacă partenerul tău de implementare tratează asta ca pe o singură etapă în săptămâna go-live, ai o problemă.

Date de Bază vs. Date Tranzacționale: Ce Se Mută, Ce Rămâne

Aceasta este cea mai importantă distincție pe care trebuie să o înțelegi înainte să înceapă migrarea.

Datele de Bază (Se Mută Întotdeauna)

Datele de bază reprezintă datele de referință ale afacerii — entitățile și structurile de care depinde tot restul. Volumul lor este relativ mic, dar corectitudinea este esențială:

Volumul datelor de bază este de obicei de la sute până la câteva mii de înregistrări per tip. Un distribuitor de dimensiune medie poate avea 2.000 de clienți, 500 de furnizori, 5.000 de articole și un plan de conturi de 200 de linii. E gestionabil — dacă datele sunt curate.

Datele Tranzacționale (Se Mută Selectiv)

Datele tranzacționale reprezintă activitatea zilnică: facturi, plăți, încasări, înregistrări jurnal. Nu le migrezi pe toate. Migrezi ce e necesar pentru continuitate:

Regula de bază: migrezi ce ai nevoie pentru a opera în prima zi, restul rămâne arhivat.

Vechiul sistem devine o arhivă read-only. Păstrezi o licență (sau exportul într-o bază de date statică) ca să poți consulta tranzacții vechi, dar nu rulezi două sisteme în paralel. Fiecare client care a încercat să migreze „totul” — fiecare tranzacție istorică de la înființare — și-a văzut termenul triplat și bugetul depășit. Nu o face.

De Ce Rămâne Istoricul în Urma

Structura de înregistrare din Business Central este fundamental diferită de sistemele mai vechi. Înregistrările jurnal de articole din NAV 2013 nu se mapează unu-la-unu cu cele din BC. Tranzacțiile din QuickBooks nu au profunzimea de dimensiuni și posting groups pe care BC le așteaptă. Să forțezi 15 ani de tranzacții prin scripturi de transformare e cea mai sigură cale spre date corupte.

Păstrezi vechiul sistem pentru consultări și audit. Dacă un client contestă o factură din 2019, deschizi arhiva — exact cum ai fi făcut oricum. Nu ai nevoie de acea factură în BC.

Instrumentarul: Cum Ajung Efectiv Datele în BC

Există mai multe abordări, iar ce folosești depinde de sistemul sursă, volumul de date și buget.

Configuration Packages (RapidStart)

RapidStart Services for Business Central este instrumentul de import de date încorporat de Microsoft. Folosește configuration packages — practic șabloane Excel — care se mapează pe tabelele BC. Completezi foile Excel, le imporți, iar BC validează și creează înregistrările.

Ideal pentru: Sisteme sursă simple (QuickBooks, Xero, Excel), volume mici de date, date de bază fără complicații.

Limitări: Nu include logică de transformare. Dacă datele sursă au nevoie de reformatare — separarea unui câmp, combinarea unor valori, recalculări — faci asta în Excel înainte de import. Pentru date tranzacționale cu dependențe (o factură referă un client care referă un posting group), trebuie să încarci în exact ordinea corectă, altfel importurile eșuează.

API (Business Central API v2.0)

BC expune un API REST complet pentru crearea și actualizarea înregistrărilor. Poți scrie scripturi (PowerShell, Python, C#) care citesc din sistemul sursă și scriu în BC prin apeluri API.

Ideal pentru: Migrări complexe cu logică de transformare, sisteme cu acces API în ambele capete, date tranzacționale cu dependențe.

Limitări: Necesită efort de dezvoltare. Se aplică rate limit la API. Volumele mari iau timp — poate fi nevoie să rulezi scripturi peste noapte sau pe durata mai multor zile.

Extensii AL Custom

Pentru cele mai complexe scenarii — multi-entitate, date tranzacționale grele, sisteme cu structuri de date proprietare — partenerii construiesc extensii AL custom care gestionează întregul pipeline de migrare direct în BC.

Ideal pentru: Migrări NAV-la-BC (aceeași familie, model de date familiar), volume masive de date, reguli de validare complexe.

Limitări: Costul cel mai ridicat și timpul de construcție cel mai lung. Merită doar când celelalte metode nu pot face față complexității.

Unelte Terțe

Unelte precum Scribe, KingswaySoft și Layer2 există pentru ETL (Extract, Transform, Load) între sisteme. Se situează între sursă și BC, gestionând maparea, transformarea și tratarea erorilor.

Ideal pentru: Migrări din ERP-uri majore (SAP Business One, Sage, NetSuite) unde există conectori pre-construiți.

Limitări: Cost de licență. Curbă de învățare. Adaugi o altă unealtă într-un proces care deja are destule componente în mișcare.

Ce Folosim Noi în Practică

În practică, majoritatea migrărilor combină mai multe metode. Un pachet RapidStart pentru datele de bază, scripturi API pentru tranzacțiile deschise și poate o extensie AL pentru zonele pe care instrumentele standard nu le pot atinge. Nu există o singură unealtă „corectă” — există combinația potrivită pentru migrarea ta specifică.

Calendarul pe Care Nu Ți-l Spune Nimeni

Iată cum arată cu adevărat o migrare de date, săptămână de săptămână, pe baza proiectelor reale.

Acest calendar presupune o migrare standard — companie de dimensiune medie, un singur sistem sursă, date decent de curate. Poate merge mai repede (3 săptămâni pentru o migrare simplă din QuickBooks cu date curate) sau mai lent (8+ săptămâni pentru migrări multi-entitate, multi-sistem cu curățare intensă).

Ce nu e negociabil: Nu poți comprima toate acestea în săptămâna go-live. Dacă planul de proiect al partenerului arată „migrarea datelor” ca un singur item în ultima săptămână, poartă o discuție serioasă despre ce planifică exact — și ce omit.

Cele 5 Lucruri Care Distrug o Migrare Business Central

Am văzut aceste tipare repetându-se în zeci de proiecte. Iată ce ucide o migrare — și cum să le eviți pe fiecare.

1. Date Proaste în Sistemul Sursă

Migrarea nu repară datele proaste. Le mută dintr-un sistem în altul, adesea înrăutățind situația pentru că noul sistem aplică validări pe care cel vechi nu le avea.

Exemplul clasic: clienți duplicați. Ion Popescu există ca CUST001, CUST001-A și JS-2021. Toți au solduri deschise. Scriptul de migrare nu știe că e același client — creează trei fișe client în BC, iar acum ai creanțe împărțite pe trei înregistrări care ar trebui să fie una singură.

Repară înainte de migrare: Deduplică, standardizează, dezactivează. Rulează un audit al calității datelor înainte de a începe orice lucru tehnic. Bugetează cel puțin 20% din calendarul migrării pentru curățare — dacă partenerul tău nu vorbește despre asta, e prea optimist.

2. Extinderea Scope-ului în Timpul Migrării

Migrarea e la jumătatea săptămânii 3 când cineva spune: „De fapt, putem să aducem și istoricul de vânzări pe ultimii cinci ani? Echipa de vânzări vrea raportare istorică.”

Brusc trebuie să mapezi, să transformi și să validezi ani întregi de date tranzacționale care nu erau în scope. Deciziile de mapare se schimbă. Efortul de validare se triplează. Termenul alunecă cu săptămâni întregi.

Blochează scope-ul devreme: Definește exact ce se mută în documentul de inițiere a proiectului. Orice „hai să aducem și” merge într-un backlog de fază 2, nu în migrarea curentă.

3. Fără Buget pentru Curățarea Datelor

Companiile bugetează onorariile partenerilor și licențierea, dar nu și timpul echipei proprii pentru curățarea datelor. Apoi liderul de proiect descoperă că 30% din înregistrările de articole nu au cost, 15% din detaliile bancare ale furnizorilor sunt depășite, iar planul de conturi n-a mai fost revizuit din 2018 — și nimeni nu are timp să repare totul.

Bugetează pentru asta: Estimează realist efortul de curățare. O companie medie cu 5.000 de articole și probleme moderate de calitate a datelor va avea nevoie de 40–80 de ore de efort intern pentru curățare. Include-le în planul de proiect — sau acceptă că datele murdare intră în producție și le vei repara sub presiune după go-live (ceea ce costă de 3 ori mai mult).

4. Tratarea Migrării ca pe o Problemă Exclusiv IT

IT-ul poate extrage date și rula scripturi. Financiarul trebuie să valideze că balanța de verificare leagă. Operațiunile trebuie să confirme că stocurile coincid cu inventarele fizice. Vânzările trebuie să verifice termenele de plată și limitele de credit ale clienților.

Când migrarea e tratată ca un exercițiu tehnic deținut exclusiv de IT, etapa de validare eșuează. Nimeni din zona de business nu verifică datele până în săptămâna go-live și atunci descoperă că maparea planului de conturi e greșită sau termenele de plată ale furnizorilor lipsesc.

Fiecare departament își validează propriile date. Partenerul gestionează pipeline-ul tehnic. Echipa ta face validarea de business. Asta nu e opțional.

5. Omiterea Migrării de Test

Cea mai scumpă greșeală, fără excepție. Partenerul încarcă datele direct în mediul de producție cu două zile înainte de go-live, își încrucișează degetele și speră că totul merge.

Nu merge. Soldurile nu leagă. Posting groups sunt configurate greșit. Balanța de verificare are o diferență de 47.000 € și nimeni nu știe de ce. Go-live-ul se amână — sau, mai rău, se merge înainte cu date greșite care iau luni de zile să fie descurcate.

Fă întotdeauna cel puțin o migrare de test completă într-un mediu sandbox. Cu cel puțin două săptămâni înainte de go-live. Fiecare tip de înregistrare. Validează totul. Repară ce nu merge. Apoi fă încă un test dacă primul a avut probleme semnificative. Migrarea de test nu e un „nice-to-have” — e plasa de siguranță care prinde problemele când mai e timp să le repari.

Checklist Pre-Migrare pentru Clienți

Înainte ca partenerul să ruleze primul script de migrare, iată ce trebuie să ai deja făcut:

• Identifică toate sistemele sursă. Dacă tu crezi că ai „un singur sistem” dar depozitul folosește un WMS separat și vânzările folosesc un CRM care alimentează ERP-ul, ai trei.
• Desemnează un responsabil de date pentru fiecare domeniu. Financiarul deține G/L și clienții. Operațiunile dețin articolele și stocurile. Vânzările dețin prețurile clienților. O persoană per domeniu, care poate lua decizii.
• Rulează un audit al calității datelor. Exportă datele de bază. Sortează după data ultimei activități. Marchează tot ce e inactiv de 2+ ani pentru dezactivare. Găsește duplicatele. Identifică câmpurile critice lipsă.
• Dezactivează înregistrările obsolete. Nu șterge — s-ar putea să ai nevoie de istoric. Dar marchează clienții inactivi, articolele discontinue și furnizorii închiși ca să nu intre în BC ca înregistrări active.
• Reconciliază înainte de extracție. Balanța de verificare, creanțele pe vechimi, datoriile pe vechimi, evaluarea stocurilor — toate trebuie să lege înainte să extragi. Rezolvă reconcilierile în sistemul vechi, nu în timpul migrării.
• Standardizează denumirile și formatarea. Descrieri de articole care urmează un tipar. Nume de clienți cu capitalizare consecventă. Fără caractere speciale în coduri decât dacă BC le acceptă. Fă asta în sursă — e mai ușor decât să repari în pipeline-ul de migrare.
• Verifică detaliile bancare. O cifră greșită în contul bancar al unui furnizor generează ore de depanare a plăților după go-live. Verifică acum.
• Revizuiește planul de conturi. E ultima ta șansă să restructurezi înainte să fie blocat în BC. Unește conturile redundante. Adaugă dimensiuni. Planifică structura pe care o vrei cu adevărat, nu pe care ai moștenit-o.
• Blochează timp pentru validare. Fiecare responsabil de date are nevoie de 4–8 ore pentru a-și valida domeniul după fiecare migrare de test. Pune-le în calendar acum.

Validarea Post-Migrare: Ce Să Verifici Înainte de Go-Live

După migrarea finală în mediul de producție, iată lista de verificare — minimul pe care trebuie să-l validezi înainte să tranzacționeze cineva în BC:

Validare Financiară

• Balanța de verificare leagă cu sistemul sursă la data tăierii. Fiecare cont G/L. Nu „pe aproape.” Exact.
• Creanțele pe vechimi corespund: totalul restant și segmentele de vechime coincid cu raportul din sursă.
• Datoriile pe vechimi corespund: același standard.
• Soldurile bancare se reconciliază cu ultimul extras de cont înainte de data tăierii.
• Conturile de TVA/impozit corespund cu sistemul sursă — dacă nu, primul decont fiscal generat din BC va fi greșit.

Validare Operațională

• Cantitățile de stoc corespund cu ultimul inventar fizic, pe locație și bin dacă folosești funcționalitatea de warehouse.
• Evaluarea stocurilor corespunde cu sistemul sursă. Dacă folosești cost standard, costurile standard sunt setate corect. Dacă folosești cost real, metoda de evaluare se transferă corect.
• Comenzile de vânzare deschise sunt complete — fiecare linie, fiecare cantitate, fiecare adresă de livrare.
• Comenzile de achiziție deschise sunt complete și pot fi recepționate.

Verificări prin Eșantionare a Datelor de Bază

• Eșantion de 20 de clienți: verifică nume, adresă, termene de plată, valută, posting group.
• Eșantion de 20 de furnizori: la fel, plus detaliile bancare.
• Eșantion de 20 de articole: descriere, unitate de măsură de bază, cost, preț, categorie articol.
• Verifică planul de conturi: fiecare cont, fiecare alocare de posting group.

Validare de Sistem

• Postează o factură de vânzare de test de la cap la coadă și verifică că se reflectă corect în G/L.
• Postează o factură de achiziție de test.
• Procesează o plată de test.
• Rulează rapoarte financiare și verifică că produc rezultatele așteptate.

Regula de semnătură: Fiecare responsabil de date aprobă domeniul său în scris. Nu un mesaj pe Slack. Nu o încuviințare dintr-o ședință. O confirmare scrisă că și-au validat datele și sunt corecte. Sună birocratic. E o asigurare — pentru tine și pentru partener.

Cât Costă: Prețul Migrării în Context

Migrarea datelor este de obicei inclusă în onorariul de implementare — nu se tarifează separat — pentru că este inseparabilă de configurare. Totuși, anvergura migrării influențează semnificativ costul total al proiectului.

În contextul unei implementări Business Central:

• O implementare ușoară (8K–15K €) include de obicei migrarea dintr-o sursă simplă (QuickBooks, Xero, Excel) cu date curate. Date de bază plus tranzacții deschise. Efort tipic de migrare: 2–3 săptămâni.
• O implementare standard (18K–40K €) include migrarea dintr-un ERP structurat (NAV, SAP Business One, Sage) cu curățare moderată a datelor. Efortul de migrare este de obicei 3–5 săptămâni în cadrul proiectului.
• O implementare complexă (45K–100K+ €) include migrarea din sisteme multiple, transformări complexe sau extensii AL custom. Migrarea poate dura 5–8+ săptămâni și poate necesita un arhitect de date dedicat în echipa partenerului.

Ce crește costul migrării (în interiorul onorariului de implementare):

• Date care necesită curățare intensă înainte de a putea fi încărcate — rezolvarea duplicatelor, standardizare, completarea câmpurilor lipsă
• Surse multi-sistem (ERP + CRM + WMS care alimentează toate BC-ul)
• Volume mari de date tranzacționale (mii de facturi deschise, stocuri complexe)
• Logică de transformare custom care necesită dezvoltare AL
• Consolidări multi-entitate cu solduri intercompany de reconciliat

Ce menține costul jos:

• Date sursă curate și bine întreținute
• Un singur sistem sursă
• O echipă client care face curățarea intern, înainte ca partenerul să pună mâna pe date
• Scope clar — ai decis deja ce se mută și ce nu

Pentru o analiză mai detaliată a costurilor de implementare, vezi analiza noastră de prețuri 2026.

Concluzia

Migrarea datelor e momentul în care vine nota de plată pentru anii de neglijență în întreținerea datelor. Companiile care trec cu bine prin acest proces sunt cele care tratează calitatea datelor ca pe o disciplină continuă, nu ca pe un proiect de urgență pe care îl rezolvă în pripă înainte de go-live.

Dacă reții un singur lucru din acest ghid: începe să-ți cureți datele acum, înainte chiar să fi selectat un partener. Fiecare duplicat pe care îl rezolvi, fiecare înregistrare inactivă pe care o dezactivezi, fiecare reconciliere pe care o închizi — e timp și bani pe care nu îi cheltuiești în timpul implementării.

Și întotdeauna, dar întotdeauna, fă o migrare de test. N-am întâlnit niciodată o companie care să regrete simularea. Am întâlnit destule care au regretat că au sărit peste ea.

Ai nevoie de ajutor pentru planificarea migrării datelor în Business Central? Echipa noastră gestionează migrări din NAV, QuickBooks, SAP Business One, Sage, Excel și sisteme legacy custom. Vezi serviciile noastre de implementare sau contactează-ne pentru o evaluare a pregătirii pentru migrare.