Migrarea de la Dynamics NAV la Business Central: Ghidul Complet

Dacă firma ta rulează pe Dynamics NAV — fie că e NAV 2009, NAV 2013, NAV 2016 sau NAV 2018 — știi deja că discuția se apropie. Microsoft împinge spre Business Central de ani de zile, iar fereastra pentru o migrare planificată, fără stres, se îngustează. Probabil îți pui aceleași întrebări ca toți clienții NAV: Cât durează? Cât costă? Supraviețuiesc personalizările? Și — sincer — chiar trebuie să fac asta?

Ghidul ăsta răspunde la toate, de la cineva care a făcut-o de multe ori. Fără limbaj de vânzări, fără tactici de speriat. Doar realitatea migrării de la Dynamics NAV la Business Central — ce se schimbă, ce rămâne, ce se strică, cât costă și cum o faci fără povești de groază. Iar dacă vii de pe Dynamics AX, nu de pe NAV, găsești spre final o secțiune dedicată.

Încă te întrebi dacă Business Central chiar e altceva decât NAV (sau Navision)? Citește mai întâi comparația Dynamics NAV vs Business Central — articolul de față e ghidul practic.

---

De Ce Se Întâmplă Mutarea de la NAV la BC Acum

Să fim direcți: Microsoft nu-ți va lua NAV-ul cu forța. Dar direcția e limpede de ani de zile. Business Central e viitorul, NAV e trecutul. NAV 2018 a fost ultima versiune NAV — nu va mai apărea alta — iar decalajul dintre cele două crește în fiecare trimestru.

Sfârșitul Suportului

Dacă ești pe NAV 2016 sau mai vechi, ai trecut deja de sfârșitul suportului extins — fără patch-uri de securitate, fără actualizări legislative, fără remedieri de niciun fel. Pentru cele două versiuni încă acoperite, „suport extins” înseamnă doar remedieri de securitate: nicio funcționalitate nouă, nicio actualizare de reglementare. Iată situația fiecărei versiuni, conform paginilor de ciclu de viață Microsoft:

Versiune NAV	Suport principal încheiat	Suport extins încheiat / se încheie
NAV 2009 / 2009 R2	Demult	Încheiat
NAV 2013 și 2013 R2	Ianuarie 2018	Ianuarie 2023
NAV 2015	Ianuarie 2020	Ianuarie 2025
NAV 2016	Aprilie 2021	Aprilie 2026
NAV 2017	Ianuarie 2022	Ianuarie 2027
NAV 2018	Ianuarie 2023	Ianuarie 2028

Spus politicos: majoritatea instalărilor NAV rulează acum software nesuportat, fără patch-uri, tot mai izolat. Spus direct: fiecare lună pe o versiune veche de NAV e o lună în care ERP-ul tău se îndepărtează de ecosistemul Microsoft în care s-au mutat deja celelalte instrumente ale tale. Iar în România, unde e-Factura, SAF-T (D406) și e-Transport se schimbă des, un NAV fără actualizări legislative devine rapid o problemă de conformitate, nu doar una tehnică.

Realitatea Cloud-First

Întreaga strategie Microsoft trece acum prin cloud. Copilot, Power BI în timp real, fluxuri bancare automate, documente electronice — toate presupun o platformă conectată, actualizată continuu. NAV, chiar și în cele mai noi versiuni on-premise, stă în afara acestui ecosistem.

Business Central primește actualizări lunare. NAV nu primește nimic. După câțiva ani, diferența se cumulează — decalajul dintre ce rulezi tu și ce consideră piața standard devine un dezavantaj competitiv, nu doar un inconvenient tehnic.

Nu Doar Microsoft Împinge

Echipa IT vrea să scape de serverele de întreținut — patch-uri, backup-uri, upgrade-uri SQL Server, acces la distanță. Financiarul vrea raportare în timp real, fără exporturi în Excel. Auditorii întreabă de separarea sarcinilor și de pistele de audit pe care versiunile vechi de NAV le gestionează prost. Iar un ERP on-premise nesuportat, cu SQL Server în spate și cod nepeticit de ani de zile, e o constatare de audit care așteaptă să se întâmple.

Întrebarea nu e dacă migrezi de la Dynamics NAV la Business Central, ci când și cum. Ghidul ăsta răspunde la ambele.

---

Ce Se Schimbă De Fapt: NAV vs. Business Central

Trecerea de la NAV la BC nu seamănă cu trecerea de la SAP la Oracle. E același ADN — Microsoft a cumpărat Navision în 2002 și l-a dezvoltat continuu de atunci. Dar peste 20 de ani de evoluție înseamnă o experiență cu adevărat diferită.

Domeniu	Dynamics NAV	Business Central
Instalare	Server on-premise. Tu deții hardware-ul, licențele SQL Server, strategia de backup și telefoanele de la 2 noaptea când pică.	Cloud SaaS implicit. Microsoft îl rulează, îl actualizează, face backup. On-premise există, dar SaaS e varianta implicită și primește funcționalitățile primul.
Interfață	Client Windows (Classic sau RoleTailored în versiunile mai noi). Familiar, funcțional, datat.	Interfață modernă în browser. La fel pe desktop, tabletă, telefon. Centre de rol care chiar arată ca fiind din deceniul ăsta.
Personalizări	Cod C/AL scris direct în aplicația de bază. Fiecare upgrade însemna conflicte de cod, testare de regresie și o săptămână din timpul consultantului.	Extensii AL — cod izolat, care stă deasupra sistemului de bază. Microsoft actualizează baza, extensiile tale rămân intacte.
Licențiere	Licențe perpetue (cumperi o dată) cu plan anual de mentenanță (enhancement plan).	Abonament (SaaS): Essentials 80 USD/utilizator/lună, Premium 110 USD, Team Members 8 USD — prețuri de listă SUA din noiembrie 2025.
Actualizări	Upgrade-uri planificate cu luni înainte, cu întreruperi — sau, realist, deloc.	Actualizări lunare automate. Două valuri majore pe an (aprilie, octombrie).
Extensii	Puține. Majoritatea partenerilor construiau de la zero.	AppSource — mii de extensii gata făcute: piste de audit, fluxuri de aprobare, captură documente, integrări de curierat — instalate în minute.
AI și Copilot	Nimic. Zero.	Copilot integrat — descrieri de produse generate de AI, sugestii la reconcilierea bancară, predicția plăților întârziate, asistență la analiză, agenți. Capabilități noi la fiecare release.
Integrare	În mare parte custom — servicii web, importuri din fișiere, middleware. Fiecare, un proiect.	API-uri REST native, conectori Power Automate, Dataverse, integrare Microsoft 365. Outlook, Teams, Excel și Power BI din prima.
Mobil	Soluții terțe sau improvizații.	Aplicații native iOS și Android, aceeași interfață.
Conformitate și audit	Configurare manuală. Actualizările legislative depindeau de hotfix-uri de la partener.	Piste de audit, jurnal de modificări, instrumente GDPR integrate. Localizările și actualizările legislative vin de la Microsoft și partenerii de localizare.

