Cum pregătiți o migrare Odoo reușită, de la Excel sau ERP vechi

O migrare Odoo se prezintă, de obicei, în două forme. Prima este trecerea la Odoo dintr-un sistem existent: foi Excel, un program de contabilitate, un ERP vechi sau un amestec de toate trei. A doua este migrarea între versiuni ale aceluiași Odoo, atunci când o bază în producție trebuie ridicată la o versiune mai nouă. Ambele cer disciplină, dar nu aceleași gesturi. Pagina de față le tratează pe rând, din perspectiva unei firme din România.

Pentru contextul general al unui astfel de proiect, începeți cu ghidul despre migrarea unui ERP; aici rămânem la ce este specific pentru Odoo.

Ce înseamnă, concret, migrarea către Odoo

Migrarea nu este un simplu import. Este un proiect cu patru componente care se sprijină una pe alta: datele, procesele, utilizatorii și obligațiile legale. Dacă lipsește una, celelalte nu o pot compensa.

• Datele: ce se preia, în ce stare, cu ce istoric.
• Procesele: cum lucrează firma azi și cum va lucra în Odoo (aprobări, circuitul facturilor, gestiunea stocurilor).
• Utilizatorii: cine are acces, cu ce drepturi, cine a fost instruit.
• Obligațiile: facturare electronică, raportări către ANAF, închideri contabile.

Un proiect care pornește de la fișiere și abia apoi se gândește la procese ajunge să copieze în Odoo exact dezordinea din sistemul vechi. Procesul se discută întâi, datele vin după.

Din ce sistem plecați: trei scenarii frecvente

Punctul de plecare schimbă munca de pregătire mai mult decât orice altceva.

Dacă plecați de la un program românesc de contabilitate sau de la un ERP local, cum este WinMentor Enterprise, întrebarea utilă nu este „cum copiem tot", ci „ce mai avem nevoie să consultăm peste un an și în ce formă".

Reprezentarea datelor: ce se preia și ce nu

Tentația este să se mute tot. Practica bună este opusă: se preiau datele necesare pentru a lucra de a doua zi și pentru a respecta obligațiile de arhivare, iar restul se păstrează separat, consultabil.

Datele de bază

Acestea sunt fundația: parteneri (clienți și furnizori, cu CUI, adrese și condiții de plată), produse și servicii, unități de măsură, planul de conturi, depozite și locații. Documentația Odoo menționează modele de import preconfigurate pentru contacte, produse, extrase bancare, înregistrări contabile și comenzi. Ele reduc timpul de pregătire și evită greșelile de structură.

Documentele deschise și soldurile

Soldurile de deschidere (clienți, furnizori, bancă, casă, stocuri) se aliniază cu balanța la data tranziției. Facturile neîncasate, comenzile în curs și comenzile de achiziție nelivrate se preiau ca documente deschise, ca să poată fi închise normal în Odoo. Aici contabilul trebuie să fie implicat de la început, nu doar la final pentru semnare. Modul de lucru în partea financiară este detaliat în pagina despre contabilitate și finanțe în Odoo.

Istoricul

Istoricul complet al tranzacțiilor se preia rar integral. Se decid, domeniu cu domeniu, două lucruri: ce trebuie să existe în Odoo (de exemplu, pentru rapoarte comparative sau pentru istoricul unui client) și ce rămâne în arhiva sistemului vechi. Un istoric preluat „la grămadă" încarcă baza și încurcă rapoartele, fără să aducă valoare reală.

Curățarea datelor, înainte de orice import

Curățarea este etapa cea mai neglijată și cea care decide dacă proiectul pornește bine. Câteva verificări de bază:

• parteneri dubli (același client scris în trei feluri, cu CUI diferit sau lipsă);
• produse inactive, coduri neuniforme, unități de măsură amestecate;
• adrese și date fiscale incomplete, care vor bloca ulterior emiterea documentelor electronice;
• solduri care nu se reconciliază cu balanța;
• conturi și gestiuni folosite o singură dată, de mult.

