Enterprise and ERP. Odoo
Odoo experts, including on whether you should stay
We're not an Odoo partner and we don't resell it. We've implemented it for clients and advised a company choosing between it and Zoho One. That's a different kind of expertise. It's the more useful kind when the question is whether to keep going.
Odoo is a real ERP, and a good one for a company willing to work the way it works. Trouble starts when it isn't willing, because the usual response is to customize until the software fits. That path carries a cost nobody shows you up front, and it's usually what starts the conversation with us.
Where it fits
Where does Odoo fit?
We sell no Odoo licenses and take no referral fees, so this is not a hit piece. These are the cases where keeping it is the honest advice, and if yours is one of them, we will say so on the call.
You're willing to run close to vanilla. Odoo standard is capable, and a company that adapts its process to the software gets a lot for very little.
Inventory and manufacturing are the core of your operation. The stock and MRP modules are genuinely strong. Rebuilding them is rarely worth it.
You need accounting localization in a country most vendors ignore. Odoo has more of these than almost anyone, and that alone can decide it.
You're replacing five disconnected tools and the integration burden is the real problem. One database beats five APIs, at least until the modules start fighting you.
Where it breaks
Where does Odoo break down?
The failure modes below are the ones that show up again and again as a company grows.
The upgrade tax. Custom modules don't carry across major versions on their own. Every version you skip makes the next jump harder. Customize heavily enough and the choice narrows to paying for the migration at every major release or staying on a version that stops getting security fixes.
The Studio ceiling. Studio covers fields, views and simple automation. The moment a requirement needs real logic you're writing a module, and you've quietly become a software company maintaining a fork.
The all-in-one coupling. Accounting, inventory and sales share one data model, which is the selling point right up until you want to replace one of them. You can't swap out a module you dislike without touching the ones next to it.
Record rules. Access comes down to domain expressions in ir.rule, and multi-company setups are where the subtle leaks live. A rule that reads correctly can still expose the wrong records once a second company or a shared contact record enters the picture.
Reporting past the pivot view. The built-in reporting handles standard questions fine. Anything shaped like your business specifically means SQL views, a custom report module, or pulling the data out and doing the work somewhere else.
Partner dependency. The customizations are code, so the firm that wrote them is usually the only one who can safely change them. That's a commercial position, and you feel it most at renewal and at upgrade.
The replacement
What does replacing Odoo look like?
Often you shouldn't replace it, and we'll say so. If the parts of Odoo you use sit close to standard, the honest project is stripping the customizations back out and keeping the platform.
When replacing is right, it's almost never all of it at once. Take the part of the business Odoo fits worst, usually the operational core that attracted the most custom code, and build that as its own system on your own database while Odoo keeps doing the accounting. That's the pattern that works.
Your data already sits in PostgreSQL, which makes this materially easier than leaving a closed vendor. The external API gives full read access to every model, so the migration becomes a defined engineering problem. Nobody has to negotiate over export formats.
What you end up owning is a system with your objects in it, named the way your team names them, with rules that match how you actually work. No per user per app line at renewal, no module list, and no version whose end of support sets your roadmap for you.
The stakes
What does it cost to get this wrong?
More than the software. A replacement that goes badly costs you the one thing the old system was still doing, a single place your team agrees on. The failures below each turn a rebuild into a year of parallel systems, so they are the ones we plan around.
The usual disaster is quiet. A company two years into customization can't upgrade, can't justify what migrating the custom modules would cost, and keeps running a version that no longer receives fixes.
The second is reconciliation. Move the ledger before anyone has proved the new numbers match the old ones over the same period, and you get a month where nobody can say with confidence what the business earned. You can't work your way out of that one.
The third gets underestimated. You lose the person who understood the customizations, and undocumented Python inside a module is knowledge held by whoever wrote it. When they leave, the system turns into something nobody will touch.
The order of work
What happens, in what order, when you leave Odoo?
Each step exists because skipping it is how the previous attempt failed. The sequence is fixed. The runway is not, and it goes in your written scope once we know the shape of your data rather than on this page as a calendar promise.
- 01
Read what's actually custom
Before any decision, we list every custom module, every Studio change and every automated action, and mark which ones are load bearing. The list surprises most companies. A good share of it turns out to be built for a process that changed years ago.
- 02
Decide module by module
Inventory and accounting frequently stay. The sales, project or service side is usually where the custom code piled up, and that's what gets rebuilt. Going module by module keeps this from turning into a rip and replace nobody signed up for.
- 03
Pull the data through the API
Odoo exposes every model over its external API, so extraction gets scripted and repeatable. Repeatable matters more than fast. You'll run it many times before cutover, and a hand made export is only correct on the day it was made.
- 04
Run both and reconcile before anything is switched off
The new system runs alongside Odoo on real data, and the same questions get asked of both until the answers agree. We switch Odoo off when the numbers match, never because a build finished.
- 05
Accounts in your name from day one
The database, the repository, the hosting and the keys go into your name on day one. There's no handover at the end, because by then there's nothing left to hand over. You own it if you can remove us without asking anyone.
Limits
What we will not do
Saying this out loud is cheaper for both of us than finding out in month two. If one of these is what you actually want, we are the wrong firm and we will say so on the first call.
- We won't tell you to leave Odoo when the real problem is a configuration decision made three years ago. That's a smaller project and we'd rather do it.
- We won't move your ledger before the numbers have been proved against the same period in Odoo.
- We won't hold your customizations hostage. The code sits in your repository, documented, and any competent developer can pick it up.
Questions
What people ask about leaving Odoo
Are you an Odoo partner?
No, and we'd rather be useful than affiliated. There's no reseller margin, no referral fee and no quota on any platform, so telling you to stay on Odoo costs us nothing. We've implemented Odoo for clients, and that's where the expertise comes from. It just isn't a commercial relationship with the vendor.
Is Odoo actually a good ERP?
Yes, for the right company. It covers more ground than almost anything else at its price, the inventory and manufacturing modules are strong, and the accounting localizations are unusually broad. The real question is whether your business is willing to work the way Odoo works. That's what decides how much custom code you end up owning.
We've heavily customized Odoo and can't upgrade. What are the options?
Three, and they're all real. Pay to migrate the customizations to the current version, which works and then recurs at every major release. Strip the customizations out and get back to something close to standard, which is often possible once someone lists what they were actually for. Or move the customized part out into a system you own and leave Odoo doing the standard work it does well. Which one is right depends entirely on that list, so we build the list first.
What's the difference between Community and Enterprise, and does it matter here?
Enterprise adds Studio, the mobile apps, several accounting features and official support, and it's priced per user per app. Community is free and open source. It matters. A lot of customization exists either to reproduce an Enterprise feature in Community or to work around a Studio limit in Enterprise, and knowing which side of that line a customization came from usually explains why it exists at all.
Can our data actually get out?
Yes, and it's the best thing about your position. Odoo runs on PostgreSQL and exposes every model over an external API, so extraction is ordinary engineering work with nothing to argue about. On Odoo Online you get less direct database access, but the API is still there and it's enough. Next to a closed SaaS ERP, you're in a strong spot.
Do we have to leave all of Odoo?
Almost never, and we'd push back on a plan that said so. Usually accounting and inventory stay where they are, and the operational side, the part that attracted the custom modules, becomes its own system. One database at the center matters less than most people are told. What matters is that the parts talk to each other reliably and nobody is retyping anything.
How is what you build different from another set of Odoo customizations?
Ownership and coupling. Custom Odoo modules live inside somebody else's release cycle, so every major version brings a bill and a risk. A system built as its own thing has no version whose end of support sets your roadmap and no module list at renewal. The database, the code and the hosting are in your name from the start. That's a different relationship than a partner holding the only copy of the code.
What if we start this and decide Odoo was fine?
Then you stop, and you've lost very little. The first piece of work is reading what's custom and why, and that list is worth having whatever you decide. You can take it back to your existing Odoo partner and use it to strip customizations out with nothing rebuilt. We'd count that as the project working.
Related
Coming from a different tool?
The same honest treatment for the other platforms we used to implement, and the pages that explain the custom model itself.
Tell us where Odoo stopped fitting
Book a strategy call, or send a short note about the workarounds your team runs today. If keeping Odoo is the right answer, you will hear that first.