Odoo upgrades
Een Odoo-upgrade is geen 'klik hier'-zaak. Het is een project met een scope, een budget, een testplan en een cut-over datum — en de volwassenheid waarmee je het behandelt bepaalt of de landing schoon is of dat je je business twee weken stuk legt.
We hebben klanten geüpgraded van v12 naar v17, v14 naar v18, v16 naar v19. Sommige duurden twee weken, andere twee maanden. De variabele is niet zozeer het versie-gat als wel de hoeveelheid custom code, het aantal OCA-modules in gebruik en de discipline van het team.
Deze gids is het playbook dat we intern volgen voor elke upgrade-opdracht. Eén ding onthouden: nooit in productie upgraden, nooit testcycli overslaan, en nooit toelaten dat de upgrade 'we kunnen meteen ook…' wordt. Scope-discipline redt het project.
Waarom überhaupt upgraden — en waarom nu
Elke major-versie is drie jaar ondersteund. Daarna geen security-fixes meer, geen Enterprise-support, geen module-updates op de App Store. Op een niet-ondersteunde versie blijven = risico en schuld opbouwen — en je upgrade toch, gewoon later en slechter.
Naast support brengt elke major echte verbeteringen: betere UX, snellere rapporten, nieuwe features in modules die je al gebruikt. We hebben klanten zien uren maandwerk winnen door alleen al van v14 naar v17 te gaan, omdat de boekhoudkundige reconciliatie zoveel beter werd.
- Elke major drie jaar ondersteund — achterop blijven = security- en feature-schuld
- Na support-cut-off: geen security-fixes, geen Enterprise, geen app-updates
- Nieuwe versies brengen UX, performance en features in modules die je al gebruikt
- Later upgraden = slechter upgraden — schuld stapelt versie per versie
- Elke twee jaar is een gezonde upgrade-cadans voor de meeste KMO's
Wat verandert er werkelijk tussen versies
Het kerndatamodel evolueert: velden hernoemd, modellen gesplitst, nieuwe modules geïntroduceerd, oude deprecated. De officiële upgrade-tool handelt het standaard af, maar weet niets van jouw custom velden, weergaven en workflows. Die zijn jouw verantwoordelijkheid — en kost.
Custom code geschreven voor v14 zal niet noodzakelijk op v17 draaien. Method-signaturen wijzigen, ORM-gedrag wijzigt, de JS-laag wijzigt (OWL-adoptie). Hoe groter je custom voetafdruk, hoe groter de upgrade. Dit is een reden waarom we klanten pushen om customisatie slank te houden.
- Standaardmodellen evolueren — Odoo's tool dekt dat
- Custom velden, weergaven, workflows = jouw verantwoordelijkheid
- Custom Python-code kan herschrijvingen vragen — signaturen, ORM-gedrag
- JS-laag diep gewijzigd (OWL) — oude QWeb / legacy JS heeft vaak updates nodig
- OCA-modules vragen hun eigen geüpgradede versie — beschikbaarheid per module checken vóór commit
De upgrade-stream — drie omgevingen, twee cycli
We werken altijd met minstens drie omgevingen: een productie-kopie (bevroren referentie), een upgrade-staging (waar de upgrade draait en getest wordt), en een finale UAT (waar gebruikers valideren). Twee testcycli minimum — één om problemen te vinden, één om fixes te bevestigen.
De cut-over naar productie wordt end-to-end gerepeteerd op staging. Geklokt, elke stap gedocumenteerd, rollback-beslispunten geïdentificeerd. Het echte cut-over weekend is dan een gekende operatie, geen experiment.
- Drie omgevingen minimum: prod-kopie, upgrade-staging, UAT
- Twee testcycli minimum — problemen vinden, fixes bevestigen
- Cut-over end-to-end gerepeteerd op staging, geklokt en gedocumenteerd
- Rollback-beslispunten gedefinieerd — wanneer breken we af
- UAT afgetekend door business vóór planning cut-over
Custom code, OCA en de afhankelijkheden die bijten
Inventariseer alle custom en OCA-modules in gebruik. Beslis per module: upgraden (en budgetteren), droppen (en de use-case naar standaard migreren) of vervangen (door een andere module). Deze beslissing drijft 60% van de upgrade-kost.
OCA-modules zijn geweldig tot het upgrade-moment. Elke module heeft zijn eigen maintainer; sommige zijn op dag één klaar voor de nieuwe versie, andere doen er zes maanden over, sommige nooit. We checken altijd de OCA-beschikbaarheid voor de doelversie vóór we offreren — verrassingen hier ruïneren budgetten.
- Inventariseer alle custom + OCA — per module beslis upgrade / drop / vervang
- Custom-code-herschrijving = 60% van upgrade-kost voor typische implementaties
- OCA-beschikbaarheid voor doelversie gecheckt vóór offerte
- Sommige OCA-modules worden nooit geüpgraded — voorzie vervanging of refactor
- Upgrade is een uitstekend moment om ongebruikte custom te schrappen — wees genadeloos
Cut-over weekend en post-go-live
Plan de cut-over in een periode met weinig activiteit — meestal een weekend. Vergrendel productie, draai de finale upgrade vanaf de laatste prod-data, voer smoke-tests uit, switch DNS / gebruikers, monitor. De meeste van onze cut-overs passen in vrijdagavond – zondagavond.
De eerste week na de upgrade is intensief. Hyper-care vanuit het implementatieteam, dagelijkse standups met key users, snelle triage van gemelde issues. De meeste issues zijn klein (weergaven, rechten, kleine data afwijkingen); enkele vragen code-fixes. Plan ervoor.
- Cut-over in low-activity venster — typisch vrijdagavond – zondagavond
- Finale upgrade vanaf laatste prod-data, niet vanaf staging-snapshot
- Smoke-tests gescript en uitgevoerd vóór gebruikers maandag terugkomen
- Hyper-care week 1 met dagelijkse standups — 80% issues opgelost in 5 dagen
- Communicatieplan voor gebruikers — wat is nieuw, wat veranderde, waar vragen stellen
Upgrade-fouten die projecten lelijk maken
Dit zijn de fouten die we het vaakst zien wanneer klanten zonder ons proberen te upgraden.
- 'Snelle' upgrade in productie zonder staging — kapotte business, geen rollback.
- Scope laten doorslaan in een redesign — elke workshop voegt werk toe, datum glijdt.
- OCA-beschikbaarheid niet inventariseren — in week drie ontdekken dat een sleutelmodule niet klaar is.
- Geen UAT-cyclus — go-live legt issues bloot aan alle gebruikers tegelijk.
- Integraties vergeten — de EDI-feed, e-commerce sync, BI-exports moeten allemaal getest worden.
Metrics die bewijzen dat de upgrade goed verlopen is
We volgen deze de twee weken na cut-over. Gezonde upgrade = gezonde cijfers.
- Cut-over afgerond binnen geplande venster — geen overloop in maandag-business-uren.
- Smoke-tests slagen vóór gebruikers maandag terugkomen.
- Aantal P1/P2 issues in week 1 onder vooraf afgesproken drempel (typisch <10).
- Alle integraties (EDI, e-commerce, betaling, BI) operationeel tegen dinsdag.
- Tevredenheidsenquête op +2 weken boven 75% positief.
Hoe we Odoo-upgrades aanpakken bij Flydoo
We starten elke upgrade met een discovery: inventaris custom modules, OCA-afhankelijkheden, integraties, klantenlijst van ergernissen om meteen mee te nemen. Uit de discovery komt een vaste-scope offerte — inclusief drop / vervang / upgrade beslissing per module.
Daarna het standaard playbook: upgrade-staging, twee UAT-cycli, cut-over repetitie, cut-over weekend, hyper-care. We laten scope-creep nooit toe tijdens de upgrade — verbeterverzoeken gaan naar de volgende kwartaal-release, niet bovenop de cut-over.
- Discovery: inventaris custom + OCA + integraties + ergernissen
- Vaste-scope offerte met drop / vervang / upgrade beslissing per module
- Drie omgevingen: prod-kopie, upgrade-staging, UAT
- Twee UAT-cycli minimum, cut-over end-to-end gerepeteerd
- Hyper-care week 1, scope-creep doorgeschoven naar volgende kwartaal-release
Praktische checklist vóór je je Odoo-upgrade plant
Loop deze lijst af met je IT-lead en Odoo product owner. Meestendeels afgevinkt = klaar om te plannen.
- Custom-module inventaris compleet met beslissingen: upgrade / drop / vervang
- OCA-module beschikbaarheid geverifieerd voor doelversie
- Integratielijst gedocumenteerd met testplannen (EDI, e-commerce, BI, betaling)
- Drie omgevingen voorzien: prod-kopie, upgrade-staging, UAT
- Twee UAT-cycli gepland met key users
- Cut-over weekend afgesproken en gecommuniceerd aan business
- Rollback-plan gedocumenteerd en gerepeteerd
- Hyper-care plan gedefinieerd: wie, wanneer, hoe escaleren
Belangrijkste inzichten
- Elke twee jaar upgraden is gezond — achterop blijven samengesteld het risico
- Custom code en OCA = 60% van upgrade-kost — inventariseer genadeloos
- Drie omgevingen minimum: prod-kopie, upgrade-staging, UAT
- Cut-over end-to-end gerepeteerd op staging — nooit improviseren op het echte weekend
- Scope-discipline telt — laat de upgrade geen redesign worden
- Hyper-care week 1 vangt en fixt 80% van post-upgrade issues
Veelgestelde vragen
Kunnen we versies overslaan, bv. v14 direct naar v17?
Ja, de Odoo-upgrade tool ondersteunt multi-versie sprongen. Het risico groeit niet lineair met het gat — het groeit met de hoeveelheid custom code te porten en de evolutie van het OCA-landschap. We hebben v12 → v17 in één keer gedaan, en v15 → v16 die langer duurde door een zwaar gecustomiseerde manufacturing-module. Plan op je custom voetafdruk, niet enkel op het versie-gat.
Hoeveel kost een Odoo-upgrade?
Voor een kleine KMO op standaard Odoo met één of twee custom velden: enkele duizenden euro. Voor een middelgroot bedrijf met een dozijn custom modules, OCA-afhankelijkheden en integraties: typisch 15-50 k€. Voor een complex multi-entiteit setup met veel custom: zes cijfers is realistisch. De kostendrijver is custom code, niet de upgrade zelf.
Moeten we upgraden en nieuwe features tegelijk doen?
Sterk afgeraden. Upgrades = pariteit — zelfde businessprocessen, nieuwe versie. Nieuwe features zijn een apart project, idealiter na stabilisatie van de upgrade. Mengen maakt scope onbeheersbaar en rollback onmogelijk. Laat het twee maanden stof neerdalen, bouw daarna nieuw.
Wordt Odoo Online (SaaS) automatisch geüpgraded?
Ja — Odoo regelt de upgrade voor SaaS-klanten, typisch eenmaal per jaar. Tradeoff: minder controle over timing en welke custom modules je kunt installeren. Voor Belgische KMO's adviseren we vaak Odoo.sh of self-hosting net omdat die je controle geven over upgrade-schema en customisatie-oppervlak.
Wat als de upgrade datakwaliteits-issues blootlegt?
Dat is eigenlijk één van de voordelen — en verrassingen. Upgrades exposen vaak langlopende data-rariteiten die de vorige versie tolereerde. Wij behandelen dit positief: opruimen tijdens het upgrade-venster en je hebt nadien een gezondere database. De pijn is echt, de uitkomst goed.
Hulp nodig om dit toe te passen op uw eigen context? We praten er graag over.