DEV Community: Mohit

Where Standard Odoo Ends: When Construction Companies Should Consider Customization

Mohit — Wed, 12 Aug 2026 07:34:52 +0000

"Can we just configure that?"

It gets asked in every scoping session, usually hopefully, and it usually gets answered with a feeling. It deserves better, because the question has a technically checkable answer.

Standard Odoo covers more construction requirements than most people assume. It also stops covering them at identifiable points, and those points are properties of the data model rather than judgements about difficulty. Below are five signals that a requirement has crossed the line — each one a structural fact you can check before anyone estimates anything.

Signal 1: you need the history of a value, not its current state

This is the one that catches most construction projects, and percent complete is where it shows up.

A field like this looks reasonable:

class ConstructionContract(models.Model):
    _name = "construction.contract"

    percent_complete = fields.Float(compute="_compute_percent_complete")

    @api.depends("line_ids.completed_qty", "line_ids.contract_qty")
    def _compute_percent_complete(self):
        for contract in self:
            total = sum(contract.line_ids.mapped("contract_qty"))
            done = sum(contract.line_ids.mapped("completed_qty"))
            contract.percent_complete = (done / total * 100) if total else 0.0

Two problems, and they are both structural rather than stylistic.

First, computed fields are not stored by default — they are calculated and returned when requested. Search and grouping are unavailable on them unless you write a custom search method. So the moment someone asks to group jobs by completion band, this field cannot do it.

Adding store=True fixes searching and grouping. It does not fix the second problem, which is worse: a stored field holds one value, the current one. Construction needs to know what percent complete was at the end of each billing period, because that is what was invoiced against and what the next invoice is measured from. Overwrite it monthly and the history is gone.

The tell is easy to check. If a stakeholder ever says "as at" — as at last month, as at the previous application, as at year end — a scalar field is the wrong shape regardless of how it is computed. You need a record per period:

class ConstructionProgressLine(models.Model):
    _name = "construction.progress.line"
    _order = "period_end desc"

    contract_id = fields.Many2one("construction.contract", required=True, ondelete="cascade")
    period_end = fields.Date(required=True, index=True)
    percent_complete = fields.Float(required=True)
    recorded_by = fields.Many2one("res.users", default=lambda self: self.env.user)

That is a new model. It is not configuration, and no amount of Studio gets you there — because the requirement is temporal, and the standard model has no time dimension on that value.

One related gotcha while you are in this territory: computed fields run with compute_sudo=True by default, meaning the computation executes with superuser privileges regardless of who is asking. If your computed value aggregates records the requesting user is not supposed to see, that is worth thinking about before it ships.

Signal 2: the fact belongs to the relationship, not to either record

A subcontractor works on several of your jobs. A job uses several subcontractors. The obvious modelling instinct is a many-to-many, and Odoo will happily give you one.

Then the requirements arrive. What is this sub's scope on this job? What is the awarded value on this job? What retention percentage applies here, which is different from the one on the job across town? When does their compliance for this specific site expire?

None of those belong to the subcontractor. None belong to the job. They belong to the pairing — and a many-to-many produces a bare join table with two foreign key columns and nowhere to put them.

The moment a relationship needs attributes, you need an explicit model for the relationship itself:

class ConstructionSubcontract(models.Model):
    _name = "construction.subcontract"
    _description = "Subcontractor engagement on a specific job"

    job_id = fields.Many2one("construction.contract", required=True, ondelete="cascade")
    partner_id = fields.Many2one("res.partner", string="Subcontractor", required=True)
    scope = fields.Text()
    awarded_value = fields.Monetary()
    retention_percent = fields.Float()
    compliance_expiry = fields.Date()
    currency_id = fields.Many2one("res.currency", required=True)

This one is worth catching early because retrofitting it is genuinely painful. Data already entered against a many-to-many has no attributes to migrate, so somebody reconstructs them from contracts and email, by hand, for every live job.

The general test: if you catch yourself wanting to write a field name like retention_percent_for_this_job_only, the relationship needs to be a record.

If you want the functional context behind these requirements rather than the modelling argument, there is a non-technical overview of Odoo for contractors that covers the workflow side.

Signal 3: you need different state semantics than the ones shipped

Odoo's Project app looks like an obvious home for construction work, and for task management it often is. The boundary here is specific and easy to miss.

Task stages are configurable — they are project-specific and can be shared across projects that follow the same workflow. Task statuses are not. Odoo ships five fixed statuses — In Progress, Changes Requested, Approved, Canceled and Done — and they cannot be customised. There is also behaviour attached: Changes Requested and Approved clear automatically when a task moves to another Kanban stage, reverting to In Progress, while Done and Canceled persist.

