Migreren naar Odoo: van Excel, boekhoudpakket of oud ERP

Een Odoo migratie is zelden een technisch probleem alleen. De lastigste vragen zijn bedrijfskundig: welke data neemt u mee, welke historie heeft nog waarde, en op welk moment schakelt u om zonder dat facturatie, voorraad of btw-aangifte stilvalt? Wie dat vooraf beantwoordt, houdt de overstap beheersbaar, ook als het bronsysteem een verzameling Excel-bestanden is.

Op deze pagina leest u hoe u overstapt naar Odoo vanuit drie veelvoorkomende uitgangspunten en hoe u een bestaande Odoo-omgeving naar een nieuwere versie brengt. De tekst is geschreven voor mkb-bedrijven en middelgrote organisaties in Nederland, waar de boekhouder of accountant bijna altijd meekijkt. Een algemeen overzicht van ERP-migraties vindt u in onze gids over ERP-migratie.

Twee soorten migratie: naar Odoo en binnen Odoo

Het woord migratie dekt in de praktijk twee verschillende trajecten.

• Migratie naar Odoo: u verlaat een bestaande werkwijze (Excel, een los boekhoudpakket, een ouder ERP-systeem) en zet stamdata, openstaande posten en eventueel historie over.
• Migratie binnen Odoo: u brengt een bestaande Odoo-database naar een nieuwere hoofdversie, vaak met aanpassingen en gekoppelde apps die mee moeten.

Beide trajecten hebben een testomgeving, een draaiboek en een terugvalplan nodig. Het verschil zit in de inspanning. Bij een overstap van buiten is het opschonen en vertalen van data het grootste werk. Bij een versie-upgrade is het vooral de vraag of maatwerk en koppelingen de nieuwe versie overleven.

Vanuit welk systeem stapt u over?

Van Excel en losse bestanden

Excel is het meest voorkomende vertrekpunt. Het voordeel: u weet precies wat erin staat. Het nadeel: er is geen afdwingbare structuur. Dezelfde klant staat onder drie schrijfwijzen, een artikelcode is soms tekst en soms getal, en btw-codes zijn vrije invoer.

Begin daarom met een inventaris per bestand: wat is de bron van waarheid, wie onderhoudt het, en welke velden hebben echt betekenis voor Odoo? Een artikelbestand met tientallen kolommen levert vaak maar een handvol velden op die in de eerste versie nodig zijn. De rest kan later, of hoort in een aparte module.

Van een boekhoudpakket

Wie vanuit een boekhoudpakket komt, raakt vooral het financiële deel. Het gaat om het rekeningschema, relaties, openstaande debiteuren en crediteuren, openingsbalans en bankkoppelingen. Het rekeningschema is het gesprek dat u met uw accountant voert, niet met de ICT-leverancier: welke grootboekstructuur wilt u houden en welke rapportagewensen volgen daaruit?

Stapt u over van Exact Online, lees dan ook onze pagina over Exact Online om te zien welke functies u hebt gebruikt en welke u in Odoo moet inrichten. Hoe de financiële kant in Odoo werkt, staat in boekhouding en financiën in Odoo.

Van een ouder ERP-systeem

Bij een ouder ERP is er meer te verliezen en meer te winnen. Er zit jarenlange data in, vaak met afwijkende structuren, eigen velden en procesafspraken die niemand meer kan uitleggen. Gebruik de migratie als moment om te beslissen wat u niet meeneemt. Een offerte uit een afgesloten jaar of een artikel dat nooit meer wordt besteld hoeft zelden in het nieuwe systeem.

Is het huidige ERP nog in gebruik maar wilt u eerst een onafhankelijk oordeel over wat er staat, dan helpt een audit of projectovername ook bij een lopend Odoo-project dat vastloopt.

Welke data neemt u mee?

Een goede indeling scheidt wat nodig is om morgen te werken van wat alleen voor raadpleging dient.

Let op de wettelijke bewaarplicht: ook als u historie niet in Odoo laadt, moet de administratie raadpleegbaar blijven. Een auditfile uit het oude systeem of een bewaarde, alleen-lezen omgeving kan daarvoor voldoende zijn. Overleg dit met uw accountant, niet pas bij de eerstvolgende controle. Meer over verplichtingen leest u in onze gids over wettelijke verplichtingen bij ERP.

Hoe Odoo data importeert

Odoo biedt een eigen importfunctie die CSV en Excel (.xlsx) accepteert. Voor contacten, producten, bankafschriften, boekingen en bestellingen zijn voorgeconfigureerde sjablonen beschikbaar. Dat versnelt de eerste lading aanzienlijk, omdat de kolomnamen en de volgorde al kloppen.

Twee eigenschappen zijn voor uw planning bepalend:

