Skip to main content
Knowledge Center

Specialised articles on Odoo systems

We write about implementation rather than definition: what works, what fails, and what is outside our scope. The answers below are direct because they are what gets asked before any project.

Questions asked before any Odoo project

Direct answers with no generic definitions — each verifiable from our scope of work or from the system’s own documentation.

What is Odoo, and who is it for?

Odoo is a suite of business applications on one database: sales, purchasing, inventory, manufacturing, accounting, HR and point of sale, with each module extensible through business rules. It fits an organisation that needs its functions connected in one system instead of separate files, and it can start small (one or two modules) then expand. An organisation needing extreme depth in a single function may be better served by a dedicated product — and we say so at assessment stage.

Do we start with every module or just one?

One or two. The value comes from connection rather than count: disciplined stock connected to sales beats six half-operated modules. The usual order is: clean the master data, then the module that stops the largest loss, then connect it to accounting, then expand. An abandoned project with many modules is worse than a small successful one.

How is an Odoo implementation costed?

By scope rather than guesswork: the number of companies, branches and warehouses; items and users; modules and workflows; the volume of data to migrate; and the integration scope. We give no binding price before the needs analysis and the written scope with acceptance criteria, because a figure before that changes later and destroys trust. Changes after the scope is approved are estimated as written change requests.

How is data migrated from our current system?

In order: inventory what genuinely must move (not everything), clean it (merge duplicates, correct units and categories), then a trial migration into a test environment with balances reconciled against the old system, then the final migration after approval. Opening balances are reconciled with accounting and stock, and differences are documented with their causes rather than patched in a file. Detailed historical data usually stays in the old system for reference instead of being migrated wholesale.

Module and topic guides

Each topic has a detailed page with scope, deliverables and metrics — the reference our articles are written from.