That is fine for tasks. It is not a contractual state machine, and construction has several of those — a subcontract that moves through awarded, mobilised, in progress, complete and closed out, with rules about which transitions are legal and what each one triggers.

Trying to bend task status into that shape is the classic mistake. The status field will keep resetting itself underneath you because it was designed to, and you will end up writing overrides that fight the framework at every stage change.

Model your own state field on your own model instead, with explicit transitions:

class ConstructionSubcontract(models.Model):
    _inherit = "construction.subcontract"

    state = fields.Selection(
        [("draft", "Draft"), ("awarded", "Awarded"), ("mobilised", "Mobilised"),
         ("in_progress", "In Progress"), ("complete", "Complete"), ("closed", "Closed Out")],
        default="draft", required=True, tracking=True,
    )

    def action_award(self):
        for rec in self:
            if rec.state != "draft":
                raise UserError(_("Only draft subcontracts can be awarded."))
            if not rec.compliance_expiry or rec.compliance_expiry < fields.Date.today():
                raise UserError(_("Cannot award: subcontractor compliance is missing or expired."))
            rec.state = "awarded"

Leave the shipped task status alone and let it do the job it was built for.

Signal 4: the rule has to hold at the database, not in the form

Odoo gives you two places to enforce a rule, and the choice matters more in construction than in most domains because the data outlives the people who entered it.

@api.constrains runs Python validation after fields are written. It is flexible, it can look at related records, and it produces good error messages. It is also bypassable — direct SQL, a bad migration script, or a code path that writes with the constraint deferred will all go straight past it.

_sql_constraints pushes the rule into PostgreSQL, where nothing gets past it:

class ConstructionContract(models.Model):
    _inherit = "construction.contract"

    _sql_constraints = [
        ("job_number_uniq", "unique(company_id, job_number)",
         "Job number must be unique within the company."),
        ("retention_range", "CHECK(retention_percent >= 0 AND retention_percent <= 100)",
         "Retention percentage must be between 0 and 100."),
    ]

Use the database for anything that would corrupt your reporting if it were ever violated — uniqueness of job numbers, non-negative quantities, percentages within range. Use Python for rules that need context, like the compliance check in the example above.

If a requirement can only be expressed as a database constraint, that is a customization by definition. There is no configuration screen for a CHECK constraint.

Signal 5: the number has to be reconstructable, not just current

This is signal 1 generalised, and it is the one most worth internalising because it catches requirements before they are written down.

Ask of any number the business cares about: can we reproduce what this was on an arbitrary past date? If the answer is no and someone will eventually need it, the model is missing a dimension.

Cost committed as at each month end. Contract value before and after each variation. Which subcontractors were compliant on the day of an incident. Every one of those is a question the business will ask exactly once, at the worst possible moment, and a current-state model cannot answer any of them.

Odoo gives you some of this free. Fields with tracking=True write to the chatter, which is an audit trail and is fine for "who changed this". It is not a reporting structure — you cannot group or aggregate across it usefully. If the historical value needs to appear in a report, it needs to be a record, not a message.

Where standard genuinely holds

Worth saying plainly, because the signals above are easy to over-apply.

Multi-dimensional cost analysis, document management, purchasing workflows, approval routing, resource scheduling and most reporting are configuration problems in Odoo, not code problems. Reaching for a custom model when a configuration option exists is a decision to maintain something forever that Odoo would have maintained for you.

Two framework limits worth knowing before you assume something is impossible, though. Related fields cannot chain through Many2many or One2many in their dependency paths — that limitation catches people who try to reach across two hops and conclude the framework cannot do it, when a stored computed field with an explicit @api.depends usually can. And a non-stored computed field that "cannot be searched" often just needs store=True plus a correct depends list rather than a new model.

Check both before escalating.

The test to run before anyone opens an editor

For each requirement, answer four questions.

Does it need a value as at a past date? Does it need attributes on a relationship rather than on a record? Does it need a state machine other than the one shipped? Does it need a rule enforced below the application layer?

Any yes means you have left standard behind, and that is fine — it just means the item belongs in a build scope with an owner and a maintenance plan rather than in a configuration checklist. Scoping Odoo ERP customization honestly at this stage is considerably cheaper than discovering the boundary halfway through a rollout, when the data is already in and the retrofit is a migration.

All four answers no, and someone should go and find the configuration option, because it is probably there.

How Consultants Map Existing Workflows to Odoo (Down to the Model Names)

