Almost every Odoo implementation arrives with a list attached: the bank, the online store, the payment gateway, a warehouse scanning app, a legacy system nobody wants to touch. The list looks like a checklist. In practice it is where a large share of the implementation budget goes, and where go-live dates quietly slip.
Integration work is rarely hard because the technology is exotic. It is hard because two systems that were designed separately disagree about what a customer is, what a price is, and when a transaction is final. Reconciling that is analysis work, not plumbing.
First question: does the other system need to survive?
Before scoping any connector, ask whether the system on the other end still needs to exist after go-live. Odoo covers a wide functional surface. A standalone quoting tool, a spreadsheet-based stock count, a separate CRM used by three people: these are often better retired than integrated. Every system you keep is a permanent link to maintain, retest on every version upgrade, and explain to every new hire.
Keep the system when it does something Odoo genuinely does not, when a bank or a regulator owns it, or when the cost of moving its history outweighs the cost of maintaining a connection. Retire it otherwise. This one decision usually removes more work from an integration backlog than any technical optimization.
Decide which side owns each record
The most common source of integration pain is unclear ownership. If both Odoo and an online store can edit a product price, you will eventually get a support ticket about a price that "changed back on its own." Ownership has to be settled field by field, not system by system.
A workable pattern is to name one system the master for each entity and make the other side read-only for the fields that master owns. Products and prices might be mastered in Odoo, while the storefront masters customer accounts and web orders. Write this down before anyone opens an editor. An ownership table with three columns, entity, master system, and synced fields, prevents more defects than any amount of careful coding afterward.
Three shapes of integration, three different costs
- Scheduled one-way export. One system produces, the other consumes, on a timer. Cheapest to build and to debug, because you can always rerun yesterday's file. Good for reporting feeds, payroll journals, and price lists.
- Two-way synchronization. Both sides change data and both sides must converge. This is where conflict rules, timestamps, and duplicate detection appear. Expect it to cost several times a one-way feed, and expect it to need ongoing attention.
- Real-time calls. Odoo asks another system for an answer while a user waits, or the reverse. Fast and clean when it works, but it couples your uptime to someone else's. Every real-time call needs a defined behavior for when the other end is slow or down.
Choosing the cheapest shape that meets the actual business need is the single largest cost lever in integration scoping. Teams often specify real-time synchronization for data that would be perfectly fine arriving every hour.
Plan the failure path, not the happy path
Demos always run on the happy path. Production does not. Before a connector goes live, three questions should have written answers. What happens when a message fails? Who sees the failure, and in which screen? Can the same message be safely sent twice without creating a duplicate invoice or a double stock move?
That last property, idempotency, is worth insisting on. Retries are inevitable, and a connector that cannot be retried safely turns every network blip into a manual cleanup. Equally important is that someone in operations, not only the implementation partner, is named as the person who checks the error queue.
Sequence by what blocks the business
Not every integration is needed on day one. Connect first what stops invoicing, shipping, or paying people if it is missing. Statutory e-invoicing usually sits at the top of that list, and it is worth being precise about how it is delivered: e-invoicing for markets such as Saudi Arabia, Egypt, and the UAE is handled by Odoo's official localization modules rather than by a custom connector, so it belongs in your configuration plan rather than your development backlog.
Everything else can be phased. A reporting feed or a marketing tool can wait a month after go-live, and waiting often improves the design, because by then you know how the data actually looks in production rather than how it looked in the workshop.
Build, connector, or middleware
Three options exist, and the honest answer depends on volume and change frequency. An existing Odoo connector is the right default when one is maintained and matches your version. Custom development wins when the process is specific to your business or the counterpart system has no usable connector. Middleware earns its license fee only when you have many systems talking to many systems, not when you have two.
Whichever route you take, budget for the second year. Integrations are not finished at go-live; they are maintained through version upgrades, API deprecations, and business changes. When integration work does need real code, it should be scoped, specified, and tested like any other development, which is how we approach custom development engagements.
The teams that do this well are not the ones with the most connectors. They are the ones who retired three systems, agreed ownership on paper, and shipped the four links the business could not run without.