Migreren naar Odoo vanuit SAP, Oracle of Sage
Een legacy-ERP-migratie gaat zelden over technologie. Het gaat over jaren van opgestapelde maatwerk, data en gewoonten ontwarren. Dit artikel is de playbook die onze consultants gebruiken wanneer een klant ons vraagt hen uit SAP, Oracle, JD Edwards of Sage te halen.
Legacy-ERP-migraties hebben de reputatie fout te lopen, en die reputatie is deels verdiend. De meeste mislukkingen die wij zien zijn niet technisch — het zijn beslissingen die te laat genomen werden, scopes die zonder governance groeiden, of data zonder eigenaar.
Doorheen onze portfolio haalden we fabrikanten uit SAP Business One, distributeurs uit S/4-satellieten, dienstenbedrijven uit Oracle E-Business Suite, retailers uit JD Edwards en een lange staart KMO's uit Sage 100, Sage X3 en Dynamics NAV. De patronen herhalen zich.
Wat volgt is de volgorde waarin we een migratie aanpakken. Niet elke klant heeft elke stap nodig, maar de eerste skippen is wat cutover-nachten kraakt — en reputaties.
Begin met het waarom, niet het hoe
Het eerste gesprek gaat nooit over Odoo. Het gaat over waarom het huidige ERP niet meer past en hoe succes er over twee jaar uitziet. Dat beeld stuurt al de rest: scope, sequencing, training, partnerkeuze.
Klanten die het waarom kort kunnen formuleren komen op tijd binnen. Wie dat niet kan, descopt halverwege na ernstig geld te hebben uitgegeven aan onderdelen die ze laten vallen. We dringen aan op dit gesprek vooraan.
- Documenteer de drie belangrijkste redenen om te migreren
- Bepaal het doel-operatiemodel over twee jaar
- Spreek af wat expliciet buiten scope is
- Benoem een executive sponsor die het resultaat bezit
- Beslis welke legacy-rapporten letterlijk moeten overleven
Breng in kaart wat echt wordt gebruikt
De meeste legacy-ERP's zijn 80% geconfigureerd en 20% gebruikt. Voor we Odoo scopen, doen we discovery om in kaart te brengen wat actief gebruikt wordt, door wie en hoe vaak. De antwoorden zijn vaak verrassend — en ze verkleinen de migratiescope drastisch.
Op sommige projecten haalde discovery alleen al drie modules uit scope. De klant betaalde licenties en onderhoud voor schermen die niemand in twee jaar opende. Die kost besparen financiert soms de migratie.
- Inventariseer actieve modules, schermen, rapporten en integraties
- Bevraag eindgebruikers om 'dagelijks' van 'jaarlijks' te scheiden
- Identificeer maatwerk dat puur historische redenen heeft
- Beslis wat te laten vallen, herontwerpen of herbouwen
- Publiceer de bevindingen — zichtbare beslissingen blijven plakken
Datamigratie: de langste paal
Op migratieprojecten is data-werk bijna altijd de langste activiteit. Het is ook waar de meeste kwaliteitsproblemen vandaan komen. Behandel het als een eerste-klas workstream met eigen lead, plan en kwaliteitsgates.
Wij rekenen typisch 30-40% van de projectinspanning aan data toe. Klanten die dat onderschatten zijn dezelfde die op dag drie ongebalanceerde proefbalansen vinden.
- Beslis cutover-datum per transactie-stroom
- Master data eerst, transactionele data daarna
- Iteratieve loads met kwaliteitsrapporten
- Cutover twee keer repeteren voor de echte
- Read-only snapshot van legacy bewaren na sunset
Coëxistentie en parallel run
Op grotere programma's moeten Odoo en het legacy-ERP enkele weken of maanden naast elkaar draaien. We ontwerpen coëxistentie met heldere regels: welk systeem is bron van waarheid waarvoor, hoe stroomt data, en wanneer gaat het legacy uit. Zonder die regels driften beide systemen.
Parallel run is duur — je team bedient twee ERP's. Houd het zo kort als de datakwaliteit toelaat. We mikken op twee tot vier weken parallel op kritieke processen, niet drie maanden.
- Per datadomein de bron-van-waarheid benoemen
- Minimale, betrouwbare bidirectionele flows bouwen waar nodig
- Een harde sunset-datum voor het legacy plannen
- Parallel run beperken tot weken, geen maanden
- Legacy data snapshotten bij sunset voor audit en historiek
Mensen, training en verandering
Technologische migraties falen op mensen, niet op code. Teams die de cutover overleven hebben geïnvesteerd in training, in interne champions en in eerlijke communicatie over wat anders zal zijn op dag één. Een van die drie skippen is de snelste weg naar een slechte tweede maand.
We identificeren altijd een champion per businessfunctie voor de training start. Zij beantwoorden de kleine vragen in de eerste weken, sneller dan een helpdeskticket. Zonder hen wordt elke micro-vraag een escalatie.
- Champions per businessfunctie identificeren en benoemen
- Trainen op echte scenario's, niet op demodata
- Transparant communiceren — ook over wat eerst lastiger zal zijn
- Zichtbare ondersteuning de eerste twee weken na go-live
- Retrospectief op maand één en op maand drie
Fouten die legacy-migraties doen zinken
Vijf patronen die we vaak genoeg zagen om vooraf te benoemen.
- Scope laten groeien zonder executive sponsor die terugduwt.
- Datamigratie behandelen als IT-klus in plaats van workstream.
- Op dag één elke legacy-customisatie in Odoo proberen na te bouwen.
- Maandenlang parallel draaien in plaats van weken — put het team uit.
- Live gaan zonder benoemde champions per businessfunctie.
Hoe meet je dat de migratie geslaagd is
Cijfers die we drie maanden na go-live volgen.
- Open tickets per actieve gebruiker — moet wekelijks dalen.
- Doorlooptijd op top 5 processen — terug naar baseline tegen maand 2.
- Datakwaliteitsscore op masterdata — moet stijgen versus legacy baseline.
- Boekhoudkundige proefbalans rijmt op de cent versus legacy op maandeinde.
- Gebruikerstevredenheid (lichte pulse) positief tegen maand 3.
Hoe Flydoo legacy-migraties leidt
We slaan discovery nooit over, ook als de klant zegt 'we weten wat we willen'. Twee weken gestructureerde discovery op een echte ERP-migratie spaart maanden. We mappen processen, data, integraties, rapporten; publiceren wat we vinden; maken scopebeslissingen zichtbaar.
Daarna bouwen we Odoo iteratief: een kleine slice gaat vroeg live zodat het team begint te leren, grotere modules volgen. Big-bang is voor gevallen waar coëxistentie onmogelijk is — meestal door gereguleerde rapporteringsgrenzen.
- Twee weken gestructureerde discovery vóór elke configuratie
- Discovery-bevindingen en scopebeslissingen zichtbaar publiceren
- Iteratieve go-lives waar de business het toelaat
- Champions in elke functie voor de training begint
- Minstens twee cutover-repetities, met getimede metingen
Migratie-readiness checklist
Loop deze lijst voor je een cutover-datum vastlegt.
- Top drie migratiedrijfveren gedocumenteerd en getekend door sponsor
- Twee-jaar doel-operatiemodel afgesproken en gecommuniceerd
- Discovery afgerond en gedeeld met alle stakeholders
- Datamigratieplan met kwaliteitsgates en repetitiedata
- Champions geïdentificeerd en getraind per businessfunctie
- Parallel run scope en duur afgesproken
- Sunset-datum legacy gepland en gebudgetteerd
Migraties zijn projecten, geen events
Een geslaagde migratie van SAP, Oracle of Sage is het resultaat van een gestructureerd project, geen een-week-heroïek. De technologische kant van Odoo zit goed — wie slaagt steekt energie in scoping, data en mensen, in die volgorde.
Kies een partner die dit werk al deed, die terugduwt als scope drift, en die 'nee' zegt als je het verkeerde vraagt. De juiste migratie is die waar je team drie jaar later nog trots op is.
Weeg je een migratie van een legacy-ERP, dan lopen we graag de discovery- en scoping-opties met je door voor je je vastlegt op iets groters.
Veelgestelde vragen
Hoe lang duurt een typische migratie van SAP of Oracle naar Odoo?
Voor een KMO (50-200 gebruikers) plannen we typisch 6 tot 9 maanden van kickoff tot go-live, inclusief discovery, build, datamigratie, training en cutover. Voor grotere of meer gereguleerde organisaties is 9 tot 18 maanden realistisch. Korter dan 6 maanden op een echte legacy-migratie is ofwel piepklein ofwel gehaast.
Kunnen we module per module migreren, of moet het big-bang?
Waar de business het toelaat verkiezen we sterk iteratieve go-lives — start met een afgebakende module (vaak CRM of HR), voeg dan de volgende slice toe. Big-bang is soms onvermijdelijk voor boekhouding of gereguleerde rapportering, maar het is zelden onze eerste keuze.
Hoeveel historische data migreren?
Minder dan je denkt. Open transacties en het laatste afgesloten boekjaar is een typische baseline. Oudere data gaat naar een read-only snapshot van het legacy. Tien jaar historiek migreren is zelden de moeite en het kwaliteitsrisico waard.
Verwerkt Odoo hetzelfde niveau van maatwerk als vandaag?
Waarschijnlijk wel — maar vraag of dat niveau nog nodig is. De meeste legacy-ERP's stapelen maatwerk op om historische redenen. De migratie is je kans om te resetten naar een leanere configuratie. Weersta de drang het verleden te kopiëren.
Hoe gaan we met het oude systeem om na sunset?
Houd een read-only snapshot voor audit, historiek-vragen en eventuele fiscale verzoeken. Houd het niet live met gebruikers — dat hercreëert het twee-systemen-probleem. We leveren de snapshot meestal als bevroren omgeving met gedocumenteerde retentie en decommissioning.
Wil u bespreken wat dit betekent voor uw eigen Odoo-project? We praten er graag over.