1. Externe identifiers. Met een externe identifier koppelt u elk record aan de sleutel uit het bronsysteem. Zo voorkomt u dubbelen bij een tweede lading en blijven relaties tussen records, zoals klant en contactpersoon, behouden.
2. Definitief. Een import in Odoo kan niet worden ongedaan gemaakt. Een fout in de laadvolgorde of een verkeerde kolomkoppeling herstelt u dus niet met een knop, maar met een nieuwe lading of een databasekopie van vóór de import.

De praktische consequentie: laad nooit voor het eerst in de productiedatabase. Oefen op een kopie, controleer een steekproef en leg de laadvolgorde vast. Eerst bedrijfsgegevens en rekeningschema, dan relaties en artikelen, pas daarna openstaande posten, voorraad en orders.

Data opschonen voor de lading

Schoonmaken is het werk dat het vaakst wordt onderschat. Een bruikbare werkwijze:

• Zet alle bronbestanden in één structuur en geef iedere kolom een eigenaar.
• Voer dubbelcontrole uit op relaties: naam, adres, btw-nummer, KvK-gegevens.
• Normaliseer eenheden, valuta en landcodes. Euro is de standaard, maar buitenlandse leveranciers brengen vaak andere valuta en btw-regimes mee.
• Controleer btw-codes tegen wat uw btw-aangifte werkelijk vereist, zie btw-aangifte en ERP.
• Laat een gebruiker uit de praktijk, niet de projectleider, de opgeschoonde set beoordelen.

Wilt u na de overstap elektronisch factureren via Peppol, controleer dan nu al of klantgegevens zoals het adres en het identificatienummer compleet zijn. Achteraf aanvullen kost meer tijd. Achtergrond staat in onze pagina over e-factureren en ERP.

Strategie voor de omschakeling

Er zijn grofweg drie manieren om om te schakelen, elk met eigen voor- en nadelen.

Voor de financiële omschakeling kiest u een logisch moment, meestal een periode- of kwartaalgrens, zodat de openingsbalans schoon aansluit en de btw-aangifte niet over twee systemen verspreid raakt. Voor voorraad is het moment na een telling, met een stilstand in magazijnbewegingen tijdens het laden.

Hoe de omschakeling past in het hele inrichtingstraject, ziet u in de implementatie van Odoo.

Testen voordat u omschakelt

Een migratie die niet getest is, is een gok. Plan in elk geval:

• Technische test: komen alle records binnen, zijn aantallen en totalen gelijk aan de bron?
• Financiële test: sluiten debiteuren, crediteuren en de balans exact aan op de bronstanden?
• Procestest: doorloopt een gebruiker een volledige keten, van offerte tot factuur en betaling, en van inkoop tot ontvangst?
• Koppelingstest: werken bank, webshop, vervoerders en andere systemen, zie integraties met Odoo?
• Gebruikersacceptatie: ondertekenen de afdelingshoofden dat zij ermee kunnen werken?

Combineer dit met training. Gebruikers die de nieuwe schermen vooraf hebben geoefend, maken op de eerste dag minder fouten en vragen minder om terugkeer naar het oude systeem.

Terugvalplan: wat als het misgaat?

Omdat imports definitief zijn, begint een terugvalplan bij een bewaarde kopie. Leg vooraf vast:

1. Een volledige kopie van de bron en van de Odoo-database vlak vóór de definitieve lading.
2. Een duidelijk beslismoment, met een naam erbij, waarop wordt besloten door te gaan of terug te vallen.
3. Criteria voor terugval: bijvoorbeeld een financiële afwijking die niet verklaard kan worden, of een kernproces dat niet werkt.
4. Wat er met transacties gebeurt die tussen lading en terugval zijn ingevoerd.
5. Wie het oude systeem tot welke datum beschikbaar houdt, inclusief de licenties.

Een terugvalplan is geen teken van wantrouwen. Het is wat de directie nodig heeft om de omschakeling goed te keuren.

Migreren tussen Odoo-versies

Wie al met Odoo werkt, krijgt vroeg of laat te maken met een nieuwe hoofdversie. Volgens de officiële documentatie krijgt elke hoofdversie drie jaar standaardondersteuning na de release, plus twee jaar extra om de nodige upgrades uit te voeren voordat elke ondersteuning verdwijnt. Beveiligingspatches komen alleen binnen de standaardondersteuning. Uitgebreide ondersteuning is betaald en alleen beschikbaar op Odoo.sh en on-premise; daar blijven assistentie en bugfixes mogelijk, maar alleen voor zover technisch haalbaar.

De ondersteunde versiepagina noemt onder meer Odoo 17.0 (november 2023, einde standaardondersteuning september 2026), 18.0 (oktober 2024, september 2027) en 19.0 (september 2025, september 2028). Voor 20.0 was september 2026 aangekondigd, met standaardondersteuning tot september 2029. Draait u nog op 17.0, dan is de einddatum van de standaardondersteuning dus bereikt of nadert die op korte termijn.

