What an Odoo ERP implementation really involves

Odoo is one of the most capable ERP platforms available, and one of the easiest to underestimate. The software is not the hard part. The implementation is — the fitting, the data, the decisions nobody wants to make, and the weeks after go-live when people either use the system or quietly route around it. This guide walks through what an Odoo ERP implementation actually involves, in the order it happens, so you can plan for the work the demo never shows.

Odoo is a platform you fit, not a product you install

Out of the box, Odoo gives you apps for sales, purchasing, inventory, manufacturing, accounting, projects, HR, e-commerce and more, all sharing one database and one set of partner and product records. That shared database is why companies pick Odoo, and why implementations are harder than they look: a decision made in inventory shows up in the accounts three months later, and a shortcut taken in product data is felt in every module at once.

Switching the apps on takes an afternoon. Fitting them to how your company actually quotes, buys, ships, invoices and closes a month is the project, and two businesses in the same industry rarely run Odoo the same way.

The phases of an Odoo implementation

A realistic implementation moves through the same sequence almost every time. Skipping a phase does not remove the work; it moves it somewhere more expensive.

Discovery and scoping — mapping how the business runs today and deciding what the ERP should adopt, improve, or drop.
Configuration — setting up the standard apps, the chart of accounts, taxes, warehouses, pricelists, users and access rules against that map.
Custom development — building modules only for the parts of the business standard Odoo genuinely does not cover.
Data migration — moving partners, products, stock, open documents and balances, cleaned and reconciled.
Integration — connecting Odoo to the systems you are keeping: webshop, payments, bank, carriers, machines, internal tools.
Testing on real records — the people who will use the system running their own work through it, not a scripted demo.
Training — key users trained on your configuration and your data, then training the rest.
Go-live and the weeks after — cutover, then the corrections that only appear once real volume hits the system.
Maintenance and the annual upgrade — because an ERP is never finished, it is maintained.

Every phase should end with something you can open, look at and sign off. A phase whose only output is a status update is a phase you cannot verify.

Discovery: what to decide before you touch the system

Discovery is not a workshop about features. It is the exercise of writing down how the business actually runs today — not how the org chart describes it, and not how the last system forced it to run. The people who know are the ones doing the work, so that is who you ask. The decisions worth making before anyone configures anything:

Which processes move into Odoo in the first phase, and which stay where they are for now.
How a quote becomes an order, a delivery and an invoice — including who approves what, and at which thresholds.
Your chart of accounts, tax rules and fiscal localisation, and who signs off the month-end close.
How stock is counted and valued: standard or average cost, single or multi-warehouse, lots and serial numbers or neither.
Which reports the business actually runs on, as opposed to the ones that are merely printed.
What data has to move, from which systems, and what can be left behind.
Every system Odoo will exchange data with, and which side owns each record.
One named person on your side who can make a decision without convening a committee.

What comes out of discovery is a module list, a gap list and a phase plan. The gap list is the important one: it separates what standard Odoo already does from what it does not, and splits the gaps three ways — solved by configuration, solved by code, or solved by changing the process. That document is what decides the budget, so it has to exist before anything is built. A supplier who will not produce something like it before quoting a build is quoting a guess.

Configure first, customise second

Every custom line in Odoo is a line somebody has to carry through the next upgrade. That is the entire argument for configuring first. The standard apps, configured properly, already cover most of what a company asks for, and what they cover costs nothing to maintain.

So the order is fixed. Configuration first. Then Odoo Studio for fields, views and small automations. Then a real Python module when the requirement is genuinely yours — a pricing rule nobody else has, a document a regulator demands, a machine or a marketplace the standard connectors have never heard of.

How to tell whether a requirement needs configuration or code

Most arguments on an ERP project are really this question in disguise. A rough test that settles most of them:

Can it be expressed as a setting, a pricelist rule, a stock route, an approval rule, a document layout or a report filter? Configuration. Do it there and it survives every future version.
Is it an extra field, a view change or a simple automated action? Studio will do it — but be aware that Studio customisations live in the database rather than in git, which matters when you want them reviewed, versioned and moved between environments.
Does it need logic that runs on save, a calculation Odoo has no concept of, a document in a format somebody else mandates, or a live connection to another system? That is a Python module, and it should be scoped and estimated like one.
Does the requirement exist only because the old software worked that way? Change the process. This is the cheapest option on the list and the one most often skipped.

The question that resolves the rest: can the requirement be explained without referring to the previous system? If not, it is a habit rather than a requirement. Sometimes the right move is to change how you work, not how the software works, and a good implementer will say so in writing — once, with reasons — and then build what you decide.

Data migration: the part that quietly sinks projects

Migration is where ERP projects fail without anyone announcing it. The system goes live, the numbers do not match, finance keeps a spreadsheet on the side, and within a quarter nobody trusts the ERP. The rule that prevents it is simple: every object moves deliberately, is reconciled against a number your finance team already trusts, and is signed off before it counts.

Most of the pain is avoidable, and the avoiding happens before the import — in your old system, or in a spreadsheet, while there is still time. Clean these first:

Duplicate customers and suppliers. Merge them before the load. Once documents attach to duplicates in Odoo, cleaning them up becomes a project of its own.
Product data: consistent references, units of measure that match how you actually buy and sell, and a decision on variants versus separate products taken before the first import rather than after.
The chart of accounts. Decide whether you carry the old one across or adopt Odoo's fiscal localisation and map to it. Mapping is far easier before the data arrives.
Open items only. Unpaid invoices, live orders, current stock. Closed history is usually better left readable in the old system than half-imported into the new one.
Stock. Count it. An import cannot fix an inventory nobody has physically counted, and every manufacturing figure downstream inherits that error.
The small rot: missing tax codes, dead references, contacts with no email, and addresses stored in one free-text field that now has to become five.

Then load in order — master data first (partners, products, units of measure, bills of materials, pricelists), balances second (open invoices, opening stock by location and lot, opening accounting entries). Every load runs into a staging database, and runs twice, because the second run is what proves the first was repeatable rather than a one-off performed by hand at midnight.

Loaded is not migrated. Before sign-off, stock valuation, receivables, payables and the trial balance are compared against the source system and the difference is explained until it is either zero or understood. That comparison is what makes the numbers trustworthy on the Monday after go-live.

Big bang or module by module

There are two honest ways to go live, and the choice is a business decision more than a technical one.

A big bang puts everything on the same date. It makes sense when the processes are too tightly coupled to split — when manufacturing, stock and accounting cannot sensibly report against two systems at once — and when the business has a genuinely quiet period to do it in. The cost is that everything has to work on one date, and every team learns everything at once.

A phased go-live releases groups of modules instead. Sales, purchasing and inventory can run first while accounting closes the current year in the old system; accounting moves at a fiscal-year or period boundary; manufacturing follows once stock is trusted. The cost is temporary bridges between old and new, and a stretch where finance reconciles across two systems. What you buy is a normal week for each team to learn one thing, instead of an abnormal week learning everything.

Phase it when you can; big bang when the accounting calendar or the coupling between processes forces your hand. Either way, write the cutover runbook, define the rollback point and name the person allowed to call it — before the day, not during it.

Integrations with the systems you keep

An Odoo implementation almost never happens in isolation. Odoo exposes its models over XML-RPC and JSON-RPC, and a custom module can add REST endpoints, webhooks and scheduled jobs, so the question is rarely whether two systems can talk. It is who owns which record, and what happens when one side is down. The connections that come up most often:

E-commerce: Odoo's own website, or Shopify or WooCommerce as the storefront with Odoo holding stock, pricing and invoicing.
Payments and banking: gateways on the sales side, bank statement import and reconciliation on the accounting side.
Shipping: carrier labels, rates, and tracking written back onto the delivery order.
Business tools: CRM, mail, spreadsheets, BI and internal APIs — orchestrated in a workflow tool such as n8n when the flow is a business process rather than a product feature.
Industrial: scales, label printers, barcode terminals, PLCs and machine data, where the plant network constrains the design as much as the software does.
The legacy application that is not going away, and now has to stay in step with Odoo.