Pe scurt: Business Central e ce ar fi fost NAV dacă ar fi fost reconstruit pentru cloud de la zero — ceea ce, practic, s-a și întâmplat. Treci de la „software pe care îl deții” la „serviciu pe care îl folosești”, iar asta schimbă aproape tot în felul în care firma lucrează cu sistemul.

Schimbările Tehnice Care Dau Efortul de Migrare

Tabelul de mai sus e ce vor observa utilizatorii. Tabelul ăsta e ce trebuie să acopere planul de proiect:

Domeniu	Dynamics NAV	Business Central	Impact asupra migrării
Limbaj de dezvoltare	C/AL, integrat în aplicația de bază	AL, în extensii izolate	Major. Tot codul custom trebuie retras, înlocuit sau rescris.
Câmpuri custom	Adăugate direct în tabelele standard Microsoft	Adăugate prin table extensions	Major. Modificările directe pe tabelele standard nu mai sunt posibile.
Mediu de dezvoltare	C/SIDE, integrat în NAV	VS Code cu extensia AL Language	Moderat. Dezvoltatorii schimbă unealta — în bine.
Rapoarte	Rapoarte Classic (NAV 2009) sau layout-uri RDLC (NAV 2013+)	Layout-uri Word, Excel și RDLC, Power BI	Moderat. Rapoartele Classic se refac de la zero; cele RDLC pot fi uneori adaptate.
Servicii web	SOAP și OData, configurate manual	API-uri REST, OData, conectori Power Automate	Moderat. Endpoint-urile SOAP custom devin API-uri BC.
Add-on-uri ISV	Fișiere .fob îmbinate în aplicația de bază	Extensii din AppSource sau de la ISV	Variabil. ISV-urile mari au versiuni BC; cele de nișă, adesea nu.
XMLport-uri	Import/export, personalizabile în C/AL	Același concept, scris în AL	Redus. Funcțional identic.

---

Ce Rămâne La Fel: Logica Ta de Business Supraviețuiește

Asta îngrijorează orice client NAV, iar răspunsul onest e: procesele, structurile de date de bază și felul în care gândești ERP-ul nu se schimbă nici pe departe atât cât te temi.

Structura tabelelor e familiară. Înregistrările contabile, înregistrările de clienți, de articole, de valoare — tabelele de bază nu au fost reproiectate de la zero. Structurile de date pe care financiarul le înțelege se păstrează.

Grupurile de înregistrare funcționează la fel. Grupurile de înregistrare generale pe business și pe produs, configurațiile de TVA — logica prin care tranzacțiile ajung în contabilitate e aceeași. Dacă le înțelegi azi, le vei înțelege și mâine.

Planul de conturi și dimensiunile se transferă. Planul de conturi existent poate fi migrat intact, iar dimensiunile — unul dintre cele mai puternice atuuri ale NAV — funcționează la fel în BC.

Ciclurile de vânzări și achiziții urmează același flux. Ofertă → Comandă → Livrare/Recepție → Factură. Interfața arată altfel, dar pașii sunt aceiași, până la numele câmpurilor și logica de înregistrare.

Trecerea de la C/AL la AL ține de arhitectură, nu de funcționalitate. Asta e cea mai mare neînțelegere. Da, personalizările C/AL trebuie rescrise ca extensii AL. Dar se reimplementează logica de business — ce face codul. E traducere, nu reinventare. Iar rezultatul e mai curat, mai ușor de întreținut și rezistent la upgrade-uri, cum C/AL n-a fost niciodată.

Un exemplu concret: un client NAV avea un flux de aprobare a achizițiilor scris în C/AL pe trei codeunit-uri și două tabele. La migrarea în Business Central, regulile de aprobare au rămas identice — dar în loc să fie îngropate în aplicația de bază, au devenit o extensie AL curată peste motorul standard de workflow din BC, pe care nicio actualizare Microsoft nu o atinge.

Migrarea nu e o resetare. Echipa nu va intra în Business Central ca într-un sistem străin. Va recunoaște logica, terminologia, fluxul documentelor. Curba de învățare e reală — mai ales pentru cei cu zeci de ani în clientul Windows — dar e o rampă, nu o prăpastie.

---

Căi de Migrare: Cloud SaaS vs. BC On-Premise

Când migrezi de la Dynamics NAV la Business Central, ai două opțiuni de instalare — iar alegerea îți influențează calendarul, costurile și experiența pentru ani buni.

Opțiunea 1: Business Central Cloud (SaaS)

E calea recomandată de Microsoft și, din experiența noastră, răspunsul corect pentru aproximativ 90% dintre clienții NAV.

Ce primești: Business Central pe infrastructura Azure. Microsoft se ocupă de disponibilitate, securitate, backup-uri, recuperare în caz de dezastru și fiecare actualizare. Tu îl deschizi în browser. Atât.

Avantaje:

• Fără servere de întreținut. IT-ul nu se mai ocupă de infrastructura ERP.
• Mereu la zi. Actualizările vin automat — funcționalități, securitate, conformitate.
• Integrare nativă cu Microsoft 365: Outlook, Teams, Excel și Power BI din prima.
• Extensiile AppSource se instalează din câteva clicuri, fără acces la server.
• Cost total mai mic: fără licențe SQL Server și Windows Server, fără infrastructură de backup.

Constrângeri:

• Nu ai acces direct la baza de date SQL. Raportarea merge prin API-uri sau Power BI.
• Nu ai acces la sistemul de fișiere sau la COM pe server — integrările și automatizările care depind de ele trebuie refăcute.
• Ești pe calendarul de actualizări Microsoft. Release-urile majore vin în aprilie și octombrie; le poți amâna o perioadă, dar nu le poți sări definitiv.

Pentru cine: Orice client NAV care nu are un motiv concret și solid să rămână on-premise.

Opțiunea 2: Business Central On-Premise

Versiunea on-premise există, dar e o opțiune minoritară, pentru firmele care au cerințe legale, operaționale sau contractuale să-și țină datele ERP pe servere proprii.

Compromisuri:

• Îți întreții singur infrastructura, ca pe vremea NAV.
• Actualizările sunt manuale — și fiecare versiune on-premise are o fereastră de suport limitată, deci nu-l mai poți „îngheța” cum ai făcut cu NAV.
• Unele funcționalități doar-cloud (anumite capabilități Copilot, unele integrări) lipsesc.
• Pe termen lung costă mai mult, dacă pui la socoteală infrastructura și oamenii de IT.

Pentru cine: Organizații din industrii puternic reglementate sau cu cerințe de suveranitate a datelor pe care centrele de date Azure din regiune nu le acoperă.

Recomandarea Noastră Sinceră