Op Odoo Online en Odoo.sh is een upgrade naar een nieuwe hoofdversie binnen twee jaar verplicht, en tussenversies (SaaS-versies) moeten binnen enkele weken na de volgende release worden bijgewerkt. U krijgt hiervoor vooraf bericht. De SaaS-versies verschijnen elke twee à drie maanden, zijn alleen op Odoo Online beschikbaar en geven geen recht op uitgebreide ondersteuning. Wie stabiliteit wil, kiest daarom doorgaans voor hoofdversies. Meer over editie- en versiekeuzes vindt u bij versies en edities.

Voor de praktijk van een upgrade geldt: vraag eerst een geüpgradede testdatabase aan en valideer daar de nieuwe versie voordat u in productie gaat. Let op dat bepaalde diensten buiten de upgrade-SLA vallen; maatwerk en eigen modules horen daar in veel gevallen bij en moeten dus door uw integrator worden aangepast en getest.

Wat vaak breekt bij een versie-upgrade

• Eigen modules en maatwerkrapportages die verwijzen naar velden of schermen die zijn veranderd.
• Koppelingen met externe diensten die een andere API-versie verwachten.
• Communitymodules van derden die nog niet voor de nieuwe versie bestaan.
• Gebruikersrechten en automatiseringen die na de upgrade anders reageren.

Hoe zwaarder uw maatwerk, hoe eerder u moet beginnen. Ons overzicht over Odoo-maatwerk legt uit waarom zuinig maatwerk de latere upgradekosten beperkt.

Veelgemaakte fouten

De fouten bij een migratie zijn weinig verrassend, maar worden telkens herhaald. Zie ook onze analyse van fouten in ERP-projecten.

• Alles meenemen. Wie jaren aan historie laadt, vertraagt het project en neemt oude fouten mee.
• Zonder eigenaar voor de data. Als niemand verantwoordelijk is voor de kwaliteit van de bron, komt die kwaliteit er niet.
• Eerste lading in productie. Imports zijn definitief; oefenen doet u op een kopie.
• Accountant te laat betrokken. Het rekeningschema, de openingsbalans en de bewaarplicht horen vroeg op tafel.
• Omschakelen midden in een periode. Dat maakt afsluiten en btw-aangifte onnodig ingewikkeld.
• Geen terugvalplan. Zonder duidelijke criteria wordt een mislukte omschakeling een crisis.
• Upgrade uitstellen tot de laatste dag. Dan botst de einddatum van de ondersteuning met de agenda van uw integrator.

Wie doet wat in het traject?

Een migratie slaagt wanneer de rollen helder zijn. De integrator richt Odoo in, bouwt de laadscripts en begeleidt de test. U levert de data, de eigenaar per gegevensgroep en de beslissingen. Vraag in de offerte expliciet wat onder de migratie valt: alleen het laden, of ook het opschonen, de afstemming met de accountant en de nazorg na de omschakeling.

Het budget hangt af van het aantal modules, de datakwaliteit en het maatwerk; zie prijzen en kosten van Odoo voor wat de licentie zelf betreft. De uitvoeringskosten van de migratie bepaalt uw integrator op basis van een inventarisatie, niet op basis van een rekenregel.

Hoe vindt u een integrator die migraties beheerst?

Vraag potentiële partners naar hun werkwijze, niet alleen naar referenties: hoe testen zij een lading, hoe leggen zij de terugval vast, en hoe gaan zij om met uw accountant? Een goede integrator laat een draaiboek zien en geeft toe wat niet in één keer lukt. Onze pagina over een Odoo-integrator kiezen geeft concrete selectievragen.

ERP Integrator is een gratis bemiddelingsdienst. Wij koppelen u aan een ERP-integrator die past bij uw project; de migratie zelf voert die integrator uit. Wij zijn niet gelieerd aan Odoo of aan andere softwareleveranciers.

Een korte checklist voor de start

• Is vastgelegd welke systemen en bestanden de bron zijn, met een eigenaar per bron?
• Is besloten welke historie mee gaat en welke wordt gearchiveerd?
• Is de accountant betrokken bij rekeningschema, openingsbalans en bewaarplicht?
• Is de omschakeldatum gekozen op een periodegrens?
• Is er een testdatabase en een gedocumenteerde laadvolgorde?
• Is een terugvalplan met beslismoment en criteria goedgekeurd?
• Zijn gebruikers getraind vóór de omschakeling?
• Staat de volgende Odoo-upgrade al in de planning?

Met deze punten beantwoord is de overstap naar Odoo een gepland project met een einddatum, geen sprong in het diepe.

De genoemde softwarenamen zijn handelsmerken van hun respectievelijke eigenaren en worden uitsluitend ter informatie vermeld. Deze site is onafhankelijk en niet verbonden aan een softwareleverancier.