Een upgrade is geen technische formaliteit
Een Odoo-upgrade raakt processen, maatwerk, data, integraties, rapporten en gebruikersgewoontes. Zelfs wanneer de database technisch migreert, moet je nog bewijzen dat het bedrijf correct blijft werken.
Daarom hoort een upgrade een testplan te hebben, geen “we klikken eens rond”.
Inventaris vóór je start
- Welke custom modules zijn geïnstalleerd?
- Welke Studio-aanpassingen bestaan er?
- Welke server actions en automatische acties draaien?
- Welke externe koppelingen zijn kritisch?
- Welke rapporten, documenten en portaalflows moeten identiek blijven?
- Welke processen mogen geen dag stilliggen?
Staging en testdatabase
Test nooit rechtstreeks op productie. Gebruik een recente kopie, voer de upgrade uit en test met echte scenario’s: offerte tot factuur, aankoop tot ontvangst, webshoporder tot levering, ticket tot oplossing.
Test ook gebruikersrechten. Veel upgradeproblemen verschijnen pas met een gewone gebruiker.
Maatwerk en Studio
Custom modules moeten gecontroleerd worden op deprecated API’s, gewijzigde views, nieuwe standaardvelden en gewijzigde workflows. Studio-aanpassingen moeten zichtbaar gemaakt worden, want die zitten niet altijd in een klassieke code-review.
Documenteer wat aangepast is en welke flows geraakt worden.
Go/no-go criteria
- Kritische flows getest en goedgekeurd.
- Integraties getest met realistische data.
- Rapporten en documenten gecontroleerd.
- Performance aanvaardbaar.
- Rollback of herstelplan beschikbaar.
- Gebruikers weten wat verandert.
Conclusie
Een goede upgrade is voorspelbaar omdat je vooraf weet wat belangrijk is. Inventaris, staging, testscenario’s en duidelijke go/no-go criteria maken het verschil tussen een spannende gok en een gecontroleerde overgang.