Mohit — Fri, 07 Aug 2026 10:40:02 +0000

Most workflow mapping produces a diagram. Diagrams are the wrong deliverable.

What an implementation actually needs is a crosswalk: every step of your current process, sitting next to the Odoo model and field that will carry it, with the steps that have no home flagged and classified. That artefact is testable. A swimlane diagram is not — you cannot run a query against it to find out whether it is true.

Here is the method, including the checks that catch a bad mapping before it reaches a statement of work.

Step 1: capture the process as events, not boxes

Do not start with a workshop asking people to describe their process. You will get the official version.

Start by picking one real document and tracing it backwards. "Show me the last order you shipped" — then follow it: who typed it, what they typed it into, what triggered the next person, what they printed, where the paper went, what got re-keyed. For each step, record five things:

the trigger (a time, an email, a phone call, someone walking over)
the actor (a role, not a name)
the system of record at that moment
the decision being made, if any
the artefact produced (a document, a status change, a note in a spreadsheet) You want three to five traces per document type, ideally including one that went wrong. The exception traces are where the real requirements live. A process map built only from happy paths maps a business that doesn't exist.

Skip BPMN at this stage. Formal notation is excellent for communicating an agreed process and useless for discovering a disputed one, and every hour spent on notation is an hour not spent finding the fourth exception nobody mentioned.

Step 2: name the Odoo object for every step

This is the actual mapping work, and it is unglamorous. Each captured step gets a row.

Current process step	Odoo model	Fields that carry the meaning	What usually goes wrong
Customer and their delivery sites	`res.partner`	`parent_id`, `type` (`delivery` / `invoice`)	Sites modelled as separate customers, which breaks consolidated credit and statements
Quotation	`sale.order`, `state` `draft` → `sent`	`state`, `validity_date`, `pricelist_id`	Two legacy statuses both land on `sent`
Confirmed order	`sale.order`, `state` = `sale`	`date_order`, `commitment_date`	"Confirmed" and "released to warehouse" are one state here, not two
Pick, pack, dispatch	`stock.picking` + `stock.move` / `stock.move.line`	`picking_type_id`, `state`, `lot_id`	Assumed to need code; multi-step routes are configuration
Stock available to promise	`stock.quant`	`quantity`, `reserved_quantity`, `location_id`	Legacy "available" rarely equals `quantity` − `reserved_quantity`
Invoice	`account.move`, `move_type` = `out_invoice`	`invoice_date`, `invoice_payment_term_id`	Proforma has no native state and gets faked badly
Volume or contract pricing	`product.pricelist.item`	`min_quantity`, `compute_price`, `date_start` / `date_end`	Quoted as custom development when it is a pricelist rule
Works order	`mrp.production`	`bom_id`, `state`, `qty_produced`	Byproducts and scrap left unmapped until go-live

Three rules make this table do real work:

If two current statuses map to the same model and state, you have lost a distinction. Decide now whether it comes back as a field, a saved filter, or not at all. Discovering it during user acceptance testing is how you end up with a custom field called x_status_2.

If one current step maps to two Odoo models, your step was hiding a handoff. That handoff is almost always where the process actually fails today. Split the row.

If a step maps to nothing, it goes to Step 3. Do not force it.

Step 3: classify every gap into one of four buckets

The value of the mapping is not the rows that match. It is the disciplined sorting of the rows that don't.

Bucket 1 — configuration. Exists in standard Odoo, needs setting up: multi-step routes, operation types, warehouses, pricelist items, payment terms, fiscal positions, units of measure. No code, no Studio, no cost beyond consulting time. Most first-draft gap lists are 60–70% this bucket once someone experienced reads them.

Bucket 2 — no-code automation. Odoo's automation rules cover a surprising amount: trigger on create or write or a time condition, then update a field, send a message, or run a small server action. Combined with Studio computed fields, this handles most "we need the system to notice X and do Y" requirements. Note the licensing constraint — Studio sits on the Custom plan, not Standard, so a business budgeted at Standard has no bucket 2 at all.

Bucket 3 — code. A custom module: _inherit = 'sale.order', new fields under a consistent prefix, an overridden method, tests. This is the bucket that scales your invoice and your upgrade risk, because every item in it must be re-tested on every version bump.

Bucket 4 — not in Odoo. Belongs in another system, or is a habit that dies with the migration. Write down which, and who agreed.

The discipline that matters: nothing is allowed into bucket 3 until someone has genuinely attempted it in buckets 1 and 2 and failed. In mappings we have reviewed, the single most common error is a requirement written as custom development because the person capturing it did not know that standard functionality already covered it — a pricelist rule quoted as a module, a multi-step delivery route quoted as a workflow engine.