Curățarea se face în fișierele sursă, nu în Odoo. Un dirigent al acestei etape (de obicei cineva din contabilitate sau din operațiuni, nu de la IT) validează fiecare fișier înainte de import.

Importul în Odoo: ce spune documentația

Odoo acceptă fișiere CSV și Excel (.xlsx). Trei detalii din documentație influențează direct planificarea:

1. Identificatorii externi evită dublurile și permit reconstituirea relațiilor din vechiul sistem (de exemplu, legătura dintre o factură și clientul ei). Fără ei, importurile succesive creează înregistrări noi, nu le actualizează pe cele existente.
2. Importurile sunt definitive și nu pot fi anulate. Nu există buton de revenire pe un import greșit.
3. Ordinea contează: partenerii și produsele se importă înaintea documentelor care le referențiază.

Consecința practică este simplă: importul se repetă de mai multe ori pe o bază de test, cu aceleași fișiere și aceleași reguli, până când rezultatul este curat. Abia apoi se rulează în producție. Dacă proiectul implică conectarea cu alte sisteme (magazin online, bancă, curier), aspectele sunt tratate în pagina despre integrări Odoo.

Strategia de tranziție: cum treceți în producție

Există două abordări mari, iar alegerea depinde de dimensiunea firmei și de toleranța la risc.

Pentru o firmă de comerț sau de servicii, o dată de tranziție aliniată la începutul unei luni contabile simplifică mult solduri și raportări. În producție, tranziția se planifică în jurul comenzilor în curs și al stocurilor intermediare. Planul trebuie să prevadă și perioada de lucru în paralel, dacă se justifică, cu o regulă clară despre care sistem rămâne „sursa adevărului".

Nu uitați de teritoriul românesc al tranziției: emiterea facturilor prin RO e-Factura, raportarea SAF-T (D406) și, unde este cazul, RO e-Transport nu se pot suspenda în timpul schimbării de sistem. Detaliile obligațiilor le găsiți în ghidurile despre facturarea electronică în ERP și despre Odoo în România; pentru fiecare, cereți integratorului o demonstrație pe baza de test, cu documente reale.

Testele: ce se verifică înainte de tranziție

Testarea nu este o formalitate. Un plan rezonabil acoperă:

• Testul de import: totalurile din Odoo coincid cu cele din fișierele sursă (număr de înregistrări, solduri, valori de stoc).
• Testul de proces: un utilizator real parcurge ciclul complet (ofertă, comandă, livrare, factură, încasare) fără ajutor.
• Testul legal: emiterea și transmiterea unei facturi electronice, generarea unui fișier de raportare, verificarea TVA.
• Testul de drepturi: fiecare rol vede doar ce are nevoie.
• Testul de volum: baza răspunde corect la numărul de utilizatori simultani estimat.

Utilizatorii cheie validează în scris. Dacă testele au fost făcute doar de integrator, firma nu a testat de fapt nimic. Instruirea utilizatorilor se pregătește în paralel; vedeți pagina despre instruirea pentru Odoo.

Planul de revenire

Înainte de tranziție, se scrie ce se întâmplă dacă ceva nu merge. Un plan de revenire util conține:

• un export complet al sistemului vechi, păstrat intact și verificat că se poate redeschide;
• o copie a bazei Odoo înainte de ultima încărcare;
• un criteriu clar, convenit în prealabil, care declanșează revenirea (de exemplu, o balanță care nu se reconciliază);
• o persoană care decide, nu un comitet;
• procedura pentru documentele emise între timp, ca să nu se piardă numerotarea.

Pentru că importul în Odoo nu poate fi anulat, revenirea se face prin restaurarea unei copii, nu prin „ștergerea" ce s-a încărcat. Aceasta înseamnă că momentul copiei contează.

Migrarea între versiuni de Odoo