Dacă nu ai o obligație legală sau contractuală să rămâi on-premise, mergi pe SaaS. Economia, ritmul de funcționalități noi și simplitatea operațională arată toate în aceeași direcție. Am migrat clienți NAV în ambele variante, iar proiectele SaaS sunt constant mai rapide, mai line și mai ieftin de întreținut.

Pentru imaginea completă a costurilor, ghidul nostru de costuri pentru implementarea Business Central detaliază onorariile partenerului, licențierea și costurile ascunse.

---

Alegerea Rutei de Upgrade: Migrare Completă, Reimplementare sau Hibrid

Asta e decizia care îți influențează bugetul mai mult decât oricare alta — și depinde în primul rând de versiunea de NAV pe care o ai.

Ruta Oficială Microsoft

Nu există salt direct de la NAV la Business Central online. Conform documentației Microsoft de migrare, orice bază de date NAV trece întâi prin Business Central 14 on-premises (ultima versiune care încă rula C/AL), apoi printr-o versiune on-premises actuală și abia apoi, cu instrumentul Cloud Migration, în BC online:

Versiunea de pornire	Ruta de upgrade suportată
NAV 2015, 2016, 2017, 2018	BC 14 on-prem → BC on-prem v25 sau mai nou → BC online
NAV 2013 / 2013 R2	NAV 2018 → BC 14 on-prem → BC on-prem v25 sau mai nou → BC online
NAV 2009 SP1 / 2009 R2	NAV 2013 sau 2015 → NAV 2018 → BC 14 on-prem → BC on-prem v25 sau mai nou → BC online

Din tabel reies două lucruri. Unu: cu cât sunt mai mulți pași, cu atât „upgrade-ul tehnic” costă mai mult — o bază NAV 2009 trebuie urcată de patru ori până ajunge în cloud. Doi: chiar Microsoft oferă o alternativă — odată ajuns pe BC 14, un instrument de reimplementare mută doar esențialul (date master, solduri inițiale, configurări), fără conversia personalizărilor și fără istoricul tranzacțiilor.

Cele Trei Căi Practice

Calea 1: Upgrade tehnic (migrare completă). Datele din NAV vin cu tot cu istoric; fiecare modificare C/AL e triată și reconstruită ca extensie AL. Procesele rămân în mare aceleași; se schimbă platforma de dedesubt. Potrivită pentru: NAV 2015–2018 cu personalizări moderate, a căror logică e încă valabilă. E ce înțeleg majoritatea oamenilor prin „upgrade de NAV”.

Calea 2: Reimplementare (o iei de la capăt). Pornești de la un Business Central curat, configurat după cum lucrezi azi, și aduci datele master, soldurile și documentele deschise. Istoricul vechi rămâne într-o arhivă NAV doar-citire. Potrivită pentru: NAV 2009–2013 cu personalizări multe, adesea depășite. Firme care vor să-și regândească procesele, nu să le copieze. Nu plătești programatori să traducă cod C/AL din 2009 scris de un partener care nici nu mai există.

Calea 3: Hibrid (în etape). Financiarul și operațiunile de bază intră live primele, cu personalizările critice; restul modulelor, integrărilor și extensiilor vin în etapa a doua. Potrivită pentru: firme medii care nu-și permit o singură fereastră lungă de go-live sau unde unele module (producție, service) sunt critice, iar altele „nice to have”. E calea cu riscul cel mai mic — financiarul poate fi live în 8–10 săptămâni.

Trasee reale pe care le-am livrat:

Versiune NAV	Profil client	Calea aleasă	Durată
NAV 2009	Distribuitor regional, puternic personalizat	Reimplementare	5 luni
NAV 2013	Comerț en-gros + producție ușoară, C/AL moderat	Reimplementare	4 luni
NAV 2015	Firmă de servicii multi-entitate, peste 30 de obiecte C/AL	Hibrid (întâi financiarul, operațiunile în etapa 2)	5 luni
NAV 2017	Producător cu o singură firmă, 15 modificări C/AL	Upgrade tehnic	3 luni
NAV 2018	Firmă de distribuție, folosea deja extensii	Upgrade tehnic, rescriere minimă	2 luni

Durata în Funcție de Versiunea NAV

Versiunea ta NAV	Calea tipică	Durată	Ce determină durata
NAV 2009 și mai vechi	Reimplementare	4–6 luni	Datorie C/AL mare, rapoarte Classic de refăcut, procese de reproiectat, integrări toate custom
NAV 2013 / 2013 R2	Reimplementare	3–5 luni	Doi pași de upgrade în plus pentru un upgrade tehnic; integrări de refăcut
NAV 2015	Hibrid sau reimplementare	3–5 luni	Rapoarte RDLC parțial reutilizabile, evaluare ISV necesară
NAV 2016	Upgrade tehnic sau hibrid	2–4 luni	Datorie C/AL mai mică, date de calitate mai bună
NAV 2017	Upgrade tehnic	2–4 luni	Rută directă prin BC 14; efortul e în principal rescrierea personalizărilor
NAV 2018	Upgrade tehnic (cel mai rapid)	2–3 luni	Dacă partenerul a construit deja funcționalitățile noi ca extensii AL, rămân în mare parte datele și configurarea

Avantajul NAV 2018: dacă ești pe NAV 2018 și personalizările sunt deja extensii, ești în cea mai bună poziție posibilă — asta e varianta de 2 luni. Dacă rulezi încă modificări C/AL pe NAV 2018, adaugă 1–2 luni pentru rescrierea în AL.

Realitatea NAV 2009: nu faci un upgrade tehnic. Faci o reimplementare care, întâmplător, împarte modelul de date cu sistemul țintă. Vestea bună: Business Central standard acoperă acum lucruri care în 2009 cereau personalizări grele — gestiune de depozit, intercompany, multivalută, aprobări. Ce lua 40 de obiecte C/AL în 2009 poate însemna 5 extensii AL astăzi.

---

Procesul de Migrare: Fază cu Fază

O migrare NAV → BC urmează o structură asemănătoare cu o implementare Business Central standard, dar cu particularități care apar doar când vii de pe NAV. Dacă evaluezi parteneri, serviciile noastre de implementare acoperă tot procesul — de la evaluare la suportul post-go-live.

Faza 1: Descoperire și Evaluare (Săptămânile 1–2)

Înainte să atingem vreo linie de cod, trebuie să înțelegem cu ce avem de-a face. Faza e scurtă, dar critică.

Ce analizăm:

• Versiunea NAV, numărul de build și istoricul personalizărilor
• Toate modificările C/AL — obiecte modificate, obiecte noi, soluții ISV instalate
• Dimensiunea bazei de date, numărul de rânduri din tabele și indicatorii de calitate a datelor
• Integrările: ce se conectează la NAV, cum și cât de critic e
• Numărul de utilizatori, seturile de permisiuni și cerințele de securitate
• Add-on-urile terțe (LS Retail, Continia, Jet Reports etc.) și echivalentele lor în BC