Whether the build then runs in-house or through an Odoo implementation company, insist the bucket-3 list is signed before anyone quotes a fixed price. The count of items in that bucket, not the number of apps you are switching on, is what determines the number on the invoice.

Step 4: prove the mapping against real data

A mapping that has not been tested against your own records is a hypothesis. Two cheap checks turn it into a finding.

Load a real slice with stable identifiers. Import a few thousand real records using an id column carrying your legacy key as an External ID. Re-running the import then updates rather than duplicating, which means you can iterate the mapping instead of rebuilding the database each time you learn something.

Run the crosswalk check. Put the legacy status on the record as a temporary field, then count the pairs. In SQL, against a copy:

SELECT x_legacy_status, state, count(*)
FROM sale_order
WHERE x_legacy_status IS NOT NULL
GROUP BY 1, 2
ORDER BY 1, 3 DESC;

Or through the ORM, which works without database access. Odoo 19 documents an external RPC API alongside a separate JSON-2 API; the long-standing XML-RPC path still reads cleanly:

import xmlrpc.client

common = xmlrpc.client.ServerProxy(f"{url}/xmlrpc/2/common")
uid = common.authenticate(db, username, api_key, {})
models = xmlrpc.client.ServerProxy(f"{url}/xmlrpc/2/object")

pairs = models.execute_kw(
    db, uid, api_key,
    'sale.order', 'read_group',
    [[('x_legacy_status', '!=', False)]],
    {'fields': ['id'], 'groupby': ['x_legacy_status', 'state'], 'lazy': False},
)

Read the output for two failure signatures. A legacy status spread across several Odoo states means your mapping rule is ambiguous. Two legacy statuses sharing one Odoo state means a distinction is about to disappear silently. Both are decisions somebody has to make; the query only tells you they exist. External API access also sits on the Custom plan, which is worth knowing before you promise this check.

What the finished mapping document contains

Not a diagram. Six things: the crosswalk table, the four bucket lists with an owner against each item, the traces you captured including the exceptions, the list of legacy statuses being deliberately dropped, the crosswalk query output, and a named business person's sign-off per document type.

Where this method falls down

It goes stale. A mapping is accurate on the day it is signed and drifts from then on, so if the project stalls for a quarter the exception traces need re-running rather than trusting.

It also invites over-investment. There is a genuine failure mode where three weeks disappear into beautifully complete documentation that nobody opens during the build, and the honest answer is that for a small single-company deployment, one afternoon of tracing per document type is enough.

And mapping is descriptive, not evaluative. It tells you where each current step lands in Odoo. It cannot tell you that a step should be deleted rather than migrated — that judgement comes from the people doing the work, which is the argument for having them in the room rather than sending them a diagram to approve.

Start with one document

Pick your highest-volume document type. Trace three real instances end to end, one of which went wrong. Write the crosswalk rows. Then sort the gaps into the four buckets and count bucket 3.

That number is your project. Everything else is scheduling.

The Odoo Requirements Checklist That Decides How Much Custom Code You Write

Mohit — Fri, 31 Jul 2026 07:43:04 +0000

Requirements gathering on ERP projects gets treated as a business-analyst chore that happens before the interesting work starts. It isn't. It's the phase that determines how many custom modules you end up maintaining for the next six years, and most of the questions that matter are questions only someone who has read the Odoo source would think to ask.

This is the checklist I'd want filled in before I opened an editor. It is deliberately not a list of departments to interview.

1. Map the client's nouns to models before anything else

Every business has five or six words that appear in every sentence they say. "Job." "Load." "Batch." "Run." "Consignment." Write those down on day one and put an Odoo model next to each.

There are three outcomes, and you need to know which one you're in before anyone estimates:

Outcome	What it looks like	Implementation	Realistic cost
Maps cleanly	Their "consignment" is a `stock.picking` with a different label on it	Configuration and terminology only	Hours
Maps with extra fields	Their "job" is a `project.task` plus four fields and an extra state	`_inherit` plus a view extension	An afternoon to a few days
Doesn't map	Their "run" is a scheduling entity with its own lifecycle, approvals and reporting	New model, views, security rules, reports	Scope it as its own work package

The failure mode is silent: a business analyst hears "job", nods, and writes "the system will track jobs." Six weeks later someone discovers that a job spans three sales orders, two warehouses, and can be reopened after invoicing. Ask what the noun is, structurally, and ask what it can be linked to. Cardinality is a requirement, not an implementation detail.