Dacă Odoo este deja folosit, problema se schimbă: nu mai aduceți date din altă parte, ci ridicați baza existentă la o versiune mai nouă. Aici contează calendarul editorului.

Ritmul versiunilor și al suportului

Fiecare versiune majoră beneficiază de trei ani de suport standard, urmați de doi ani suplimentari în care puteți face mutările necesare înainte de a pierde orice suport. Suportul extins, plătit, există doar pe Odoo.sh (pentru versiuni limitate) și pe server propriu. Corecțiile de securitate se livrează doar în perioada de suport standard.

Conform paginii versiunilor suportate, calendarul este următorul:

Odoo 20.0 era anunțată pentru septembrie 2026, cu suport standard până în septembrie 2029. Versiunile intermediare (SaaS) apar la un interval de două-trei luni, sunt disponibile doar pe Odoo Online și nu dau dreptul la suport extins. Merită să verificați starea lor la momentul deciziei, pentru că ele nu sunt pentru toată lumea.

Ce se cere pe Odoo Online și Odoo.sh

Pe aceste două moduri de găzduire, trecerea la o versiune majoră este obligatorie la un interval de doi ani, iar versiunile intermediare trebuie ridicate în săptămânile care urmează unei noi versiuni. Odoo trimite un preaviz. Procedura prevede obținerea unei baze de test deja migrate, pe care validați noua versiune înainte de producție; unele servicii rămân în afara angajamentelor de nivel de serviciu ale procedurii de upgrade, deci citiți condițiile. Alegerea găzduirii este discutată în pagina despre Odoo în cloud.

Ce se verifică la un upgrade

Un upgrade nu este neutru dacă baza are personalizări. Modulele dezvoltate special, rapoartele proprii și integrările cu sisteme externe sunt primele afectate. Înainte de data de tranziție, integratorul rulează upgrade-ul pe o copie, listează diferențele și corectează. Dacă nu mai știți ce s-a personalizat în timp, un audit al proiectului Odoo este punctul de plecare logic. Pentru diferențele dintre ediții și versiuni, consultați pagina despre versiuni și ediții.

Greșeli care costă cel mai mult

• Importul direct din fișiere necurățate, în speranța că se rezolvă „pe parcurs".
• Preluarea întregului istoric fără nicio decizie, doar pentru că „se poate".
• Contabilul chemat târziu, când soldurile sunt deja încărcate și diferențele devin greu de explicat.
• Lipsa unei baze de test reprezentative, cu date reale anonimizate acolo unde e nevoie.
• Nicio dată de tranziție legată de calendarul contabil: se schimbă sistemul în plin sfârșit de lună.
• Nicio probă a obligațiilor ANAF înainte de lansare.
• Un plan de revenire inexistent sau doar declarat.
• Utilizatori neinstruiți, care continuă în paralel pe vechile fișiere.
• Un upgrade amânat până la sfârșitul suportului, când securitatea nu mai este acoperită.

Cum alegeți cine face migrarea

Migrarea este partea din proiect în care diferențele dintre integratori se văd cel mai clar. Cereți o metodă scrisă: cum se evaluează datele, cum se numesc fișierele de import, cum se raportează diferențele, cum arată planul de revenire. Un integrator care vorbește doar despre „migrare rapidă" fără aceste elemente nu a dus încă un proiect dificil până la capăt. Mai multe criterii găsiți în pagina despre implementarea Odoo.

Noi nu realizăm migrarea: punem firma în legătură cu un integrator ERP certificat, potrivit proiectului, iar acesta o execută. Pașii serviciului sunt descriși în cum funcționează punerea în legătură. Pentru o ofertă comparabilă, pregătiți înainte de discuție câteva informații: sistemul actual, modulele dorite, numărul aproximativ de utilizatori, obligațiile legale care vă privesc și o dată-țintă pentru tranziție.

Numele programelor menționate sunt mărci ale editorilor respectivi și apar doar cu titlu informativ. Acest site este independent și nu este afiliat niciunui editor.