Livrabilul: un document de evaluare care spune exact ce se mapează curat, ce trebuie rescris, ce poate fi retras, ce rută de upgrade se potrivește și cât efort presupune — înainte să te angajezi la ceva.

Rolul tău: acces la sistem (backup al bazei de date, fișierul de licență NAV, lista soluțiilor ISV) și o persoană care cunoaște istoria — ce personalizări se mai folosesc, care au fost făcute pentru cineva plecat de cinci ani, ce rapoarte chiar se rulează.

Faza 2: Proiectarea Soluției (Săptămânile 2–4)

Cu evaluarea în mână, proiectăm arhitectura țintă. Aici se iau deciziile.

• Cloud sau on-premise: decizia finală, pe baza cerințelor reale, nu a presupunerilor.
• Ruta de upgrade: upgrade tehnic, reimplementare sau hibrid (vezi mai sus).
• Strategia de extensii: ce personalizări C/AL sunt acoperite de BC standard (retrase), ce devine extensie AL (rescrise), ce înlocuim cu soluții AppSource (înlocuite).
• Reproiectarea integrărilor: ce se simplifică prin conectori BC nativi sau Power Automate și ce trebuie reconstruit.
• Domeniul migrării datelor: date master, tranzacții deschise, solduri istorice, înregistrări contabile. Cât istoric — tot? ultimii 3 ani? ultimii 5?
• Etapizare: totul deodată sau pe etape (întâi financiarul, apoi operațiunile).

Cea mai importantă discuție din faza asta: ce personalizări păstrăm. Orice NAV mai vechi de 3–4 ani are cod pe care nu-l mai folosește nimeni. Meniuri adăugate pentru un proiect din 2015. Rapoarte rulate o singură dată. Câmpuri completate șase luni și apoi abandonate. Migrarea e cea mai bună ocazie de curățenie pe care o vei avea — iar mai puține personalizări înseamnă cost, complexitate și mentenanță mai mici.

Faza 3: Migrarea Datelor (Săptămânile 3–8, se intensifică spre go-live)

Migrarea datelor din NAV are un ritm diferit de migrarea dintr-un sistem non-Microsoft.

Vestea bună: pentru că BC a evoluat din aceeași bază de cod, structurile de date sunt foarte compatibile. Majoritatea mapărilor sunt directe, numele câmpurilor sunt cunoscute, iar instrumentele sunt mature.

Procesul:

1. Extragere — datele se extrag din baza SQL a NAV. De obicei e simplu: e o bază SQL Server cu scheme bine documentate.
2. Profilare — căutăm duplicate, câmpuri obligatorii lipsă, înregistrări orfane, nepotriviri între tabelele principale și registrele auxiliare.
3. Curățare — deduplicăm clienții și furnizorii, standardizăm descrierile articolelor, închidem tranzacțiile rămase nedecontate. Partea asta e a ta — doar echipa ta știe ce e real și ce e un artefact din 2012.
4. Mapare — definim cum se mapează fiecare tabelă și câmp NAV în Business Central. Pentru tabelele standard (G/L Entry, Customer, Vendor, Item) mapările sunt bine stabilite; tabelele custom din C/AL au nevoie de reguli proprii.
5. Transformare — aplicăm regulile de business: codurile de dimensiune NAV devin valori de dimensiune BC, datele din câmpurile custom C/AL ajung în tabelele extensiilor AL.
6. Încărcare — la upgrade-ul tehnic, baza de date on-premises actualizată se replică în BC online cu instrumentul Cloud Migration. La reimplementare, datele se încarcă prin pachete de configurare (RapidStart) sau prin instrumentul de reimplementare BC 14.
7. Verificare — rapoarte de reconciliere: solduri contabile, scadențare clienți/furnizori, evaluarea stocurilor, comenzi deschise de vânzare și achiziție.

Facem cel puțin două simulări complete de migrare înainte de cea finală. Prima arată ce e stricat. A doua confirmă remedierile. Cea finală — în weekendul de go-live — trebuie să fie o rutină repetată, nu o descoperire.

Ce cere cea mai mare atenție:

• Tranzacțiile deschise — comenzi livrate parțial, livrări facturate parțial, plăți neaplicate. Mereu cele mai încâlcite.
• Dimensiunile — dacă au fost aplicate inconsecvent în NAV (și de obicei au fost), regulile de migrare trebuie să trateze valorile implicite, suprascrierile și excepțiile.
• Evaluarea stocurilor — valoarea din NAV, inventarul faptic și ce calculează BC după migrare trebuie să se potrivească la ban.

Faza 4: De la C/AL la AL — Personalizările Vechi (Săptămânile 3–8, în paralel cu datele)

E partea care generează cea mai multă anxietate — și, din experiența noastră, de obicei doare mai puțin decât se așteaptă lumea, odată ce abordarea e clară.

Ce se întâmplă: fiecare bucată de cod C/AL — rapoarte custom, pagini modificate, tabele extinse, codeunit-uri custom — trebuie reimplementată în AL. Nu poți copia cod C/AL în Business Central. Nu merge și nici n-ar fi o idee bună dacă ar merge.

Abordarea noastră, rafinată în proiectele de migrare NAV:

1. Triaj — fiecare modificare C/AL intră într-una din trei categorii:

   • Retrasă: funcționalitatea e acoperită de BC standard. O eliminăm.
   • Înlocuită: o extensie AppSource face același lucru, adesea mai bine. O instalăm.
   • Rescrisă: logica de business chiar are nevoie de o extensie proprie. O construim în AL.

2. Rescrierea a ce rămâne — reimplementarea în AL urmează aceleași reguli ca originalul C/AL: aceleași calcule, aceleași validări, aceleași declanșatoare de workflow. Se schimbă doar limbajul și arhitectura — AL stă peste aplicația de bază, pe când C/AL era țesut în ea.

3. Testare cu date reale — extensiile se testează în sandbox, cu date migrate. Scenariile care mergeau în NAV trebuie să dea aceleași rezultate în BC.

Un exemplu real: un client din producție pe NAV 2016 avea 28 de modificări C/AL — statusuri custom pentru comenzile de producție, o verificare a disponibilității materialelor, logică modificată de planificare a capacității și mai multe rapoarte. După triaj: 6 retrase (acoperite de modulul de producție din BC), 4 înlocuite (soluții AppSource pentru colectarea datelor din secție și controlul calității), 18 rescrise ca extensii AL. Dezvoltare AL totală: 18 zile, în două sprinturi. Logica de business s-a păstrat exact — echipa n-a observat vreo diferență în rezultate, doar interfața mai curată.

Rolul tău: contextul de business pentru fiecare personalizare. Trebuie să știm nu doar ce face codul, ci de ce a fost scris și dacă mai e nevoie de el. O oră din timpul tău la triaj economisește zile de dezvoltare inutilă.