2. Get the numbers, not the adjectives

"High volume" means nothing. Ask for counts, because Odoo's defaults hold up beautifully at one scale and stop being pleasant at another. Each of these numbers changes a decision you cannot cheaply reverse later:

Ask for	What it decides
Orders per day, lines per order	Whether a stock list view is a workable UI or the picking team needs a purpose-built screen
Deliveries per day, invoices per month	Whether document generation runs inline or has to be batched and queued
Active products and partners	Whether a computed field can stay non-stored, or has to be stored and indexed
Concurrent users at peak	Worker count, hosting shape, and whether long operations need to move off the request cycle
Peak versus average, by month	Everything above, recalculated for the month that actually matters

A wholesaler doing 40 orders a day for eleven months and 900 a day in December has a December problem, not an average problem. Design for December.

3. Collect every artefact that leaves the building

Not a description of it. The actual file.

Invoices, credit notes, delivery notes, pick lists, pallet labels, customer statements, EDI payloads, remittance advice, the weekly CSV that goes to the 3PL, the order confirmation email. Each one is a QWeb template, a report, or an export routine, and each one has details — a legal footer, a barcode symbology, a column order the customer's system parses positionally — that nobody mentions until UAT.

Ask two follow-ups per artefact: who receives it, and what happens if it's wrong. The second answer tells you whether it needs an approval step.

While you're here, ask about numbering. Do invoice numbers have to continue from the legacy system's sequence? Does the jurisdiction require gapless numbering? ir.sequence handles this easily if you know before go-live and awkwardly if you find out after the first invoice is posted.

4. Nail product identity early, because it's expensive to change

This one question reshapes the whole data model: is "500ml bottle, blue cap" a variant of one product template, or its own product?

Get it wrong and you're not refactoring — you're re-importing, and every historical transaction, report, and price list built on the old structure comes with you. Establish the template/variant split, the attribute list, and whether attributes affect price, cost, barcode, or packaging.

Then units of measure, which quietly break more implementations than variants do. Ask what they buy in, stock in, sell in, and report in, and get the conversion factors in writing. Fixed factors are fine. Variable ones — catch weight, meat and produce, anything sold by nominal case but invoiced by actual kilos — are a genuine design problem and need to be surfaced in week one, not month four.

Finally, traceability: lots, serials, or neither, and whether expiry dates or shelf life drive picking order. That decision propagates into every stock move.

5. Write the access model down as rules, not as job titles

"Sales reps shouldn't see cost prices" is a sentence. ir.rule records and field-level group restrictions are the implementation, and translating between the two surfaces contradictions fast.

Work through it as access rights and record rules: who can read, write, create, and delete each of the ten or so models that matter, and which records within those models. Then check the exceptions — there is always a regional manager who needs cross-territory read access, and there is always someone who has to approve their own requisition when a colleague is on leave.

Ask the multi-company question explicitly and early: is this one legal entity with several branches, or several res.company records with intercompany transactions between them? Those are different projects with different budgets, and clients use the word "company" for both. If it's genuinely multi-company and multi-country, the fiscal localization packages involved need naming now, because they bring their own chart of accounts, tax logic, and statutory reports.

6. Turn each integration into a contract before the sprint

Every external system needs six answers, and "failure behaviour" is the one nobody volunteers. Capture it in something structured you can hand to whoever builds it:

- name: 3PL despatch feed
  direction: odoo -> external
  trigger: stock.picking state changes to done
  transport: SFTP drop, CSV, one file per picking
  payload_owner: 3PL integrations team (external)
  idempotency: filename includes picking name; re-send overwrites
  on_failure:
    retry: 3 attempts, 15 min apart
    then: flag picking, notify #ops-alerts, do NOT block invoicing
  volume: ~300 files/day, peak 900

The on_failure block is the part that gets designed at 2am during go-live if you skip it here. Decide in advance whether a downstream outage should queue, retry, drop, or halt the upstream process — that is a business decision with money attached, not a technical default.

Name the human owner on the other side too, and confirm they have capacity in your window. External integration owners run on their own release calendar, and that mismatch slips more go-live dates than anything in your own backlog.

7. Define done as real transactions, not as a feature list

Acceptance criteria written as "the system shall support batch invoicing" are unfalsifiable. Acceptance criteria written as "Priya processes these twelve real orders from quotation to paid invoice, unaided" are testable, and they surface the exceptions the requirements phase missed.