What separates an integration that survives from one that needs babysitting:

One system of record per field, written down, so nothing is edited on both sides.
Idempotent writes and stored external ids, so a retry never creates a second sales order.
Queued jobs with retries and a dead-letter path, instead of synchronous calls that freeze a user's screen when the other end is slow.
A log a non-developer can read, and an alert when a flow stops — rather than a silence nobody notices for a week.
A staging environment wired to the third party's sandbox, so the integration is proven before it touches real money.

Integrations are the most commonly underestimated line in an ERP budget, and the reason is consistent: the effort lives in the other system's quirks, its rate limits and its error handling, not in Odoo.

Manufacturing: what an Odoo MRP rollout really involves

Odoo's manufacturing app covers bills of materials, work centres and operations, work orders and subcontracting, sitting on the same inventory engine that runs receipts, deliveries and stock valuation. Quality and Maintenance are separate apps, and Quality is an Enterprise app. For most small and mid-sized manufacturers, what ships is enough. The time goes into describing the shop floor accurately — not into writing code.

Bills of materials that match reality, including variants, kit or phantom BoMs, scrap and by-products. A bill of materials that is nearly right produces stock figures that are permanently wrong.
Routings and work centres with capacities and costs that mean something, because they drive both scheduling and margin.
Replenishment: reordering rules, lead times, make-to-order versus make-to-stock, and multi-step routes for receipt, quality control and put-away.
Traceability: lots and serial numbers chosen deliberately, because that choice decides whether a recall takes an afternoon or a month.
Shop-floor reality: barcode scanning, tablet work orders, and steps operators will actually follow. An operator who has to walk to an office to confirm a step will not confirm it, and your work-in-progress data dies there.
Costing: standard versus average cost, and analytic accounts that show margin per order rather than per year.

Custom work in manufacturing is usually justified for machine and scale integration, a scheduling rule specific to your plant, a customer-mandated label or EDI format, and quality documents a regulator wants in a particular shape. Those are real gaps. A work order screen that merely looks like the old one is not.

Training and handover

People route around an ERP they do not understand, and every workaround becomes data the system does not have. So train key users on your configuration and your data — not on a demo database that looks nothing like their day — and let them train their own teams, because they are the ones who answer the questions that come up in week three. Written procedures per role, in the language the team actually works in, are worth more than a recorded webinar nobody reopens.

The technical handover is the other half: repositories, module documentation, database and backup access, integration credentials, and an open list of what still needs a decision. The measure of a good handover is whether you could run the system, and hire someone else to change it, without the original implementer. If the answer is no and your supplier is comfortable with that, it is a commercial position rather than a technical one.

The annual release, and what custom code costs at upgrade time

Odoo ships a major version every year and supports only a limited window of releases. That makes an Odoo deployment something you maintain rather than something you finish. Plan the first upgrade before go-live, not when support runs out.

Standard configuration and data are handled by Odoo's own upgrade path and usually move without drama.
Custom modules are the real work: deprecated APIs, renamed fields, changed view inheritance and moved models all have to be reviewed and adapted, version by version.
Third-party apps move at their author's pace, which is a reason to treat every installed app as a dependency before you install it.
Integrations get re-tested against the new version, because a renamed field breaks a connector silently.
The whole upgrade is rehearsed on a copy of production and validated by the same key users who signed off the go-live.

This is the honest cost of every customisation, and the reason the gap list matters more than the feature list. A deployment that stayed close to standard treats an upgrade as a review. One carrying years of unreviewed custom code turns it into a re-implementation, which is how companies end up stranded several versions behind, unable to take fixes and quoting a fortune to get current.

Odoo Online, odoo.sh or self-hosted