Faza 5: Construire, Configurare și Integrare (Săptămânile 4–12, în funcție de scop)

În paralel cu migrarea datelor și rescrierea în AL, rulează munca standard de implementare:

• Configurarea de bază: plan de conturi, dimensiuni, grupuri de înregistrare, valute, termene de plată
• Procesele: ciclul de vânzări, ciclul de achiziții, fluxurile de aprobare
• Centrele de rol, pe fiecare profil — financiar, vânzări, achiziții, depozit, management
• Integrările: ce vorbea cu NAV vorbește acum cu BC. Un serviciu web custom devine un API BC standard; un import din fișier devine, de regulă, un flux Power Automate.
• Extensiile: rescrierile AL din Faza 4 se construiesc aici
• Raportarea: dashboard-uri Power BI, layout-uri de rapoarte, raportare financiară

Ritmul: sprinturi de 2 săptămâni. La finalul fiecăruia vezi software funcțional — nu un PowerPoint, nu o specificație. Un sandbox cu datele, configurarea și extensiile tale.

Faza 6: Testare și Acceptanță (Săptămâna 6 – final)

Testarea într-o migrare NAV are o particularitate: validarea în paralel. Echipa rulează aceleași procese în NAV și în BC și compară rezultatele.

• Închiderea de lună în ambele sisteme și compararea balanțelor
• O comandă de vânzare cap-coadă în ambele și compararea înregistrărilor contabile
• Evaluarea stocurilor în ambele și reconcilierea diferențelor
• Scenariile cele mai complexe — intercompany, multivalută, dimensiuni avansate

UAT nu înseamnă doar că sistemul merge, ci că produce aceleași rezultate de business ca cel pe care îl înlocuiește. Orice diferență se investighează — de obicei e o problemă de mapare, nu un bug.

Rolul tău: pune cei mai buni oameni pe UAT. Nu pe cine are timp liber, ci pe cine știe procesele pe dinafară și observă pe loc când scadențarul nu se potrivește sau TVA-ul iese greșit.

Faza 7: Instruire (ultimele 2–3 săptămâni înainte de go-live)

Trecerea de la clientul Windows la interfața din browser e cea mai mare schimbare pentru utilizatorii NAV. Instruirea trebuie s-o abordeze direct.

• Instruire pe roluri — financiar, vânzări, achiziții, depozit, fiecare pe procesele lui, cu scenarii reale și date migrate.
• Sesiune de navigare — căutarea, personalizarea paginilor, FactBox-urile care înlocuiesc vechile panouri NAV, scurtăturile de tastatură din clientul web.
• Sesiuni înregistrate — pentru angajații noi, cei absenți și cei care „au uitat cum se făcea”.
• Fișe de referință rapidă — o pagină pe rol, nu manuale de 50 de pagini. „Așa creezi o comandă de vânzare. Așa înregistrezi o factură de achiziție.”

Faza 8: Go-Live și Suport Intensiv (Hypercare)

Weekendul de go-live urmează un plan clar:

1. Înghețarea NAV — ultimele tranzacții introduse, instantaneu final al datelor
2. Migrarea finală — rularea repetată de atâtea ori aduce ultimele date în BC
3. Reconciliere — solduri deschise, stocuri, solduri bancare verificate
4. Comutarea — utilizatorii primesc adresa BC. Luni dimineață se loghează și lucrează.
5. Hypercare — 2–4 săptămâni de suport la cerere, pe canalul tău (Teams, Slack, WhatsApp). Zilele 1–3: toată lumea are întrebări. Zilele 4–10: apar cazurile-limită. Zilele 11–28: lucrurile se așază.

Cea mai importantă decizie de go-live: păstrează NAV accesibil doar-citire cel puțin 4 săptămâni. Dacă cineva trebuie să verifice o tranzacție veche, un cod fiscal de pe o factură din 2019 sau costul unui articol dinainte de migrare, îl găsește. Dispare teama că „nu mai găsesc nimic”, iar echipa se concentrează pe BC.

---

Ce Se Strică — și Ce Faci în Privința Asta

Orice migrare are pierderi. Codul C/AL e cea evidentă (am discutat-o mai sus). Astea sunt cele mai puțin evidente, care sparg bugetele când nu le-a estimat nimeni.

1. Add-on-uri ISV Fără Versiune BC

Majoritatea soluțiilor ISV mari — Jet Reports, Continia, LS Retail — au versiuni Business Central și căi de migrare. Cele mici, de nișă sau vechi, adesea nu. Dacă modulul tău de captură documente a fost făcut de un partener local în 2012, probabil nu va primi o versiune BC.

Ce faci: inventariezi fiecare soluție ISV în faza de evaluare și cauți echivalente pe AppSource. Pentru ce nu are continuare, fie găsești un înlocuitor, fie construiești funcționalitatea ca extensie AL.

2. Integrările pe Bază de Fișiere

Dacă NAV-ul comunică cu alte sisteme prin fișiere CSV lăsate în foldere partajate sau XML-uri citite de pe FTP, integrările astea se vor strica. Business Central SaaS nu îți dă acces la sistemul de fișiere al serverului.

Ce faci: le înlocuiești cu API-uri REST sau fluxuri Power Automate. De obicei, înlocuitorul e mai bun — timp real în loc de loturi, tratare corectă a erorilor, pistă de audit — dar e muncă ce trebuie estimată.

3. Obiectele COM și Automation

Automatizările NAV care controlau Excel, Word sau Outlook prin COM nu există în Business Central SaaS. Nu mai e niciun strat COM de Windows de apelat.

Ce faci: automatizarea Excel devine layout-uri Excel din BC sau Power BI; cea din Outlook devine add-in-ul BC pentru Outlook sau Power Automate; generarea de documente devine layout-uri Word. Mai multă muncă la început, dar înlocuiești improvizații fragile cu funcționalități suportate.

4. Rapoartele Classic (NAV 2009 și mai vechi)

Rapoartele Classic nu au nicio cale de migrare către Business Central. Se refac de la zero.

Ce faci: le reconstruiești ca layout-uri Word (facturi, extrase), layout-uri Excel (analize), dashboard-uri Power BI sau rapoarte AL. Din experiența noastră, rapoartele refăcute sunt mai bune — filtrabile și actualizate automat.

Ce supraviețuiește de fapt:

• Datele — toate, dacă vrei
• Planul de conturi și dimensiunile
• Grupurile de înregistrare și logica de înregistrare
• Procesele de business (logica se transferă, chiar dacă codul nu)
• Structura de permisiuni (tradusă, nu copiată)

---

Calendar și Costuri: Trei Profiluri de Migrare

Fiecare migrare NAV e diferită, dar se grupează în trei profiluri.