Pair that with an explicit data migration scope: which historical data actually crosses over, and at what granularity. Opening balances and open documents are usually enough; full transactional history is usually a request nobody has costed. Whatever the answer, plan the import around stable external IDs so the load is re-runnable — you will run it more than once.

8. The question that eliminates the most custom code

Ask, for each process: what do you do today when it goes wrong?

Not the happy path — the happy path is already in Odoo. What happens when the customer changes the order after picking has started, when a delivery is short, when a payment arrives without a reference, when someone posts to the wrong period. Exceptions are where custom development actually lives, and they're the part clients never think to describe because handling them is muscle memory.

You'll also find that a third of the exceptions have a standard Odoo answer the client didn't know existed. That's the discovery work an Odoo consulting partner is really being paid for, and it's worth more than any amount of documentation.

The limitation worth stating

None of this produces complete requirements, and a checklist that claims otherwise is lying to you. Users cannot describe processes they perform automatically, and some requirements only become visible once someone sees a working screen and says "no, not like that."

The opposite failure is worse and more common: a 200-page specification written before anyone has touched Odoo, which faithfully documents the legacy system's workarounds and gets built as custom modules. Some of the most valuable output of a requirements phase is the list of things the client asked for and then agreed not to build. Keep that list. It's the one you'll reread when someone asks in year three why the system works the way it does.

Get a sandbox in front of the client in week two. Half your open questions answer themselves, and Studio is fast enough to prototype a model and a form view in the meeting itself — which is a much better way to find out you've misunderstood the noun.

Author bio:

The team at Master Software Solutions works on ERP consulting and AI engineering, with a focus on Odoo implementations, integrations, and custom module development for manufacturing, distribution, and food and beverage operations. They write about ERP delivery, requirements practice, and process automation.

How to Rescue a Failed Odoo Implementation: A Consultant's Triage Playbook

Mohit — Wed, 29 Jul 2026 06:48:24 +0000

The call usually comes about eleven months in. Go-live happened, sort of. Finance is still closing the month in a spreadsheet, the warehouse team keeps a parallel notebook, and someone has quietly stopped using the CRM entirely. The system technically works. Nobody trusts it.

Odoo rarely fails because Odoo is bad software. It fails because the implementation encoded somebody's misunderstanding of the business into 40 custom modules, and now every fix breaks two things. Panorama Consulting's 2026 ERP Report still puts cost overruns and schedule slippage among the most persistent problems across ERP projects of every size — and in our experience the overrun is almost never in licensing. It's in the rework.

Here's the triage sequence we actually run when we inherit a broken deployment, in the order we run it.

Step 1: Read the database before you read the code

Skip the codebase for a day. Open PostgreSQL and ask the system what people are really doing.

A few queries tell you more than a week of stakeholder interviews:

Row counts per model over time. If crm.lead stopped growing in March, sales abandoned the module in March. Nobody will volunteer this in a meeting.
ir.model.fields where state = 'manual'. Every field created through Studio or a quick patch. A healthy mid-size deployment has a few dozen. We've opened databases with 900. That number is a direct measure of how much undocumented business logic is floating outside version control.
stock.quant versus what the warehouse counts. Any gap here means inventory valuation is wrong, which means the P&L is wrong, which is usually the real reason finance went back to Excel.
ir_cron last-run timestamps and failure counts. Silently dead crons are behind a surprising share of "the system doesn't update" complaints.
Direct SQL writes. Grep the custom modules for self.env.cr.execute with UPDATE or INSERT. Every one of those bypasses the ORM, so computed fields never recomputed and stored values are now lying to you.

This step tells you which subsystems are actually broken versus which ones are merely unloved. They need very different fixes and people conflate them constantly.

Step 2: Separate the four failure types

Almost every rescue we've run sorts into four buckets, and the diagnosis determines everything after it.

Failure type	Symptom	Typical fix	Effort
Process mismatch	Users maintain shadow spreadsheets; the Odoo flow needs 9 clicks for something they do 200 times a day	Re-map the process, then reconfigure — usually less code, not more	Medium
Bad customization	Core modules edited in place, monkeypatched methods, upgrade-blocking overrides	Refactor to proper inheritance; delete what duplicates standard behaviour	High
Dirty data	Duplicate `res.partner` records, opening balances that don't tie, negative stock	Cleanse, reconcile, re-open a controlled migration window	Medium–High
No ownership	It works, but nobody was trained and no one owns the master data	Internal key-user model, documentation, defined data stewardship	Low cost, high resistance

Type 4 is the one clients least want to hear and the one that most often decides whether the rescue holds a year later. You can fix code in a sprint. You cannot fix "no one owns the product master" with a sprint.