Where Odoo runs decides what you can build, who carries the operational work, and how an upgrade will feel. Decide it early and on purpose, because moving later is a project of its own.

Odoo Online

Odoo runs the platform and you configure it. Studio customisations are fine; custom Python modules are not, and there is no shell or database access. It is the right answer for a company that will stay inside standard Odoo, and the wrong one the moment the gap list contains code.

odoo.sh

Odoo's own platform for running Odoo with your own code: git-backed, with development and staging branches, a build per push, backups and a supported path through version upgrades. This is where most implementations that involve any development belong, because developers get a real workflow and you do not have to run servers.

Self-hosted

Your own infrastructure, or a cloud provider you choose — which is what data residency requirements usually come down to. It is the right answer when residency, an on-premise integration or an existing platform team requires it. In exchange you own PostgreSQL tuning, backups and restore rehearsals, monitoring, filestore management and the upgrade machinery. That is a real operational job: staff it, or use odoo.sh.

Edition is a separate question from hosting. Community covers a great deal for light, self-hosted use; Enterprise adds modules, the mobile apps and Studio that many companies end up wanting. Either way the licence is a contract between you and Odoo. An implementer who does not resell licences has no commercial interest in which edition you land on — worth knowing, because one who does has one.

How to tell a good implementation partner from a bad one

The platform is the same for everyone. The difference between an Odoo project that lands and one that drags is almost entirely the people running it. Signs you are talking to someone who has done this properly:

They ask about your month-end close before they show you a single screen.
They produce a written gap list and a phase plan before quoting a build.
They tell you which of your requirements they think you should drop.
They say “it depends”, and then say what it depends on.
They show you working software running on your data, not slides.
They are explicit about who owns the code and where it lives — your repository or theirs.
They plan the first version upgrade before go-live.
They put the licence relationship where it belongs: between you and Odoo.

And the warning signs:

A fixed quote for the whole implementation before anyone has looked at your processes or your data.
Everything is “no problem”. Honest engineers say “it depends”; salespeople say “no problem”.
Customisation offered as the answer to every requirement. A build is billable; a setting is not.
Studio-only work presented as custom development, with nothing in version control and no way to move it between environments.
Modules that patch Odoo core, or code that exists only on the production server.
Data migration first mentioned in the week of go-live.
No answer for what happens at the next major release.
Silence about month six: who fixes it, who monitors the backups, who answers the phone.

The cheapest single test: ask what happens to your custom modules when the next Odoo version ships. An honest answer describes review and adaptation work, and roughly what drives it. An evasive answer means somebody pays for it later, and it will not be them.

What actually drives the cost

Nobody can give you an honest number before discovery, and the variables are not mysterious:

How many processes and modules are in scope, and how many departments they touch.
The length of the gap list — that is, how much of the work is code rather than configuration.
The state of your data, which is usually worse than anyone expects and is the easiest thing to improve before you start.
The number of integrations and how awkward the systems on the other side are.
How many people need training, across how many sites and languages.
Hosting and edition, which are a separate contract with Odoo, not part of the implementation.
Maintenance and the annual upgrade — a line that never goes away, and should be in the plan from the first day.

Anyone quoting a full implementation price before seeing your processes and your data is either guessing or planning to recover the difference in change requests. The most useful thing to buy first is a scoping phase with a written deliverable — module list, gap list, phase plan — that belongs to you and that you could hand to a different supplier. A supplier who will not sell that on its own has told you something as well.

None of this is glamorous, and all of it is the difference between an ERP project that is boring and one that becomes a story.

Singleton is a software studio in Tunis. We implement Odoo, build custom Odoo modules and connect Odoo to the systems around it, working in English, French and Arabic and in the same working day as companies in France and the rest of Europe. We are not an Odoo partner and we do not resell Odoo licences — you buy yours from Odoo directly, so we have no commercial interest in which edition or hosting you choose. If you are planning an ERP project and want a written scope before you commit to a build, get in touch.

All resources