Skip to content
1961 Digital TransformX
العربية

Service

Odoo you can still upgrade in three years

Odoo is cheap to change and expensive to have changed badly. We configure to the standard wherever the standard will do the job, and write the exceptions as proper modules, so next year's version is an upgrade rather than a rebuild.

Book a consultationAll services

You will recognise this

  • You are running a version several releases behind, and nobody in the building can list what an upgrade would break.

  • Somebody added fields in Studio for two years, and the same quantity now exists under three different names on three screens.

  • Core files were edited directly to make one report work, so every patch has to be reapplied by hand afterwards.

  • Half your apps came from the store, one of them has not been maintained since a release you can no longer name.

  • E-invoicing was bolted on after go-live by a separate supplier, and it reads the invoice rather than being part of it.

How the work runs

  1. Test against the standard

    Before designing anything we build your real scenarios in a clean database using nothing but standard Odoo. Most requirements turn out to be met already, or met by a routing, a rule or an operation type nobody had configured. What survives that test is a genuine difference and worth paying for.

  2. Design the exceptions

    The differences that survive are specified as modules with their own data model, tests and upgrade path. We do not edit core and we do not carry logic in Studio fields that no version control can see. Each module names the standard behaviour it extends and why the standard did not fit.

  3. Build operations and quality

    Manufacturing orders, work centres, routings, lots and serials, and quality checks placed at the points where a defect is actually detectable rather than where the paperwork prefers. Inventory is configured around what the storekeeper can know at the moment of receipt, not around what the report wants later.

  4. Localise the accounting

    Chart of accounts, tax treatment, VAT returns and e-invoicing built as part of the ledger rather than as a document produced beside it. Arabic and English on the same records, with printed documents that read correctly in both directions and reports that foot in either language.

  5. Migrate and prove the upgrade

    Moving from a legacy system or an older self-hosted Odoo runs as a rehearsed migration onto a staging database first, with balances reconciled and every custom module exercised against the new version. You see the upgrade succeed on a copy before it is allowed anywhere near production.

What you are handed

  • A configured production database with staging alongside it
  • Custom modules with source, tests and readable commit history
  • Localised chart of accounts, tax codes and VAT mapping
  • Quality control points mapped to real inspection stages
  • Documented upgrade path with the modules to retest
  • Bilingual user guides by role, with printed document templates

Why the standard is worth defending

Odoo makes customisation easy, which is why so many installations become impossible to upgrade. Every field added without a reason, every core file edited to save an afternoon, is a debt the next version calls in. Three years later the company is running on a release that no longer receives fixes, paying for a specialist to keep it alive, and quoting a rebuild to move. We spend the first weeks proving how much of your requirement standard Odoo already covers, because every requirement we retire that way is one you never pay to maintain.

Manufacturing is where the design is decided

A trading company can survive a mediocre configuration. A factory cannot. Bills of material, routings, work centre capacity and the point at which a lot number is assigned determine whether the stock figure is real or a monthly guess corrected by a physical count. The same is true of quality: a check placed at the wrong operation is paperwork, because the defect it looks for is no longer visible at that stage. We design these against how your line actually runs, including the shift where a supervisor records output from memory at the end of the day.

Localisation is part of the ledger

VAT and e-invoicing are frequently treated as an output problem, solved by a separate tool that reads finished invoices and submits them. That arrangement holds until a credit note, a partially exempt supply or a correction after submission, at which point the two systems disagree and somebody reconciles them by hand every month. Tax treatment belongs on the transaction, decided when the document is created and visible on the accounting entry it produces. Built that way, the return is a report rather than a project, and the audit trail runs from the submission back to the delivery note.

Questions we get asked

Are you an Odoo partner or reseller?
No. We do not resell licences and we earn nothing from the subscription you buy, whoever you buy it from. That is deliberate: it means we can tell you that Odoo is the wrong fit for a requirement, or that you need fewer users than you were sold. We work on Odoo because it suits a large share of manufacturing and distribution work in this region, not because of a commercial arrangement.
Should we use Community or Enterprise?
It depends on which apps your process actually needs, and the honest answer usually only arrives after the requirements are tested against a clean database. Some clients need one or two Enterprise apps and would waste money on the rest. Others need none. We put the comparison in writing with the specific features you would be paying for, and you buy the licence directly, not through us.
Will customisation stop us from upgrading?
Badly written customisation will. Written properly it does not: a module that extends standard behaviour through the documented interfaces is retested and moved forward with each release. What kills an upgrade is edited core code, logic hidden in interface configuration, and unmaintained third-party apps. We keep every change in version control with tests, so the upgrade question has an answer instead of a room full of guesses.
We are stuck on an old self-hosted version. What now?
First we establish what is actually running, which usually differs from what the documentation says. Every customisation is inventoried and classified as still needed, replaceable by standard behaviour, or dead. Most old databases carry a great deal of dead weight. The migration is then rehearsed on a staging copy until it completes cleanly and the balances reconcile, and only then scheduled against production.
Who owns the code you write for us?
You do, and you receive it as a repository you control, with the tests and the documentation. We do not hold a licence key over your business or keep a module on our own infrastructure. If you decide to work with another firm, everything needed to continue is already in your hands. A client who cannot leave is a client we have failed, and that applies to code as much as to knowledge.

Often bought together

Tell us what is not working

Send one line about what is going wrong. On the first call we will tell you whether it is a system problem, a process problem or a governance problem — and which one to fix first. That call is free and it is not a sales meeting.

Book a consultation