Odoo data-migratie playbook
Data-migratie is de plek waar de meeste Odoo-projecten stilletjes budget verliezen. Niet omdat de technische taak moeilijk is — dat is ze niet — maar omdat niemand de datakwaliteitsbeslissingen op zich neemt; ze worden uiteindelijk om 23u door een stagiair met een spreadsheet genomen, de avond voor de go-live.
Wij hebben data gemigreerd naar Odoo voor retailers, fabrikanten, dienstverleners en distributeurs. Het playbook is bijna elke keer hetzelfde: bepaal de doelen, schoon stroomopwaarts, migreer in golven, valideer hard. Teams die het volgen gaan met vertrouwen live; teams die improviseren besteden de eerste maand na go-live aan datacorrectie in plaats van aan hun business.
Deze gids is de versie die we klanten op dag 1 van de migratiestream geven. Lees ze vóór je iets exporteert uit je legacy. Zeker als je legacy een map met Excels is — uit ervaring zijn dat de projecten die het snelst ontsporen.
Beslis wat migreert en wat niet — voor je een tool aanraakt
De beste beslissing in een migratie is wat NIET migreert. Oude klanten die in drie jaar niets bestelden? Archiveren, niet migreren. Producten al vijf jaar uit het assortiment maar nog in de catalogus? Idem. Openstaande facturen uit 2019 die juridisch al afgeschreven zijn? Niet migreren, documenteren.
Minder data in Odoo betekent snellere rapporten, schonere dashboards, blijere gebruikers en een veel lagere migratiekost. We hebben ERP-databases met 60% zien krimpen tijdens migratie zonder waardeverlies — en met meetbare prestatiewinst nadien.
- Beslis wat migreert en wat niet — eerste en belangrijkste keuze
- Archiveer oude klanten, producten, transacties — verplaats ze niet
- Enkel openstaande transacties — gesloten historiek mag in legacy of datawarehouse blijven
- Minder data = sneller Odoo, schone dashboards, blijere gebruikers
- Documenteer de knip — auditors en finance vragen ernaar in jaar 1
Stamdata eerst, transacties laatst
Migreer altijd in deze volgorde: rekeningenstelsel, partners (klanten, leveranciers, contacten), producten, dan openingsbalansen en openstaande transacties. Elke laag steunt op de vorige. Een stap overslaan geeft facturen die naar onbestaande klanten wijzen, of stockbewegingen met fantoomproducten.
We testen elke laag onafhankelijk vóór we de volgende stapelen. Partners laden en valideren? Dan producten. Producten valideren? Dan opening AR/AP. Discipline betaalt elke keer terug omdat fouten geïsoleerd blijven in de laag waar ze ontstonden.
- Volgorde: rekeningenstelsel → partners → producten → openingsbalansen → openstaande transacties
- Test elke laag onafhankelijk vóór de volgende
- Partners = klanten, leveranciers, contacten — splits de imports
- Producten = varianten, eenheden, BoM's — modelleer zorgvuldig
- Openingsbalansen tot op de cent gereconcilieerd met legacy proefbalans
Schoonmaak gebeurt stroomopwaarts, niet in Odoo
Importeer geen vuile data om ze in Odoo schoon te maken. Maak ze schoon in de staging-spreadsheet of staging-DB en importeer dan de schone versie. Schoonmaken in Odoo = live data schoonmaken: operationeel risico, audit-issues, veel trager werk.
Bouw een staging-zone die het Odoo-doelschema spiegelt. Alle deduplicatie, adres-normalisatie, mapping en validatie gebeuren daar. De import naar Odoo moet saai zijn: nette CSV's naar nette modellen, met een audit trail van wat wanneer geladen is.
- Schoon stroomopwaarts in staging, nooit live in Odoo
- Staging-schema is spiegel van Odoo-doel — zelfde velden, zelfde types
- Dedupliceer partners, normaliseer adressen, valideer btw vóór import
- Veld-mapping gedocumenteerd in een gedeeld document, afgetekend
- Audit trail: wat geladen is wanneer, door wie, met welk bestand
Migreer in golven — nooit big-bang
We draaien altijd minstens drie golven: een eerste om de echte vorm van de data te ontdekken, een tweede om de schoongemaakte set te valideren, en een laatste cut-over naar productie. Veel projecten hebben er vier of vijf nodig. Elke golf levert een betrouwbaar import-script en betrouwbare data.
De cut-over wordt gerepeteerd op een staging-kopie van productie, idealiter twee keer. We klokken, documenteren elke stap, voorzien rollback. Doel: op de go-live nacht wordt niets voor het eerst gedaan.
- Drie tot vijf golven — nooit één big-bang poging
- Golf 1 = ontdekking, golf 2-3 = schoonmaak, laatste golf = cut-over
- Cut-over minstens tweemaal gerepeteerd op staging-kopie, geklokt en gedocumenteerd
- Rollback-plan gedefinieerd en getest — wat als de cut-over halfweg faalt
- Elke golf levert een betrouwbaar import-script voor de volgende
Validatie die echt problemen vangt
Tellingen en totalen — aantal partners, producten, AR-totaal, AP-totaal, voorraadwaarde — moeten tot op de cent of eenheid reconciliëren met legacy. Indien niet, is er iets mis, en je ontdekt het nu, niet bij de rapportering van maand drie.
Naast totalen samplen we altijd 50 records per type en lopen ze end-to-end door met een domein-expert. Klant Acme — klopt het adres, betaalvoorwaarden, btw-regels, prijslijst? Sampling vangt wat totalen niet vangen.
- Reconcilieer tellingen en totalen tot op de cent / eenheid tegen legacy
- Sampel 50 records per type en loop end-to-end met een domein-expert
- Run proefbalans en voorraadwaardering in beide systemen op dag 1 van go-live
- Valideer btw-nummers tegen officiële registers (VIES) voor EU-partners
- Sign-off van finance, sales, supply chain vóór 'migratie klaar'
Migratiefouten die het meest kosten
Dit zijn de fouten die we migraties zien ruïneren bij klanten die ons niet vooraf engageerden.
- Alles migreren omdat niemand de knip durft maken — opgeblazen database vanaf dag 1.
- Data schoonmaken in Odoo na import — operationeel risico, audit-issues, veel trager.
- Eén big-bang migratie — geen repetitie, geen rollback, paniek op go-live nacht.
- Geen reconciliatie tegen legacy-totalen — problemen duiken op bij rapportering maand drie.
- Domein-experts niet betrokken bij sample-validatie — technisch correct, business gebruikt rommel.
Metrics die bewijzen dat de migratie geslaagd is
Dit zijn de cijfers die we vragen op go-live + 30 dagen. Ze tonen of de data te vertrouwen is.
- Proefbalans in Odoo gelijk aan legacy proefbalans tot op de cent op cut-over.
- Voorraadwaardering in Odoo gelijk aan legacy tot op de eenheid op cut-over.
- Nul data-gerelateerde blokkerende issues in week 1.
- Sample van 50 partners, 50 producten, 50 transacties end-to-end gevalideerd door experts.
- Database 30-60% kleiner dan legacy — bewijs dat de knip-beslissingen werkten.
Hoe we data-migraties aanpakken bij Flydoo
We starten elke migratie met een 'data day' — sales, supply chain, finance, IT samen voor een halve dag om te beslissen wat migreert en wat niet. Output: een geschreven scope-document, getekend door de hoofden van elke functie. Die scope is het contract van de migratiestream.
Daarna is het discipline: staging-zone, mapping-document, golfplan, repetitie, cut-over, validatie. Niets spectaculairs. Wat een vlotte migratie scheidt van een pijnlijke is niet de tooling — het is de bereidheid om het saaie werk in de juiste volgorde te doen.
- Data day — geschreven scope, getekend door hoofden van elke functie
- Staging-zone is spiegel van Odoo-doel, alle schoonmaak gebeurt daar
- Drie tot vijf golven — ontdekking, schoonmaak, cut-over
- Cut-over tweemaal gerepeteerd op staging-kopie, geklokt en gedocumenteerd
- Validatie door domein-experts vóór 'klaar' — geen uitzonderingen
Praktische checklist voor een migratie die je go-live niet ruïneert
Loop deze lijst af met je projectleider en finance. Meestendeels afgevinkt = gezonde migratie.
- Knip-beslissing gedocumenteerd — wat migreert, wat niet, getekend door functiehoofden
- Staging-zone gebouwd, spiegel van Odoo-schema
- Veld-mapping gedocumenteerd in een gedeeld document, afgetekend
- Drie of meer migratiegolven gepland en in de agenda
- Cut-over minstens tweemaal gerepeteerd op staging-kopie van productie
- Rollback-plan gedefinieerd en getest
- Reconciliatie-queries (proefbalans, voorraadwaarde, AR/AP) klaar en in beide systemen gerund
- Domein-experts beschikbaar voor sample-validatie in week 1
Belangrijkste inzichten
- De belangrijkste beslissing is wat NIET migreert — vroeg en op papier
- Volgorde telt: rekeningenstelsel → partners → producten → openingsbalansen → openstaande transacties
- Schoon stroomopwaarts in staging, nooit live in Odoo na import
- Migreer in golven — ontdekking, schoonmaak, cut-over — nooit big-bang
- Reconcilieer totalen tot op de cent en laat samples valideren door domein-experts
- Een database 30-60% kleiner dan legacy is gezond, geen falen
Veelgestelde vragen
Hoe lang duurt een Odoo data-migratie?
Voor een KMO met één ERP, redelijke legacy-data en een duidelijke knip-beslissing plannen we 4-8 weken migratiewerk parallel met configuratie. Voor een multi-entiteitengroep met meerdere legacy-systemen en vuile data, 3-6 maanden. De variabele die de tijd bepaalt is niet volume — het is datakwaliteit en het aantal beslissingen.
Moeten we historische transacties migreren of alleen openstaande?
Openstaande, bijna altijd. Gesloten historiek (betaalde facturen, afgewerkte verkooporders, oude voorraadbewegingen) mag in legacy of datawarehouse blijven voor referentie. Gesloten historiek migreren blaast de database op, vertraagt rapporten en voegt risico toe voor heel weinig waarde. Auditors geven om de proefbalans op cut-over, niet om regels uit 2018.
Kunnen we automatisch migreren vanuit een andere ERP?
Tools bestaan — Odoo-import, OCA-modules, custom ETL — maar 'automatisch' is het verkeerde woord. Het werk zit in mapping, schoonmaak en beslissingen, niet in bytes verplaatsen. Wij gebruiken Python-scripts voor herhaalbare transformaties en de Odoo-importwizard voor de finale load, maar het stroomopwaartse werk blijft handmatig oordeel.
Wat als de legacy data écht een puinhoop is (bv. gedeelde Excels)?
Dan wordt het migratieproject eerst een datakwaliteitsproject. We hebben klanten geholpen om partner-masters te reconstrueren uit factuur-PDF's, 40 000 contacten te dedupliceren tot 12 000 echte klanten, productcatalogi te herbouwen vanuit leverancierstarieven. Het is traag maar het is het fundament — je migreert niet rond slechte data heen.
Wie moet de migratie dragen aan klantzijde?
Een toegewezen klantlead — meestal de toekomstige Odoo product owner — gesteund door domein-experts uit finance, sales en supply chain. Het technische team (wij of jullie IT) krijgt instructies van hen. Migraties geleid door IT alleen, zonder business-eigenaar, leveren technisch propere data die niemand vertrouwt.
Hulp nodig om dit toe te passen op uw eigen context? We praten er graag over.