Step 3: Audit the customizations against the upgrade path

This is where most inherited deployments are genuinely dangerous. Odoo only provides support and bug fixes for its three most recent major versions (supported versions policy), so a deployment stuck two versions back on unupgradeable custom code has a hard deadline whether or not anyone has written it down.

What we look for, roughly in descending order of how much it will hurt:

Edits to core addons in place. Someone changed addons/sale/models/sale_order.py directly. Every future update overwrites it. This is the single most common cause of "we can't upgrade."
Overrides that duplicate standard functionality. A custom pricing engine that reimplements pricelists. A custom approval flow where base.group_ rules and activities would have done it. Deleting code is the highest-ROI work in a rescue.
Missing or wrong depends declarations on computed fields — the reason stored values drift from reality and nobody can reproduce it on demand.
Data model abuse. char fields holding what should be many2one relations, so reporting is impossible without string parsing.

Practical note: run the audit against a restored production copy on the target version with OCA's OpenUpgrade scripts, not against a clean demo database. Demo data hides exactly the constraint violations you need to find.

By the end of this step you should be able to sort every custom module into keep, refactor, or delete — with a rough hour estimate on each. That list, not a strategy deck, is the rescue plan. When we scope this as an Odoo consulting partner brought in mid-project, the delete column is usually the largest of the three, and clients are consistently surprised by that.

Step 4: Stabilise before you improve

There's a strong temptation to fix everything in one heroic release. Don't. A failed implementation has already spent the organisation's patience, and the next visible failure is often fatal to the project politically.

Sequence it:

Weeks 1–2: stop the bleeding. Fix the crons, correct inventory valuation, get one clean month-end close. Nothing else.
Weeks 3–6: retire the shadow systems, one team at a time. Pick the team with the most pain and the least political weight. Get a real win you can point to.
Weeks 7+: the refactor and upgrade path. Only now touch the custom module debt, with tests.

The stabilisation phase produces almost no new features and it is the phase that saves the project. A single clean close does more for user trust than any amount of roadmap.

When rescue is the wrong answer

Sometimes the honest recommendation is to stop patching. We've walked into two situations where a rebuild on a fresh database was cheaper than a rescue:

The first is when the chart of accounts itself was configured wrong at go-live and a year of transactions sits on top of it. Restructuring live accounting data is slow, risky, and auditors hate it. Starting a new database with correct configuration and migrating open balances only is frequently the lower-risk path.

The second is when custom code exceeds roughly half the functional footprint. At that point you aren't running Odoo, you're running a bespoke application that happens to import from Odoo, and every upgrade will cost what the original build cost. Rebuilding against standard functionality — accepting that a few processes will change to match the software instead of the reverse — is usually cheaper over three years.

Both conversations are uncomfortable, and both are better had in month one of the rescue than month eight. The trade-off is real, though: a rebuild resets user trust to zero a second time, and some organisations genuinely cannot survive that. If adoption is already fragile, a slower rescue on flawed foundations can be the right call even when it's the technically worse one.

Where to start tomorrow

If you're currently living inside a struggling implementation, do one thing this week: restore a production copy to a staging server and run the queries in Step 1. Count the manual fields. Check the cron failures. Diff stock.quant against a physical count on one warehouse.

You'll have a factual picture of what's broken within a day, and it will almost certainly differ from the story being told in status meetings. Every rescue we've run well started with that gap.

The team at Master Software Solutions is an ERP consulting and AI engineering firm that helps mid-size businesses automate operations with Odoo and custom AI agents. They write about ERP adoption, implementation recovery, and business process automation.

Odoo Community to Enterprise: What the Migration Actually Involves

Mohit — Wed, 22 Jul 2026 13:18:53 +0000

"Migrating from Community to Enterprise" is one of those phrases that hides two different projects inside it. Ask five teams what they mean by it and the answers range from "we flipped a switch over lunch" to "we spent three months and we're still cleaning up." Both are telling the truth. The gap between those two experiences is the part almost nobody scopes before they start — and it's what this post is about.

I'll walk through what the move actually involves in practice: what's genuinely trivial, what quietly eats your timeline, and what you're really paying for once the invoice arrives.

Two migrations wearing the same name

There are two separate operations people lump together here.

The first is an edition switch: you stay on the same Odoo version and move from Community to Enterprise. Same major release, same database, different code and a license key.

The second is a version upgrade: you move the database itself forward — say Odoo 15 to Odoo 19 — with all the schema changes that implies.