Regula practică: o migrare NAV → BC costă de obicei 50–70% dintr-o implementare Business Central nouă cu același scop. Reducerea vine din structuri de date cunoscute (mai puțină mapare), procese cunoscute (mai puțină descoperire) și utilizatori care înțeleg deja logica ERP (mai puțină instruire).

Profil 1: Upgrade NAV Ușor

Atribut	Cum arată
NAV-ul tău	NAV 2016–2018 standard, modificări C/AL minime (≤10 obiecte), date curate, o singură firmă
Scop	Financiar + aprovizionare de bază. Majoritatea personalizărilor retrase. SaaS.
Personalizări	Majoritatea retrase, 2–3 rescrieri AL mici, poate 1–2 extensii AppSource
Complexitatea datelor	Redusă — tabele standard, date curate, puține tranzacții deschise de curățat
Durată	8–12 săptămâni
Onorariu partener	8.000–18.000 EUR
Include	Evaluare, configurare, migrare date, rescrieri AL de bază, instruire, go-live, 2 săptămâni hypercare

Profil 2: Migrare NAV Standard

Atribut	Cum arată
NAV-ul tău	NAV 2013–2018, personalizări moderate (10–40 obiecte C/AL), ceva probleme de calitate a datelor, integrări
Scop	Financiar complet + aprovizionare. Personalizările de bază rescrise ca extensii AL. Raportare Power BI.
Personalizări	30–50% retrase, 5–15 rescrieri AL, 2–4 extensii AppSource
Complexitatea datelor	Medie — tranzacții deschise încâlcite, dimensiuni inconsecvente, surse multiple
Durată	3–5 luni
Onorariu partener	18.000–40.000 EUR
Include	Evaluare și proiectare completă, configurare, migrare cu mai multe simulări, extensii AL, integrări refăcute, instruire pe roluri, go-live, 4 săptămâni hypercare

Profil 3: Migrare NAV Complexă, Multi-Entitate

Atribut	Cum arată
NAV-ul tău	NAV 2009–2017, personalizări grele (peste 40 de obiecte C/AL), mai multe firme și țări, LS Retail sau alt ISV vertical, multe integrări
Scop	Configurare multi-entitate, rescriere AL extinsă, înlocuire pe etape, migrare LS Central, intercompany complex
Personalizări	Triaj și rescriere extinse. Peste 20 de extensii AL. Mai multe soluții AppSource.
Complexitatea datelor	Ridicată — mai multe baze NAV, solduri intercompany, stocuri complexe
Durată	5–9 luni
Onorariu partener	45.000–60.000+ EUR
Include	Tot ce e mai sus plus proiectare multi-entitate, intercompany, dezvoltare AL extinsă, eventual LS Central, hypercare extins

Licențele Microsoft se plătesc separat de onorariul partenerului. Din noiembrie 2025, prețurile de listă în SUA sunt 80 USD/utilizator/lună pentru Essentials, 110 USD pentru Premium și 8 USD pentru Team Members (prețurile în euro diferă de la țară la țară). O firmă de 20 de utilizatori cu 8 Essentials, 2 Premium și 10 Team Members ajunge la circa 940 USD/lună la preț de listă. Adesea e comparabil — sau chiar mai puțin — cu cât plătea pe planul de mentenanță NAV plus servere, pentru că modelul pe roluri din BC permite ca utilizatorii ocazionali să stea pe licențe Team Members.

Ce face migrarea mai scumpă:

• Multe personalizări C/AL (mai mult de rescris)
• Date master murdare, care cer curățare serioasă
• Integrări complexe care trebuie refăcute complet
• Structuri multi-entitate (intercompany, consolidare, multivalută)
• Decizii amânate care lungesc calendarul

Ce ține costurile sub control:

• Date curate — investește în curățenie înainte să înceapă migrarea
• Un project lead decis, care poate lua hotărâri fără escaladare
• Disponibilitatea de a renunța la personalizările nefolosite în loc să le rescrii
• Abordarea pe etape — întâi financiarul, apoi operațiunile
• Extensii AppSource în loc de dezvoltare custom pentru tot

Pentru defalcarea completă a costurilor, vezi ghidul nostru de costuri pentru implementarea Business Central.

---

Ce Nu-ți Spune Nimeni Despre Migrarea NAV → BC

Din implementările noastre — o bună parte dintre ele migrări de pe NAV — iată tiparele care apar iar și iar.

1. Personalizările C/AL Se Rescriu, Nu Se Migrează

Asta îi ia pe mulți prin surprindere. Nu există buton „importă codeunit-urile din NAV”. Fiecare tabelă, pagină, raport și codeunit modificat trebuie reimplementat în AL.

Dar iată ce nu spune nimeni: e un avantaj, nu un defect. După un deceniu de patch-uri, ocolișuri și soluții „temporare” devenite permanente, majoritatea instalărilor NAV cară mult cod mort. Triajul — retragi, înlocuiești sau rescrii — forțează o curățenie care altfel n-ar avea loc niciodată. Firmele descoperă frecvent că 30–50% dintre personalizări sunt depășite sau înlocuibile cu funcționalități standard.

Da, rescrierea a ce rămâne costă. Dar rezultatul e un sistem mai curat, care primește actualizările Microsoft fără ciclul de îmbinare și retestare pe care îl cereau upgrade-urile NAV. Alternativa — să ții modificările C/AL într-un sistem on-premise tot mai departe de suport — se scumpește rapid.

2. Datele din NAV Sunt Adesea Mai Curate Decât Te Temi

Firmele cu 5–10+ ani pe NAV se așteaptă la un coșmar al datelor. În practică, găsim de obicei:

• Datele financiare de bază sunt solide. Înregistrările contabile se echilibrează, registrele de clienți și furnizori se reconciliază. Partida dublă se autocorectează.
• Datele master au resturi. Clienți inactivi din 2014, furnizori dublați cu nume ușor diferite, articole fără mișcare de 3 ani. E curățenie, nu corupție — iar migrarea e momentul potrivit.
• Tranzacțiile deschise cer atenție. Comenzi livrate parțial și închise în afara sistemului, facturi plătite dar neaplicate. Există în orice sistem vechi și se rezolvă în câteva zile de lucru concentrat.
• Dimensiunile — suspectul de serviciu. Majoritatea implementărilor NAV le-au folosit prea puțin, prea mult sau inconsecvent. Migrarea e ocazia să definești o strategie clară și s-o aplici de aici înainte.

Față de firmele care vin de pe ERP-uri non-Microsoft, clienții NAV au un drum al datelor mult mai lin. Originea comună înseamnă mult mai puține probleme de mapare.

3. De Obicei Ai Nevoie de Mai Puține Licențe Complete

Pare contraintuitiv, dar e constant: când treci de la NAV la BC SaaS, ajungi de regulă cu mai puține licențe complete.

