Let's start with the disclosure, because it changes how you should read everything else: Durpro is owned by Marc and Denis Durepos, and Pascale Lohéac is its CFO. So this isn't a client testimonial. It's the story of the company Bemade was founded for — and that is exactly why it's worth telling.
Durpro is a Quebec SME of about twenty people running four businesses under one roof: distribution, field service, custom-engineered systems and resin regeneration. Four different ways of making money, in a single system. It has run on Odoo since January 2013, back when the software was still called OpenERP.
In thirteen years, we've tried just about every way there is to run an ERP. Here's what each one taught us.
We set it up ourselves (OpenERP 6.1)
Denis set the system up on his own: development and testing on version 5.0, then a switch to 6.1 for the launch on January 1, 2013. The data was imported by hand-editing SQL files and assigning record IDs one by one. And he did it in his spare time, because the rest of the week he was designing systems and servicing Durpro's customers.
No automated tests, of course. To find out whether something worked, we used it, and waited to see what broke.
The lesson from that period: a motivated SME can get started on its own. What it can't do on its own is keep up.
Two partners, two limits (versions 7 and 11)
For version 7, we moved to Odoo Enterprise. The migration was done for us, with a large integrator handling project management. It was supposed to fix three problems. It fixed none.
Every bug we reported came back labelled a “configuration issue”, with no help resolving it, while the project-management fees kept running. The model didn't help: we paid by the hour, including, it seemed, the hours spent getting the integrator's own deployment tools to work. And when we wrote a fix ourselves, it had to go through them: billed, for little or no added value. The tally: US$15,000 to $20,000 later, we were no further ahead. We had new bugs, and features we relied on had disappeared.
We then jumped straight from 7 to 11, on the Community edition, with a partner whose Odoo team was smaller. This time the problem was availability: they couldn't free up an experienced developer for our project. Less experienced developers shipped code built to the wrong requirements, or that didn't do what it claimed to. Customizations crawled along.
And from one partner to the next, the modules delivered came with neither automated tests nor requirements documentation. Every migration turned into archaeology: first figure out what a module was for, then decide whether it was still needed, then hunt for what broke in the new version. Predictably, upgrades became projects we kept putting off.
2022: we become our own partner
In 2022, we had to get off version 11. Rather than look for a third partner, we brought the expertise in-house and founded Bemade to do the migration to Odoo 15 Enterprise. Most of the work happened in the summer of 2022; Durpro went live in January 2023, after testing.
The choice of Enterprise came down to substance: Enterprise's accounting, helpdesk and field service covered what Durpro needed, and were worth more than the licence. It wasn't about commissions — we don't live off them, and we recommend the Community edition when that's what fits.
What changed: upgrading became routine
Since 2022, Durpro has kept close to Odoo's releases:
| Version | Live in production |
|---|---|
| Odoo 15 Enterprise | January 2023 |
| Odoo 17 (we skipped 16) | Fall 2024 |
| Odoo 18 | Fall 2025 |
| Odoo 19 | September 2026 |
Four upgrades in four years, on a heavily customized system, after the previous decade had taught us to put them off. That's not luck; it's how the code is written:
Custom modules are written to be migrated. They have automated tests, and when their data needs to change shape, a migration script that does it cleanly. Today, 56 of Durpro's 62 in-house modules have tests, covering 89% of their lines of code (not counting the test code itself). More than 1,300 tests run on every change, before anything reaches production. On Odoo 11, there were none.
Shareable code is shared. Durpro runs on 48 generic modules that we publish as open source (LGPL licence), on top of its 78 in-house modules. The generic modules are maintained for several clients at once, so they keep up with new versions.
- We rehearse before cutting over. Every migration runs first on a copy of the production database, several times, until the cutover is a non-event.
Not always a non-event, mind you. During the cutover to 19, four scheduled tasks that had been created by hand in the interface stayed switched off, and nobody noticed until a user asked, weeks later, why expired quotes were no longer being cancelled. Nothing was lost, and the lesson won't stay a note on a checklist: it is becoming an automated check. Our migrations already rely on post-migration verification scripts that go beyond Odoo's own, and our other migration projects use them extensively. What one cutover teaches us, the next one checks on its own.
What Durpro does today, in a single system
- Resin regeneration, traced end to end. Tank manufacturing (deionization and carbon), shipping, customer tank returns, emptying, regeneration of spent resin, refilling — with lot and serial numbers wherever they're needed, and quality control built into the process.
- Complex service calls, documented. Planning, coordinating and documenting a service call that spans several systems across several sites, with the history of every piece of equipment at the customer's site and the profitability of every call.
- A single point of entry for every request. The helpdesk triages incoming requests and emails of every kind. A ticket can be linked to, or converted into, a quotation, a lead, a sales order, an invoice or a vendor bill, with no re-keying.
- The metrics leadership chose. Durpro is run on EOS (the Entrepreneurial Operating System); the dashboards for its key metrics are built by Pascale, directly in Odoo.
- Costs that include everything. Import costs built into product cost, vendor price tracking, blanket orders with their discounts, credit limits enforced on customers.
Durpro goes further: its team is developing its own hardware to remotely automate brine curves at customer sites, connected to Durpro's IoT module in Odoo — which will make every service visit more efficient.
That's what a single, structured system makes possible: you can connect sensors, automation and now AI to it. You can't connect any of that to a spreadsheet.
“Our EOS metrics live in Odoo, without anyone having to rebuild them in Excel. My time no longer goes into compiling the numbers: it goes into explaining them, and deciding with leadership. And because the books are kept in real time, I no longer have to wait for month-end to know where we're headed.”
— Pascale Lohéac, CFO, Durpro (translated from the French original)
The code belongs to Durpro, and Durpro works in it
This is the point we want to underline, because it holds for all our clients: Durpro owns its code. The generic modules are public, Durpro's own modules are in its own repository, and everything runs on a standard version of Odoo. But Durpro doesn't just own that repository; it uses it:
- Its COO manages the request pipeline himself. Requests are clarified with the help of AI, then he approves the requirements and the tasks that come out of them. Once the work is done and tested, he's also the one who decides when it goes to production, and the deployment happens on its own.
- Anyone with access to the repository can submit code, through a standard merge request. None gets through without passing the test suite in the continuous integration pipeline, which protects the system, as far as possible, from regressions introduced by custom code — ours included.
Back on version 7, every one of our fixes had to go through the integrator, and we were billed for it. Today, Durpro submits its own changes, and it's the tests, not an invoice, that decide whether they get through.
If Durpro wanted to switch partners tomorrow, it could. It depends on Bemade by choice, not by lock-in. That's exactly what we were missing with our previous partners, and it's what we now offer everyone else.
What this means for you
You don't need to found a company to get what Durpro got. But thirteen years of trial and error taught us what to demand from an ERP partner, whoever they are:
- That they understand your business, not just the software. If they don't ask about your margins, they won't be able to help you see them.
- That every customization is documented and tested — what it's supposed to do, and proof that it does — so that it survives the next version.
- That the code belongs to you, and that you can leave.
- That upgrading is routine, not a project you keep putting off.
If your current system doesn't tick these boxes — whether you're on Odoo or something else — let's talk. The first conversation takes thirty minutes, and you'll come away with, at the very least, a clear idea of what your current situation is costing you.