DEV Community: Mohit

From 43 Spreadsheets to One Odoo Database: Notes From a Canadian Rollout

Mohit — Thu, 24 Sep 2026 09:49:22 +0000

This is a composite of three Canadian SMB projects, with names and details changed. The numbers are illustrative of what we saw, not audited figures from one client.

The file was called MASTER_inventory_FINAL_v7_USE THIS ONE.xlsx. There was also a v8. Nobody was sure which one the warehouse used.

That was week one at a 60-person building-supplies distributor with a yard in Ontario and a smaller one in BC. They weren't disorganised. They'd grown for fifteen years on spreadsheets because spreadsheets worked, right up until the day they didn't. When we finished the inventory of every file that ran part of the business, the count was 43.

This post is about how that got down to one database, and the parts that were harder than the software.

Step one: inventory the spreadsheets, not the processes

Most ERP projects start with process mapping workshops. We did those too, but later. The first thing was a plain list of every spreadsheet that someone opened at least once a week, with four columns:

file name and location (shared drive, someone's desktop, email attachment)
owner, meaning the one person who'd notice if it broke
what it feeds (another sheet, the accounting system, a customer)
what breaks if it's wrong for a day

That last column did most of the work. It split the 43 files into roughly three groups: about a dozen that directly moved money or stock, about twenty that were reporting built on top of those, and the rest, which were personal trackers nobody else relied on.

The reporting sheets were the easy win. Once the source data lives in one place, most of them simply disappear. The personal trackers we left alone. The dozen money-and-stock sheets were the actual project.

Research has been saying this for a long time. Raymond Panko's review of spreadsheet error studies concluded that errors are "both common and non-trivial". What surprised the team here wasn't that errors existed. It was how many of them were copy-paste links between files that had silently broken months earlier.

The cleanup nobody budgets for

Before anything went into Odoo, the customer and product lists had to be merged across both yards. That's where the time went.

We ran a quick duplicate check in pandas before touching the import tool. It's crude, but it finds the obvious problems in minutes:

import pandas as pd

df = pd.concat(
    [pd.read_excel("customers_on.xlsx"), pd.read_excel("customers_bc.xlsx")],
    ignore_index=True,
)

# normalise the fields people type differently
df["name_key"] = (
    df["Customer Name"].str.upper()
    .str.replace(r"[^A-Z0-9]", "", regex=True)
    .str.replace(r"(INC|LTD|LIMITED|CORP)$", "", regex=True)
)
df["phone_key"] = df["Phone"].astype(str).str.replace(r"\D", "", regex=True).str[-10:]

dupes = df[df.duplicated(["name_key"], keep=False) | df.duplicated(["phone_key"], keep=False)]
dupes.sort_values("name_key").to_excel("review_duplicates.xlsx", index=False)

That produced about 300 candidate duplicates out of roughly 2,100 customers. Around two thirds were real. The rest were legitimately separate accounts: a head office and a branch of the same contractor, each with its own billing terms.

No script decides that last part for you. Someone from accounts receivable sat with the list for most of two days. Plan for that. When teams compare odoo implementation services, this is the line item worth asking about: who does the merge review, and how many days are in the quote for it.

External IDs saved us twice

Odoo's importer takes Excel or CSV files, and the documentation strongly advises not removing the External ID column from the templates. Take that seriously. We gave every record a stable key before the first import:

id,name,default_code,categ_id/id
product_yard_2x4_8ft,2x4 SPF 8ft,LUM-2408,cat_lumber
product_yard_osb_716,OSB 7/16 4x8,SHT-0716,cat_sheet_goods

Two things made this worth the effort. First, imports are permanent and can't be undone, so when the first product load had wrong units of measure on 140 items, we fixed the spreadsheet and re-imported against the same IDs instead of hunting down records by hand. Second, the vendor price lists and reordering rules referenced products by id, not by name, so a renamed product didn't break every file that pointed at it.

Always hit Test before Import. It catches most mapping errors without writing anything.

Where the spreadsheets were hiding a process

The hardest sheet was the one the sales desk used to price special orders. It looked like a price list. It was really an approval workflow: margin below 18% meant the cell turned red, and a red cell meant you walked over to the sales manager's desk.

That rule lived in conditional formatting and in one person's habits. In Odoo, it became an approval rule on quotations below a margin threshold. Standard Sales doesn't do margin-based approvals out of the box, so this was one of the few small customizations in the project. It took a day to build and a month to get people to stop walking over anyway.

This pattern is common in distribution. We wrote separately about how manual order processing erodes margin for wholesale businesses, and nearly every case traces back to a rule that only existed in someone's spreadsheet.

The two yards added another wrinkle: separate stock, a shared customer list, and different provincial sales tax (HST in Ontario, GST plus PST in BC). That's a warehouse-and-company structure question you want answered in week two, not week ten. There's a longer answer to whether Odoo can handle a multi-location structure if you're facing the same decision. Here it was one company, two warehouses and fiscal positions per province.

Before and after (illustrative)

These are the kind of figures we tracked. Treat them as a shape, not a benchmark.

Spreadsheets in weekly use: 43 before, 6 after (the personal trackers, plus a commission sheet sales refused to give up)
Month-end close: about 9 working days before, about 4 after three months live
Stock count variance at the BC yard: noticeably lower once receipts were scanned instead of keyed from paper
"Which version is current?" messages in the team chat: gone within a month, which the owner said was the only metric he cared about

The close improvement didn't show up in month one. Month one was slower than the old way. It showed up in month three, once people stopped double-checking the new system against the old sheets.

What didn't work

We tried to migrate five years of transaction history. It was a mistake. The old data was inconsistent enough that importing it created reconciliation noise for weeks. In the end we loaded open items and opening balances only, and kept the old files read-only for lookups. If you're planning your own move, start there and add history only if someone can name the report that needs it.

We also underestimated training at the second yard. The Ontario team had been in the workshops; BC had only seen demos. Their first two weeks were rough.

If you're starting this

Do the spreadsheet inventory first, before any demo or workshop. It'll tell you how big the project really is. If you bring in outside help, favour the team that asks to see your spreadsheets in the first meeting. The ones that start with a feature tour usually find the hidden processes late.

Then pick your top dozen money-and-stock files, and write down the rule each one is secretly enforcing. That list is your real requirements document.

Job Costing in Odoo for Canadian Construction Firms: Analytic Plans, Holdbacks and Progress Billing

Mohit — Thu, 10 Sep 2026 11:51:02 +0000

Most construction ERP rollouts I have seen go wrong in the same quiet way. The accounting migration lands fine, the projects get created, invoices go out — and four months later the controller still cannot tell you which of the eleven active jobs is making money, because every cost hit a single analytic account called "Projects".

That is not a module problem. It is a structure decision made in week two of configuration and then inherited for years. The discovery phase is where it should be settled, and for contractors it comes down to four questions the system has to answer on demand.

The four questions a contractor's system has to answer

What has this job cost me so far, split by cost code, and how does that compare to the estimate?
What have I committed but not yet been billed for — the open POs and unapproved subcontractor progress claims?
What can I legally bill this month, and what portion of it must sit as holdback?
When my sub sends a proper invoice, what is my payment clock? Odoo answers the first and third out of the box if you set it up correctly. The second needs work. The fourth is a legal deadline, not a feature, and it is the one that generates penalties.

Two analytic plans, not one

Odoo 19's analytic accounting works on plans that group analytic accounts, and a journal item can carry a distribution across several plans at once. That second part is what makes proper job costing possible, and it is the part teams skip.

Enable it under Accounting ‣ Configuration ‣ Settings ‣ Analytics, then build two plans under Accounting ‣ Configuration ‣ Analytic Plans:

Plan: Jobs                      Default Applicability: Mandatory
  ├── 2026-014  Riverbend Retrofit
  ├── 2026-021  Kanata Warehouse Phase 2
  └── OH-000    Overhead / unassigned

Plan: Cost Codes                Default Applicability: Mandatory
  ├── 01  General conditions
  ├── 03  Concrete
  ├── 15  Mechanical
  ├── 16  Electrical
  └── 99  Rework and warranty

Every cost line then carries both a job and a cost code, and you can slice either way without a custom report. Setting Default Applicability to Mandatory means an entry cannot be confirmed with the field empty — annoying for a week, and the reason your numbers are still trustworthy in year three.

Use the Applicability tab to stop the mandatory rule from firing where it makes no sense. A line for corporate insurance or a bank fee does not belong to a job. Set an applicability line with the financial account prefixes that should be exempt, or the AP clerk will start assigning everything to OH-000 to get past the validation, which is worse than having no rule.

Keep the cost-code list short at the start. In the rollouts we have run, contractors who launched with 12 to 20 codes were still using them a year later; the firm that imported its full 180-code legacy list ended up with 90% of costs sitting in four codes and no useful comparison against estimate.

Automating the distribution you can predict

Some costs always land the same way. Under Accounting ‣ Configuration ‣ Analytic Distribution Models you can pin a distribution to an account prefix, a partner, a product or a product category — so equipment depreciation splits 60/30/10 across divisions automatically, and the clerk never sees the prompt. Models can be sequenced and combined across plans.

This is the difference between a costing structure people maintain and one they resent. If a contractor is picking the same cost code 40 times a week, that is a distribution model waiting to be created, and it is exactly the kind of detail worth nailing down during odoo implementation services rather than six months after go-live.

Progress billing: milestones or percent complete

Odoo supports milestone invoicing natively. Create the service product with Product Type: Service, set Create on Order to Project and Task, and set the Invoicing Policy to Based on Milestones. Milestones carry a Delivered %; marking one reached updates the delivered quantity on the sales order line, and you invoice from there. Reaching a milestone does not create the invoice by itself — someone still clicks Create Invoice, which is the behaviour you want when a payment certifier is in the loop.

That fits fixed-price work with defined phases. It does not fit a CCDC-style monthly progress claim priced by unit quantities installed, where the number changes every month based on site measurement. For those, the pattern that has held up for us is a sales order line per schedule-of-values item, with quantities updated monthly from the field measurement, then invoiced on delivered quantity. It is more clicking. It also matches what the consultant actually signs.

Standard Odoo will not give you a construction-grade schedule of values with retainage columns, previous-billings carry-forward and stored materials, and you should budget for a light custom report if the owner's certifier expects that layout. Pretending the standard invoice PDF will pass is how a project loses a month.

Holdback: 10%, and Odoo has no field for it

Ontario's Construction Act defines holdback as 10 per cent of the value of the services or materials supplied under a contract. Other provinces run similar regimes under their own lien legislation with their own release rules, so confirm the number and the release trigger for each province you work in before configuring anything.

There is no holdback checkbox in Odoo. Two workable approaches:

Invoice the full progress claim and let the 10% sit open in AR. Simple, and it wrecks your aging report — every certified job shows a permanently overdue balance, and collections calls start going out on money you are not entitled to yet.

Invoice the full claim with a negative holdback line routed to a dedicated Holdback Receivable account. The customer's open balance equals what they actually owe this month, and the retained amount accumulates in its own account you can age separately by job. Release is a positive line on the certification invoice.

We use the second. It needs one product ("Holdback retained — 10%") whose income account points at the holdback asset account, and your accountant will need convincing that a product is the right vehicle. The alternative — a manual journal entry per claim — gets skipped the first busy month, and then the balance is wrong.

Either way, model it before the first invoice. Retrofitting holdback across nine months of posted claims is a reconciliation exercise nobody has time for.

The payment clocks are legal deadlines, not reminders

Since prompt payment came into force, the dates on your documents carry consequences. Under the Ontario Act, an owner has 28 days after receiving a proper invoice to pay the contractor (s. 6.4); the contractor then has 7 days to pay subcontractors out of what it received (s. 6.5); and where the owner does not pay, the contractor must give subs notice of non-payment within 14 days. Adjudication exists to resolve the fight quickly, which means your records get read by someone who was not there.

Practically, in Odoo:

Store the proper invoice received date as its own field on vendor bills. Bill Date is whatever the sub typed; the clock runs from receipt.
Automate the sub-payment reminder off that field, not off the standard due date.
Keep the certifier's approval as an attachment on the invoice, not in someone's mailbox. None of this is exotic configuration. It is the sort of thing that gets left out of scope because it looks administrative, and then becomes the reason a payment dispute costs more than the ERP did. Our notes on implementation best practices cover the same idea in a general setting: the fields that carry legal weight get configured first.

What to have working before go-live

Two analytic plans, mandatory, with applicability exemptions for non-job accounts
A cost-code list you can defend at 20 items or fewer
Distribution models for the five or six recurring costs
One holdback product and account, with a documented release procedure
Progress-claim format shown to one real certifier and confirmed acceptable
Proper-invoice-received date captured on vendor bills Six items. Getting them right is roughly two weeks of a configuration consultant's time, and it is the cheapest two weeks in the project — far cheaper than the three most common implementation mistakes, all of which show up as bad numbers rather than broken software. Before you sign off on a construction rollout, sit with your controller, open a job that is already half-built, and see whether the system can tell you what it has cost. If it cannot, the structure is wrong, and no amount of module selection will fix it.

An Hour-by-Hour ERP Cutover Playbook for Canadian Distributors

Mohit — Tue, 08 Sep 2026 13:10:56 +0000

Cutover is the only part of an ERP project with no room to renegotiate. Configuration slips by a week and nobody outside the project notices. Cutover slips by four hours and a distribution business cannot ship on Monday.

This is the plan I would hand a Canadian distributor moving from a legacy system to Odoo over a single weekend — roughly 60 hours, Friday evening to Monday morning. It assumes a warehouse that does not run Saturdays, one legal entity, and a production instance already provisioned. Adjust the arithmetic if any of that is different for you.

Rehearse it twice, on real data

The single strongest predictor of a clean cutover is how many times you have already done it.

Two full rehearsals on a copy of production data, timed with a clock, is the minimum. Not "we tested the import" — the entire sequence, in order, with the same people running the same commands. The first rehearsal finds broken steps. The second finds the real durations, which will be longer than your estimates.

On Odoo.sh this is what staging branches are for. Staging builds get a neutralized copy of the production database, and per the branch documentation they are explicitly not treated as persistent storage — outgoing mail and scheduled actions are disabled so a rehearsal cannot email your customers. If you are self-hosting, do the same thing manually before anything else runs:

UPDATE ir_cron SET active = false;
UPDATE ir_mail_server SET active = false;
UPDATE fetchmail_server SET active = false;
UPDATE base_automation SET active = false;

Forgetting that last one is how a rehearsal fires 4,000 order-confirmation emails from a test database. I have watched it happen.

Agree the rollback trigger before Friday

Write down, in advance, the condition under which you abandon the cutover and reopen the legacy system on Monday. Then write down the latest clock time at which that decision can still be executed.

For a weekend cutover the decision point is usually Sunday around midday. Past that, there is not enough runway to restore the legacy system, re-key the weekend's work and open on time. So the trigger is a time, not a feeling: if opening inventory is not reconciled and opening balances are not posted by 12:00 Sunday, we roll back.

The reason to write it down is that nobody makes this call well at 2am on Sunday with sunk cost in the room. Pre-committing removes the argument.

The freeze schedule

Freezes are the part clients push back on hardest, and the part that most reliably determines whether the weekend works.

Data	Freeze from	Why
Master data (products, partners, UoM, pricelists)	Wednesday 17:00	Extracts have to be stable while you clean and load them
Purchase orders	Thursday 17:00	Open POs become the migrated backlog; a PO raised Friday afternoon exists in neither system
Sales orders	Friday 12:00	Anything after this is keyed into Odoo on Monday
Goods receipts / shipments	Friday 15:00	Warehouse needs clear time before the physical count
Legacy system, all write access	Friday 18:00	This is the extract point

Two days of master-data freeze sounds excessive until you have watched a vendor record created on Thursday afternoon fail to appear in Monday's system, and the AP clerk conclude the migration lost data.

Give the sales team a written procedure for the frozen window — where to record orders taken Friday afternoon, and who keys them in Monday. A shared spreadsheet with a named owner is fine. Nothing is not fine.

Friday 18:00 to Monday 06:00

Window	Step	Owner
Fri 18:00–18:30	Legacy write access revoked. Final full backup taken and checksummed.	DBA
Fri 18:30–20:00	Final extracts pulled: master data deltas since Wednesday, open SOs, open POs, AR/AP aging, trial balance, on-hand stock by location.	Data lead
Fri 20:00–23:00	Physical count of high-value and fast-moving SKUs. Count sheets on paper, entered later.	Warehouse
Sat 08:00–11:00	Master data delta load. Row counts reconciled against extract.	Data lead
Sat 11:00–14:00	Opening inventory loaded as `stock.quant` records. Reconciled to count sheets, not to the legacy report.	Data lead + Warehouse
Sat 14:00–18:00	Open SO and PO backlog loaded. Spot-check 20 documents against legacy printouts by hand.	Ops lead
Sat 18:00–21:00	Opening balances posted: trial balance as a journal entry, AR and AP as open items per invoice.	Finance
Sun 08:00–11:00	`ir.sequence` values set. Tax and fiscal positions verified against real invoices. Warehouse routes and operation types checked.	Finance + Ops
Sun 11:00–12:00	Reconciliation review. Go / rollback decision.	Steering group
Sun 12:00–15:00	Crons, mail servers and automation rules re-enabled. Integrations repointed. Smoke tests.	Tech lead
Sun 15:00–18:00	Three end-to-end business transactions: quote to invoice, PO to receipt to bill, pick to pack to ship.	Ops + Finance
Sun 18:00–20:00	User access enabled. Comms sent. Floor-walker roster confirmed.	Project manager
Mon 06:00	First shift. Two floor-walkers per shift for the first week.	Everyone

The gaps in that table are deliberate. Overnight Saturday is not scheduled, because a team that has been awake for 30 hours makes the mistakes that turn a cutover into an incident.

Sequence numbers are the step everyone forgets

ir.sequence controls invoice, order and picking numbering. If you leave it at the Odoo default, your first live customer invoice is INV/2026/00001 while your legacy system last issued 48,217.

Your accountant will not enjoy that, your customers will query it against their POs, and fixing it retroactively means renumbering posted journal entries — which you should not do.

Set the prefix and next number to continue the legacy series, on Sunday morning, and verify by creating and deleting one draft document of each type. Do the same for pickings, receipts and purchase orders. It takes twenty minutes and prevents a month of reconciliation questions.

Reconcile with counts, not with confidence

Every load gets a row count comparison, extract against database, before anyone declares it done:

SELECT 'partners', count(*) FROM res_partner WHERE active
UNION ALL SELECT 'products', count(*) FROM product_template WHERE active
UNION ALL SELECT 'open_moves', count(*) FROM account_move WHERE state = 'posted' AND payment_state != 'paid';

Then three value checks that have to match the legacy system to the cent: AR total, AP total, and inventory valuation. If inventory valuation is off, find out whether it is a quantity problem or a costing-method problem before you touch anything — landed cost and average-cost differences between systems are common and are not data errors.

Getting the opening-balance and valuation treatment right is the part of a migration where experience actually shows, and where an implementation partner earns its fee; it is a substantial share of what Master Software Solutions spends its cutover weekends doing. The mechanics of extracting and reshaping legacy data are covered in more depth on their Odoo migration pages.

Do not decommission the legacy system

Keep it running, read-only, for at least a year.

Beyond the obvious reason — someone will need a 2023 invoice — there is a Canadian compliance one. The CRA requires business records to be kept for six years from the end of the last tax year they relate to, with some categories held indefinitely. If you migrated two years of transactional history and the legacy system holds seven, switching it off does not satisfy that. Either migrate the full history, or keep the old system available in a documented read-only state.

Backups: know what you actually have

Take your own backup before cutover. Do not assume the platform's schedule covers the moment you care about.

Odoo.sh keeps 14 full backups of each production instance for up to three months — daily for a week, weekly for a month, then monthly — and does not back up staging or development builds at all. That is a reasonable policy and it is not a cutover safety net. You want a manual dump immediately before the first live transaction, stored somewhere you control, with a restore you have actually tested.

Restoring is the half nobody rehearses. A backup you have never restored is a file, not a recovery plan.

Week one is part of cutover

The weekend gets the plan. Week one gets the problems.

Budget floor-walkers, not a help desk — someone physically standing where the work happens, because a picker will not raise a ticket, they will improvise a workaround and teach it to the next shift. Expect a productivity dip through week two and staff for it rather than being surprised by it. Keep a triage log with a daily 15-minute standup, and hold a single named person accountable for closing configuration issues within 48 hours. Whether that capacity comes from your own team or an external support and maintenance arrangement matters less than it being explicitly resourced before Monday, which is where most plans quietly leave a gap.

The honest limitation of a weekend cutover

It only works when the business genuinely stops. A distributor that ships six days a week, or runs a customer-facing e-commerce channel that cannot pause, does not have a real freeze window — and forcing one produces a backlog that takes three weeks to clear.

In that situation a phased cutover is better, even though it is more expensive and more complex: you run two systems in parallel for a defined period, with a written rule for which is authoritative for each transaction type. Nobody enjoys it. It beats a weekend plan that assumes a stoppage the business cannot deliver, and choosing between the two shapes is a conversation worth having with an ERP consulting team before the date is set rather than after.

The one artefact that matters

Build the runbook as a shared document with a checkbox and a timestamp field per step, and make one person responsible for ticking them in real time.

Not because the ticks matter. Because at 3pm Sunday, when someone asks whether opening balances were posted before or after the inventory load, the answer has to be a fact rather than a recollection.

Making Odoo Bilingual for Quebec: Where EN/FR Actually Breaks

Mohit — Tue, 01 Sep 2026 09:52:49 +0000

Activating French in Odoo takes about ninety seconds. Settings → Translations → Languages, tick fr_CA, save. The menus flip, the buttons flip, and everyone agrees the Quebec problem is solved.

Then someone in Montréal opens an invoice PDF. The header is French. The line items say Stainless Steel Bracket, 40mm. The payment-terms footer is English. The email that delivered it was subject-lined "Your invoice is ready."

Quebec's Charter of the French Language is not interested in your menus. Section 57 says invoices, receipts, acquittances and other documents of the same nature must be drawn up in French, and that you may not send one in another language unless the French version is available on terms at least as favourable. Section 52.1 says computer software must be available in French unless no French version exists. The obligations that bite are about the artifacts your ERP emits and the interface your Quebec staff sit in front of — not the language dropdown in the corner of the screen.

Here is what actually has to be fixed, in the order the fixes tend to be needed.

Install `fr_CA`, not `fr_FR`

This sounds pedantic and it is not. fr_FR gives you DD/MM/YYYY, a comma decimal separator and a non-breaking-space thousands separator. Canadian French convention differs, and more importantly the vocabulary differs — Odoo's fr_CA translation catalogue uses the terminology Quebec accountants and the OQLF expect, where fr_FR will happily print terms that read as European.

# check what you've actually got active
env['res.lang'].search([('active', '=', True)]).mapped('code')
# ['en_US', 'fr_CA']  ← what you want
# ['en_US', 'fr_FR']  ← what half the instances I've opened actually have

If you inherited an instance with fr_FR installed and data already translated against it, switching is not a checkbox. The translated values are keyed by language code, so you are looking at a migration of every translated field, not a settings change.

The translations are not where the old tutorials say they are

If you learned Odoo before version 16, you know ir_translation — one row per translated term, queryable, easy to audit. It's gone. Since this change, translated fields are stored as JSONB in the column itself. A product name is no longer a string:

{"en_US": "Stainless Steel Bracket, 40mm", "fr_CA": "Support en acier inoxydable, 40 mm"}

That is a much better design and it breaks every audit script written against the old model. The useful consequence is that you can find your gaps in one query:

SELECT id,
       name->>'en_US' AS english,
       name->>'fr_CA' AS french
FROM   product_template
WHERE  name->>'fr_CA' IS NULL
   OR  name->>'fr_CA' = name->>'en_US';

Run that against product_template, product_category, account_tax, account_payment_term and any custom model with a translate=True field. On a catalogue of a few thousand SKUs the result is usually humbling. Product names are the single largest source of English text on a French invoice, and no amount of interface translation touches them.

Most teams find this at UAT, which is late — the ordering problem is that the catalogue has to be translated before the data load, not after, and it's the kind of sequencing that specialists who handle ERP rollouts like this build into the migration plan rather than discovering in week nine.

`res.partner.lang` is the switch that matters

Odoo decides what language to speak to a customer based on the lang field on the contact — not the language of the user who clicked the button. This is the field that governs invoice PDFs, quotation PDFs, portal pages and automated emails. It is also, in a freshly migrated database, almost always set to whatever the default was at import time.

qc = env['res.partner'].search([
    ('state_id.code', '=', 'QC'),
    ('lang', '!=', 'fr_CA'),
])
qc.write({'lang': 'fr_CA'})

Do not run that blind. Province is a proxy for language preference, not the thing itself — plenty of Quebec-registered businesses correspond in English and will tell you so. What the query is genuinely good for is producing the list of contacts a human then has to make a decision about. In practice the sales team owns that list, and the field gets set as part of customer onboarding from then on.

Reports render in the language you pass them

A QWeb report does not automatically pick up the partner's language. You set it, either in the template:

<t t-call="web.html_container">
  <t t-foreach="docs" t-as="doc">
    <t t-set="lang" t-value="doc.partner_id.lang or 'en_US'"/>
    <t t-call="web.external_layout" t-lang="lang">
      <!-- ... -->
    </t>
  </t>
</t>

or at the call site:

report = env.ref('account.account_invoices')
pdf, _ = report.with_context(
    lang=move.partner_id.lang
)._render_qweb_pdf('account.report_invoice_with_payments', move.ids)

The standard accounting reports handle this correctly. Custom report templates written by someone in a hurry frequently do not, and the failure is silent — the PDF renders, it just renders in English. If you have custom reports, this is the first place to look.

Payment terms and the invoice footer deserve their own mention because they are separate records with their own translations, and a French invoice with English terms and conditions is exactly the artifact section 57 is about. Contracts of adhesion carry a further requirement — the French version must be presented first — which DLA Piper's summary of the June 2025 changes covers in more detail than I will here.

Mail templates need to be told, too

<field name="lang">{{ object.partner_id.lang }}</field>

Without that line the template renders in the language of the user or cron job that triggered it. Sales order confirmations, invoice delivery and payment reminders are the three that customers see most, and all three ship with the expression set correctly in core — so this is a problem you create, not one you inherit. Check every mail.template your custom modules add.

Your custom module has no French until you ship a `.po`

Strings in your own code are untranslated until extracted. Wrap them, export, translate, commit to my_module/i18n/fr_CA.po:

odoo-bin -d mydb --i18n-export=fr_CA.po \
         --modules=my_module --language=fr_CA

The extraction gotcha that catches everyone at least once:

# NOT extracted — the f-string is evaluated before _() sees it
raise UserError(_(f"Missing tax on line {line.name}"))

# extracted correctly
raise UserError(_("Missing tax on line %s", line.name))

Ship the .po file in the module. Translating through the UI writes to the database, which means it does not survive a rebuild and does not exist in your other environments.

The honest limitation

None of this makes your instance compliant, and it would be dishonest to imply otherwise. It makes it capable of being compliant. Somebody with real French still has to write the product descriptions, because machine-translated SKU names read as machine-translated to a Quebec customer, and a bad French translation is worse for the relationship than an English one. Budget the translation work as translation work — a per-string cost with a human in the loop — not as a configuration task.

Two more things sit outside Odoo entirely: OQLF registration for employers with 25 or more staff, and the question of whether a heavily customised self-hosted instance makes you the software vendor for section 52.1 purposes. Ask a Quebec-qualified lawyer, not your systems integrator, and certainly not me.

Run the test a lawyer would run

Create a user with lang = fr_CA and no English fallback habit. Have them raise a quotation for a Quebec customer, confirm it, invoice it, and email the invoice. Then open every PDF and every email and read them as a customer in Montréal would — line items, tax labels, payment terms, footer, email subject and body.

Anything still in English is a finding. That takes twenty minutes and tells you more than any compliance checklist.

Big-Bang vs Phased ERP: Which Actually Fits a Canadian Mid-Market Rollout

Mohit — Thu, 27 Aug 2026 10:39:44 +0000

Ask a CFO whether to go big-bang or phased and you get a budget answer. Ask an engineer and you get the right one, because this is an integration-architecture decision wearing a finance costume.

The question is not "how much disruption can we absorb." It is "how many systems of record am I willing to have at once, and for how long." Every other trade-off falls out of that.

What phasing actually costs you technically

The pitch for phased is that risk goes down because you change less at a time. That is true of user-facing risk and false of data risk.

Say you go live with Odoo Accounting and Inventory in March, and defer Sales and Purchase to September. For six months, sales orders live in the legacy system and stock lives in Odoo. Which means you now own:

An interface pushing legacy orders into Odoo as stock.picking records, or a nightly reservation sync
A reverse interface returning available quantities so legacy quoting does not oversell
A reconciliation process, because those two will drift
Two places where a user can change a unit price, and a rule about which one wins

That is not a lower-risk configuration than a big-bang. It is a lower-change configuration with a distributed-systems problem bolted on for two quarters. Anyone who has maintained a temporary integration knows how the word "temporary" performs under load.

The dependency graph is the thing to look at. In Odoo, sale depends on stock for delivery and on account for invoicing; mrp depends on stock and purchase. Cut the phase boundary across one of those edges and you are hand-rolling what the framework gives you for free.

The dual-write problem, concretely

Any phase boundary that leaves inventory in one system and order intake in another is a dual-write. You will need a reconciliation job, and you should write it before go-live rather than in week three when the numbers stop matching.

Something roughly this shape, against Odoo's external API:

import xmlrpc.client, csv
from collections import defaultdict

URL, DB, USER, KEY = "https://erp.example.ca", "prod", "svc_recon", "..."

common = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/common")
uid = common.authenticate(DB, USER, KEY, {})
models = xmlrpc.client.ServerProxy(f"{URL}/xmlrpc/2/object")

quants = models.execute_kw(DB, uid, KEY, "stock.quant", "search_read",
    [[["location_id.usage", "=", "internal"]]],
    {"fields": ["product_id", "quantity", "reserved_quantity"]})

odoo_qty = defaultdict(float)
for q in quants:
    odoo_qty[q["product_id"][1]] += q["quantity"] - q["reserved_quantity"]

with open("legacy_available.csv") as fh:
    for row in csv.DictReader(fh):
        drift = odoo_qty.get(row["sku"], 0.0) - float(row["available"])
        if abs(drift) > 0.001:
            print(f"{row['sku']}\tdrift={drift:+.3f}")

Twenty lines, and it runs nightly for six months. Fine. The point is that it exists at all, that someone has to read its output every morning, and that a big-bang rollout does not need it.

Note reserved_quantity in there. Half the drift you will chase during a phased rollout is reservation semantics — the legacy system's idea of "committed" and Odoo's idea of "reserved" are not the same concept, and reconciling on quantity alone will have you hunting ghosts.

What big-bang actually costs you

One weekend, and no rollback worth the name.

The rollback story is where big-bang is genuinely weaker, and I would not let anyone talk past it. Once Monday's transactions are in the new system, going back means either replaying them into the legacy database or losing them. In practice, by Monday afternoon you are committed. That is a real risk and it is not eliminated by good planning, only reduced.

What good planning does eliminate is the reason you would want to roll back. A two-day parallel run — same week's transactions through both systems, outputs reconciled line by line — is what turns cutover weekend from a leap into a rehearsal. Projects that skip it are the ones with rollback conversations.

The honest decision rule

For Canadian companies under about 250 staff, on a single ERP suite, my position is fairly firm:

Phase by site or legal entity. Do not phase by module.

Phasing by site works because each site is a complete system of record for itself — one plant goes live fully on Odoo, the other keeps its legacy stack fully, and the only interface between them is the consolidation you needed anyway. Phasing by module works only when the modules are genuinely decoupled, and inside a single ERP suite they are decoupled by design inside the system and coupled by process outside it.

There is one module-level phase boundary I do think is safe, and it is HR and payroll. Payroll's coupling to the rest of the ERP is one journal entry per run. Deferring it is cheap, and the timing argument in Canada is strong: T4 information returns are due the last day of February, so switching payroll systems in Q1 buys you a filing cycle of grief for no benefit. Take payroll live in July.

Two Canadian wrinkles that change the maths

Multi-province tax makes big-bang more attractive, not less. If you sell into five provinces, your tax determination logic has to be right in one place. Running it in two systems for two quarters, with GST/HST/PST/QST mappings maintained twice, is exactly the kind of duplicated configuration that produces a filing correction. Tax is not a good candidate for a temporary interface.

Version support pressure is real. Odoo maintains only the three most recent major versions, and Odoo 19 shipped in October 2025. A phased rollout that starts on Odoo 19 in early 2026 and finishes in mid-2027 will spend its second half on a version approaching the edge of that window, with an upgrade landing on top of a half-finished implementation. Compressing the timeline is worth something on that basis alone, and it is the argument I would actually make to a CFO. Version-window pressure belongs in the architecture conversation rather than the support contract, and an experienced Odoo implementation team will raise it during scoping instead of in year two. If nobody on your shortlist brings it up, ask why.

Where the budget argument comes back in

Panorama's 2026 ERP Report found more than a quarter of organizations exceeded their project budgets, with additional technology needs the leading cause. Temporary integrations are exactly that: additional technology, procured mid-project, justified as short-term, maintained for years. Every phase boundary is a small chance of a permanent middleware line item.

The checklist

Choose big-bang if most of these are true: single site, or multiple sites on one process model. Under 250 staff. One legacy accounting system rather than three. A slow quarter you can cut over into. Enough internal bandwidth for a two-day parallel run.

Choose phased if: multiple legal entities or genuinely different operating models per site; a site you can treat as a pilot without cross-site inventory movement; or a hard external constraint — an audit, an acquisition, a customer EDI deadline — that fixes one date and lets the rest move.

If you find yourself phasing because the project feels too big to do at once, that is not an architecture reason. That is a resourcing reason, and it is better solved by adding people to the discovery phase than by adding an integration you will still be maintaining in 2028.

Roast loss breaks your bill of materials: how to evaluate an ERP partner for a growing roastery

Mohit — Thu, 20 Aug 2026 09:55:13 +0000

Every ERP demo I have watched a coffee roaster sit through has the same silent failure point. The salesperson builds a bill of materials on screen: 10 kg of green Colombian in, 10 kg of roasted Colombian out. Nobody in the room says anything, because the number looks right.

It isn't. A light roast dropped at first crack loses around 10% of its green weight; push well past second crack and you can lose as much as 25%. Most of that is water — green coffee carries 10–12% moisture — and the rest is organic matter burned off in the drum. The loss is not a constant, it is not a rounding error, and it changes with the roast profile, the ambient humidity and the lot.

That single unmodelled fact is where roastery ERP projects start to rot. Inventory drifts, cost of goods is wrong by a margin that grows with volume, and within six months someone is maintaining a shadow spreadsheet to reconcile what the system says against what is actually on the pallet. So when a roaster asks me what makes a good ERP partner, I don't answer with a list of certifications. I answer with three things to make them do in front of you.

Test one: make them model a yield that changes every batch

Ask the partner to build a roast in a sandbox, then produce it at a different quantity than the one planned. Watch what the system does with the difference.

There are only a few defensible answers, and a good partner will tell you which one they're choosing and why:

Capture actual output at close. The manufacturing order plans 10 kg and you confirm 8.3 kg produced. The variance flows to a shrinkage or yield-loss account rather than sitting as phantom stock. In Odoo terms, this is the gap between product_qty on the manufacturing order and what actually gets recorded as produced — cheap to run, honest, and it gives you a variance report you can chart by roaster, profile and origin.

Model loss explicitly as a by-product. Useful if you want chaff and moisture loss visible as its own line, or if you're allocating loss cost across a blend. More setup, more discipline required from the person closing the order.

Two units of measure on the same product. Green kilos and roasted kilos as separate UoMs with a conversion factor. This is the answer that sounds elegant in a demo and hurts later, because the factor is not fixed. If a partner reaches for this first, they have not run a roastery.

The tell isn't which option they pick. It's whether they ask you for your actual yield history before picking. A partner who wants twelve months of green-in/roasted-out numbers before touching the configuration is doing the job. One who says "we'll handle that with a custom field" is deferring the problem to your accountant.

Test two: ask them to trace one retail bag backwards

Pick a 250 g bag off your own shelf. Ask the partner to show you, in their system, the path from that bag to the specific green lot it came from — through the blend, the roast batch, the packing run and the wholesale order it shipped on.

This is where lot genealogy either exists or doesn't. In Odoo the mechanics are documented and unglamorous: you enable Lots & Serial Numbers in the Inventory settings, switch each product's inventory tracking from quantity to lots, and the manufacturing order then carries a lot number for the finished coffee alongside the component lots it consumed. Blends make it harder, because one finished lot legitimately descends from three or four green lots at once, and a partner who models a blend as a single flattened component has just destroyed the audit trail you'll need.

You will need it. If you sell into the EU, the Deforestation Regulation applies to coffee from 30 December 2026 for large and medium operators and 30 June 2027 for micro and small ones, and compliance means plot-level geolocation data and a due diligence statement reference attached to the goods you place on the market. The practical question for your ERP is whether that data lives as a structured field on the green lot record — inherited automatically by every downstream roast, blend and finished lot — or as a PDF in a shared drive that someone has to go find during an audit.

Ask the partner where the DDS reference number is stored. If they haven't heard of it, they can still learn it. If they wave it away as a compliance detail to sort out later, they will be building you a system that cannot answer the one question a regulator asks.

Test three: hand them your wholesale price book and your subscription list at the same time

A growing roastery is two businesses sharing one warehouse. Wholesale runs on negotiated per-kilo pricing, standing weekly orders, 30-day terms and pallets. Direct-to-consumer runs on retail pricing, recurring subscriptions, grind-on-demand and single bags going out through a Shopify or WooCommerce storefront. The same green coffee feeds both, and the two channels compete for it.

Most demos handle one of these beautifully and fake the other. So give the partner both at once and ask a specific question: when a wholesale account's standing order and Friday's subscription run both need the last 40 kg of the Ethiopian, what does the system do?

Watch also for how they answer the grind question, because it's the decision that quietly shapes your inventory forever. Whole bean, filter grind and espresso grind can be product variants on one template, or three separate SKUs, or a post-pick operation that doesn't touch stock at all. Each choice is defensible; each one changes how you count, forecast and reorder for the next decade. A good partner walks you through the trade-off in plain language and makes you decide. When we're brought in as an Odoo implementation partner on a stalled rollout, that decision is very often the thing that was never actually made — it was configured by default and then worked around.

What the good ones do in week one

They don't configure anything. They map your process — green intake, sample roasting, production roasting, resting, blending, packing, wholesale fulfilment, e-commerce fulfilment — and they find the three places where your current process only works because a specific person remembers something.

They also argue with your requirements list. Panorama Consulting's 2026 ERP Report found more than a quarter of organisations exceeded their project budget, with additional technology needs the leading cause, and pointed at "fatal misfits" discovered late as the pattern behind it. Late discovery is a scoping failure, not a software failure. The partner who tells you in week one that four of your twenty must-haves are actually process problems is saving you the overrun.

The part nobody puts in the pitch deck

A partner who works this way is slower to start and more expensive than one who will just install and hand you the keys. You will spend three or four weeks on discovery that produces no visible software. If you are roasting fifty bags a month, that cost is real and the honest answer may be that a spreadsheet plus your storefront is still the right stack — ERP earns its keep somewhere around the point where two people can no longer hold the whole operation in their heads.

And no ERP will improve your coffee. It will tell you what a batch cost, which origin actually carries your margin, and whether the Kenyan is worth the freight. Those are finance questions, not cupping questions.

If you're evaluating partners now, take three things into the next call: twelve months of green-in and roasted-out weights, your wholesale price book, and one retail bag. Ask them to reconcile the first, price the second, and trace the third. The ones who can't will tell you so in the first twenty minutes, which is exactly what you want from a demo.

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.