Motivul: licențierea NAV — mai ales în versiunile vechi — se baza pe utilizatori concurenți sau pe licențe complete pentru toată lumea. Un magaziner care intra o dată pe zi să tipărească o listă de picking conta ca utilizator complet. Un șef de tură care verifica stocul de trei ori pe săptămână avea licență completă.

Modelul pe niveluri din BC (Team Members la 8 USD/lună pentru consultare și sarcini ușoare, Essentials la 80 USD pentru utilizatorii de financiar și vânzări, Premium la 110 USD pentru producție și service) înseamnă că plătești pentru ce face fiecare, de fapt. E des întâlnit să treci de la 30 de utilizatori compleți în NAV la ceva de genul 8 Essentials, 2 Premium și 12 Team Members.

4. Prima Lună Pare Lentă — Apoi Accelerează

E realitatea managementului schimbării despre care nu te avertizează nimeni. În primele două săptămâni după go-live, echipa va fi mai lentă la orice. O comandă de vânzare durează cu 30% mai mult. Fișa unui client e la câteva clicuri în plus. Un jurnal contabil pare străin.

Apoi, pe la săptămâna 3–4, ceva se schimbă. Interfața devine familiară. Oamenii descoperă că butonul de căutare e mai rapid decât meniurile. Încep să-și personalizeze paginile. Iar prin luna 2–3 fac în BC lucruri care în NAV erau greu sau imposibil de făcut — exact motivele pentru care ați migrat.

Planifică încetinirea și comunic-o deschis: „În primele două săptămâni unele lucruri vor dura mai mult. E normal. Din săptămâna a patra veți fi mai rapizi decât înainte.” Așteptarea setată corect previne panica.

---

Migrarea de la Dynamics AX la Business Central

Primim întrebarea asta mai des decât ai crede: „Suntem pe Dynamics AX — putem face același lucru?” Da, dar e alt tip de proiect și e bine să știi de ce înainte să ceri oferte.

De Ce AX → Business Central Nu E un Upgrade

Business Central se trage din NAV. Dynamics 365 Finance & Operations (F&O) se trage din AX. Sunt două baze de cod diferite — AX e scris în X++, cu propriul model de date — așa că o bază AX nu se mapează pe BC cum se mapează una NAV.

Concret:

• Nu există cale de upgrade de la AX la Business Central. Upgrade-ul suportat de Microsoft din AX 2012 duce în F&O, nu în BC. AX 2009 nu are deloc cale de upgrade către Dynamics 365.
• Nu există un motor Microsoft de migrare în cloud pentru AX. Cloud Migration din BC acoperă Business Central on-premises, Dynamics GP și Dynamics SL (NAV ajunge acolo prin BC on-premises). Din aprilie 2026, partenerii pot construi pe același cadru motoare de migrare custom pentru orice sursă bazată pe SQL — dar pentru AX vorbim de instrumente de partener, nu de un produs Microsoft.
• Suportul s-a încheiat. AX 2012 R3 — ultima versiune AX — a ieșit din suportul extins în ianuarie 2023. Orice instalare AX e acum nesuportată.

Așadar, o migrare de la AX la Business Central înseamnă o reimplementare Business Central plus migrarea datelor: date master (clienți, furnizori, articole, plan de conturi), solduri deschise de creanțe și datorii, solduri contabile inițiale, documente de vânzare și achiziție deschise, cantități și costuri de stoc — încărcate prin pachete de configurare, șabloane Excel sau instrumente de partener. Istoricul tranzacțiilor rămâne de obicei într-o bază AX arhivată sau într-un data warehouse.

Business Central sau Finance & Operations?

Multor clienți AX li s-a vândut, prin anii 2000, un sistem mai mare decât aveau nevoie. Ei câștigă cel mai mult trecând pe BC.

Business Central e de obicei alegerea potrivită dacă:

• Ai până la câteva sute de utilizatori, în câteva firme
• Procesele tale sunt de distribuție, servicii, proiecte sau producție discretă standard
• O bună parte din personalizările X++ există ca să ocolească limitările AX, nu ca să susțină un proces care te diferențiază
• Costul total contează — licențele și implementările BC costă o fracțiune din cele F&O

Finance & Operations e de obicei alegerea potrivită dacă:

• Ai multe entități juridice în mai multe țări, cu servicii partajate și consolidare complexă
• Ai nevoie de gestiune avansată de depozit, producție de proces sau volume foarte mari de tranzacții
• Vrei să păstrezi istoricul și structurile din AX 2012 prin calea de upgrade suportată de Microsoft
• Personalizările tale codifică procese care chiar te diferențiază și pe care BC standard nu le acoperă

Cum Arată un Proiect AX → BC

Atribut	Proiect tipic AX → BC
Abordare	Reimplementare + migrare de date (fără upgrade de cod sau de date)
Durată	4–9 luni, în funcție de numărul de firme, module și integrări
Onorariu partener	Ca la o implementare nouă — de obicei 18.000–40.000 EUR pentru un scop standard și 45.000–100.000+ EUR pentru proiecte complexe multi-entitate
Ce consumă cel mai mult efort	Maparea dimensiunilor financiare și a structurilor de conturi din AX pe planul de conturi și dimensiunile BC, regândirea proceselor construite în jurul personalizărilor X++, refacerea integrărilor, reinstruirea pe o altă interfață

Nu te aștepta la „reducerea NAV” de 50–70% — nu există un model de date comun pe care să te sprijini. Așteaptă-te la o implementare Business Central obișnuită, cu o fază mai grea de migrare a datelor și de reproiectare a proceselor.

---

Checklist de Pregătire pentru Migrare

Înainte să vorbești cu un partener, pregătește lista de mai jos. Cu cât răspunzi la mai multe puncte, cu atât primești mai repede un calendar și un preț corecte.

Configurația Actuală

• Versiunea NAV și numărul de build (Help → About)
• Dimensiunea bazei de date (GB) și numărul aproximativ de rânduri din tabelele principale
• Lista tuturor modificărilor C/AL (obiecte modificate, obiecte noi, rapoarte custom)
• Lista soluțiilor ISV și versiunile lor (Jet Reports, Continia, LS Retail etc.)
• Numărul de utilizatori pe rol (financiar, vânzări, achiziții, depozit, producție, doar consultare)

Datele

• Numărul de clienți și furnizori activi (nu totalul)
• Numărul de articole și dacă descrierile sunt standardizate
• Volumul aproximativ de înregistrări (contabile, clienți, furnizori)
• Probleme cunoscute de calitate (clienți dublați, înregistrări orfane, solduri nereconciliate)
• Cât istoric vrei în BC (2 ani? 5 ani? tot?)

Integrările

• Fiecare sistem conectat la NAV (e-commerce, salarizare, CRM, depozit, bănci, e-Factura, raportare)
• Cum funcționează fiecare (API, fișiere, link la baza de date, export/import manual)
• Care sunt critice și care sunt opționale

Decidenții