Most "Community to Enterprise" requests are secretly both. Teams asking for Enterprise are usually sitting on an older Community release and want the current apps, which means they need to change edition and jump several versions. Figuring out which of these you're actually signing up for is the first real decision, because they carry completely different risk profiles.

The edition switch is the easy 20%

On the same version, switching editions is a deployment task, not a data migration. Odoo's own documentation for moving from Community to Enterprise is short for a reason. On a self-hosted instance you point your addons_path at the Enterprise code, install one module, and register your subscription:

addons_path = /opt/odoo/enterprise,/opt/odoo/addons

Enterprise has to come first in that list so its modules take priority over the Community versions. Restart the service, install web_enterprise (that's the module that flips the database into Enterprise mode), then activate your subscription code under Settings. Your PostgreSQL data doesn't move. Nothing gets rewritten.

If you're heading to Odoo Online or Odoo.sh instead of self-hosting, you don't even do this by hand — both platforms only run Enterprise, so the "switch" is really a decision about where you host.

That part fits in an afternoon. It's also the part people fixate on, which is exactly why projects that look simple on paper still blow their estimates.

The part that actually eats the schedule

The real work is deciding what happens to every module you've already got installed.

A mature Community deployment is rarely stock. It's core Odoo, plus a layer of OCA community modules, plus whatever custom code someone wrote to fill the gaps. Enterprise ships its own versions of a lot of that functionality, and now they collide. Community accounting (account) versus Enterprise accounting (account_accountant). OCA HR and payroll modules versus the Enterprise HR suite. Custom views and automations you built by hand that Enterprise's Studio now handles natively.

For each of those you have to make a call: keep it, replace it with the Enterprise equivalent, or migrate the data out before you uninstall it. Get it wrong and you get two modules writing to overlapping tables, duplicated records, and reports that quietly disagree with each other. Deciding what to keep and what to retire is judgment work rather than something you can script, and it's the main reason teams bring in an experienced Odoo migration partner instead of toggling web_enterprise on a Friday and hoping the weekend holds.

None of this shows up in a quick demo. It shows up three days in, when someone notices the tax report changed.

When a version upgrade rides along

If you're also jumping versions — and most people are — that's where the genuine data migration lives.

Odoo SA doesn't offer an upgrade path for Community databases; its upgrade platform is aimed at Enterprise customers. For Community, the established route is the OCA's OpenUpgrade project, a set of migration scripts that move a database from one major version to the next. The important constraint: it works one major version at a time. Going from 15 to 19 means 15 → 16 → 17 → 18 → 19, and every hop can bring renamed fields, restructured models, and modules that no longer exist.

Before you touch any of it, back up the database and the filestore — the filestore holds your attachments and images, and a pg_dump without it gives you a broken restore. Then run the whole sequence on a copy and have real users test their daily workflows on the result. In the migrations we've run, testing reliably takes longer than the migration scripts themselves, and that's the healthy ratio, not a warning sign.

What you're actually buying

Community is free and licensed under the LGPLv3. Enterprise is a proprietary per-user subscription — roughly $25 to $31 per user per month on the Standard plan in 2026 depending on region and billing terms, with the Custom tier higher and a One App Free plan at the bottom. Current numbers live on Odoo's pricing page, and they shift by country, so check your own.

The subscription also buys you back into the support window. Odoo actively supports its three most recent major versions; run something older and you're either unsupported or paying a surcharge to stay covered. For a lot of teams that support timeline, not the feature list, is the actual trigger for the move.

Here's the honest limitation, though: Enterprise isn't automatically an upgrade. If you've built on solid OCA modules, part of what you're "gaining" is paid replacements for things that already worked — plus a recurring bill and a little less freedom to self-host however you like. The real wins are genuine (Studio, full accounting, mobile apps, supported upgrades, the newer AI features), but they're worth pricing honestly against what you're giving up, not assumed.

Start with the audit, not the license

If there's one thing to take away, it's the order of operations. Before you buy a single Enterprise seat, run a module audit:

Inventory every installed module and tag each one as core, OCA, or custom.
Map each OCA and custom module to its Enterprise equivalent, or mark it "keep."
Confirm your target version sits inside the supported window.
Take a full backup including the filestore, and restore it somewhere to prove it actually works.
Rehearse the entire switch on a staging copy and let real users run their daily flows against it.

The license is the cheap, reversible part. The module and version decisions are what you'll live with for years. If the audit comes back showing you're mostly on core apps, your switch really might be a quiet afternoon. If it turns up a stack of OCA modules and homegrown views, you've just found your actual project — and it is far cheaper to find that now than halfway through cutover weekend.