Odoo is not a small SAP

We are an Odoo Certified Partner, so take the following in that light. It is also the reason we would rather say plainly where it is the wrong answer, because the implementations that go badly are almost always the ones where the fit was decided before it was examined.

What it is genuinely good at

Breadth for the money. Sales, purchasing, inventory, manufacturing, projects, field service and accounting in one data model, at a licence cost that a business of forty people can absorb. The alternative is usually four products and the integrations between them, which costs more and agrees with itself less.

One place where things reconcile. The single biggest win is not any individual module. It is that the stock figure, the sales order and the invoice are looking at the same records, which removes an entire category of argument.

Extensibility that is real. It is designed to be developed against. Where the standard configuration does not reach, a custom module is a legitimate answer rather than a hack, and the extension points are documented.

Incremental adoption. You do not have to take everything on day one. Starting with inventory and sales, then adding manufacturing next year, is a normal and sensible path.

Where it is the wrong tool

When a specialist system already does the core of your business well. A packhouse with grading software tuned to its lines, or a business running a mature industry-specific product, should usually keep it and integrate. Replacing a specialist with a generalist to have everything in one place is how businesses lose capability they were not aware they depended on.

Heavy statutory or industry-specific compliance. If your sector has reporting requirements with prescribed formats, check them specifically rather than assuming configurability covers it.

When the process is genuinely unusual and nobody will change it. Odoo has opinions. Bending it a long way from those opinions is possible and it accumulates customisation, which is where upgrade pain comes from. If the answer to every workshop question is “we do it differently”, the cost is in the customisation rather than the licence, and that should be understood up front.

When nobody internally can own it. This is the most common reason implementations disappoint, and it has nothing to do with the software.

The decisions that actually determine the outcome

How much customisation, and how it is done. Configuration survives upgrades. Custom modules written against documented interfaces survive them with effort. Direct database modification does not survive at all, and we will not do it. Every deviation from standard should be a decision someone made knowingly, with the maintenance cost stated.

Data migration, which is always worse than estimated. Your existing product, customer and stock data has years of accumulated inconsistency in it. Cleaning it is a project of its own and it is better done before migration than after, when it is inside the new system and harder to see.

Hosting. Odoo Online, Odoo.sh and self-managed each make different tradeoffs on control, customisation freedom and who is responsible when something breaks. This choice constrains what you can do later, so it should not be made on price alone.

Who signs off the process design. Not IT. The people who run the process. A workshop where the warehouse manager is absent produces a warehouse module the warehouse manager will work around.

How we would rather start

With discovery priced on its own, before any commitment to implement.

That means mapping the processes, examining the fit honestly, and being willing to report that the answer is to extend or integrate what you have rather than replace it. That outcome is a legitimate result of the assessment, not a failure of it, and pricing the assessment separately is what makes it possible for us to say so.

If someone is quoting an Odoo implementation before they have seen how your business actually runs, the number is a guess.