• Sponsorul proiectului (un director care poate debloca situațiile)
• Project lead-ul (cineva cu 8–12 ore pe săptămână pentru proiect)
• Cine decide structura financiară (plan de conturi, dimensiuni, grupuri de înregistrare — greu de schimbat ulterior)
• Cine aprobă go-live-ul

Calendarul

• Fereastra preferată de go-live (evită închiderea de an, sezonul aglomerat, auditul)
• Termene fixe (sfârșitul suportului extins, reînnoirea hardware-ului de server, constatări de audit)

---

Întrebări Frecvente

Când ar trebui să migrez? Mai pot aștepta un an sau doi?

Suportul extins pentru NAV 2016 s-a încheiat în aprilie 2026. Pentru NAV 2017 se încheie în ianuarie 2027, iar pentru NAV 2018 — ultima versiune NAV — în ianuarie 2028. Să aștepți până la termen e scump: migrările făcute sub presiune, când suportul a expirat și ceva s-a stricat, costă mai mult, durează mai mult și sunt mai riscante. Cel mai bun moment e cel în care poți planifica liniștit. Începe discuția cu 6–12 luni înainte de go-live-ul dorit.

Cât costă migrarea de la NAV la Business Central?

Onorariile partenerului sunt 8.000–18.000 EUR pentru un NAV 2016–2018 puțin personalizat, cu o singură firmă, 18.000–40.000 EUR pentru o migrare standard și 45.000–60.000+ EUR pentru proiecte complexe multi-entitate — aproximativ 50–70% dintr-o implementare BC nouă cu același scop. Licențele Microsoft se plătesc separat.

Pot face upgrade direct de la NAV la Business Central online?

Nu. Ruta Microsoft trece prin Business Central 14 on-premises, apoi printr-o versiune on-premises actuală (25 sau mai nouă), apoi prin Cloud Migration. NAV 2013 trebuie să treacă mai întâi prin NAV 2018, iar NAV 2009 prin NAV 2013 sau 2015. De aceea instalările vechi aleg de obicei reimplementarea.

Ce se întâmplă cu soluțiile ISV — Jet Reports, Continia, alte module?

Majoritatea ISV-urilor NAV importante au versiuni pentru Business Central. Jet Reports există pentru BC. Continia are module BC pentru captură documente, decontări de cheltuieli și plăți. Unele instrumente devin inutile, pentru că BC acoperă nativ aceeași zonă (de exemplu, fluxurile de aprobare integrate pot înlocui un modul terț). Faza de evaluare arată ce se migrează ușor și ce are nevoie de alternative.

Pot rula NAV și Business Central în paralel în timpul tranziției?

Nu ca două sisteme de producție — și nici nu ai nevoie. Faci validare în paralel în UAT (aceleași scenarii în ambele sisteme, fără să afectezi operațiunile), apoi comuți curat. Două ERP-uri live simultan ar însemna coșmaruri de sincronizare. Varianta standard — NAV înghețat vineri, BC live luni — e mai simplă și mai sigură.

Vor funcționa rapoartele mele NAV în Business Central?

Rapoartele Classic (NAV 2009 și mai vechi) nu se transferă deloc. Nici cele RDLC din versiunile mai noi nu se transferă direct, deși layout-urile pot fi uneori adaptate. Rapoartele se refac cu layout-uri Word și Excel, Power BI pentru dashboard-uri și raportarea financiară din BC. Rezultatul e de obicei mai bun — interactiv, filtrabil, actualizat automat — decât listările statice din NAV.

Ce fac dacă sunt pe o versiune foarte veche — NAV 2009 sau mai veche?

Structurile de bază (tabele, câmpuri, înregistrări contabile) se recunosc chiar și din NAV 2009, dar un upgrade tehnic ar însemna patru pași de upgrade. În practică, clienții NAV 2009 obțin un rezultat mai bun cu o reimplementare și migrare selectivă de date. Pentru structuri complexe, planifică un efort de Profil 3: 5–9 luni, 45.000–60.000+ EUR onorariu partener; mai puțin dacă e o singură firmă dispusă să renunțe la majoritatea personalizărilor.

Pot migra de la Dynamics AX la Business Central?

Da, dar ca reimplementare, nu ca upgrade — AX și BC au baze de cod diferite și nu există cale de upgrade sau motor de migrare Microsoft pentru AX. Vezi secțiunea despre AX de mai sus pentru când e BC ținta potrivită și când F&O.

Pierd istoricul din NAV?

Nu. Cât istoric aduci în BC e o decizie, nu o limitare. Majoritatea firmelor migrează 2–5 ani de înregistrări (contabile, clienți, furnizori, articole, bănci) și toate tranzacțiile deschise. Istoricul mai vechi rămâne într-o copie doar-citire a bazei NAV. Recomandarea noastră: adu suficient istoric pentru raportări comparative (3–5 ani), arhivează restul.

Perturbă migrarea activitatea zilnică?

Proiectul rulează în paralel — echipa lucrează în NAV în timpul construirii, configurării și testării. Singurele întreruperi sunt weekendul de go-live (de obicei vineri–duminică) și curba de învățare din primele două săptămâni. Față de trecerea pe o platformă ERP complet diferită, migrarea NAV → BC e una dintre cele mai puțin perturbatoare tranziții ERP posibile.

---

Gata Să-ți Planifici Migrarea NAV → BC?

Migrarea de la Dynamics NAV la Business Central e un proiect serios — dar și cea mai previzibilă migrare ERP din ecosistemul Microsoft. Structurile de date sunt familiare, logica de business se transferă, iar perturbarea operațională se măsoară în zile, nu în luni.

Diferența dintre o migrare lină și una dureroasă se reduce la două lucruri: planificare din timp și un partener care a mai făcut asta. Din implementările noastre, din NAV și din alte sisteme, în Europa și în regiunea Golfului, am văzut ce funcționează — și ce nu.

Fie că ești pe NAV 2013, NAV 2016, NAV 2018 — sau pe Dynamics AX — hai să discutăm cum ar arăta migrarea pentru configurația ta: calendar, migrarea datelor, revizuirea personalizărilor și prețuri oneste, fără surprize.

→ Vezi serviciile noastre de implementare Business Central

Programează o discuție gratuită — 30 de minute, fără obligații, fără discurs de vânzări. Doar o evaluare sinceră a situației tale și a drumului către Business Central.

---

Vanguard 360 Solutions este partener Microsoft Dynamics 365 Business Central și LS Retail Gold Partner, cu sediul în România și proiecte în Europa, Marea Britanie, Emiratele Arabe Unite și Arabia Saudită. Printre proiectele noastre: LS Central în peste 120 de magazine în România, Pharmacy for LS Central în peste 100 de farmacii din Norvegia și arhitectura pentru un retailer cu 700 de magazine în 13 țări. Dacă vrei să afli mai întâi ce este, de fapt, Business Central, citește ghidul nostru complet despre Business Central.