Where the boundary belongs
Keep the ERP as the system of record for the things that should be standard: finance, statutory reporting, and the inventory or manufacturing processes it was built for. Put the differentiated operation — the part customers actually choose you for — in a system that can change without a customization cycle, and connect the two through APIs and events rather than duplicated master data.
The process does not disappear, it relocates
When a differentiated process is forced into a standard module, it does not go away. It moves into spreadsheets, email and a side tool, and the ERP quietly stops describing what the company does. Reconciling the two versions then becomes somebody's permanent job, and the ERP's reports become the ones nobody quite trusts.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
Data is exported so the real process can run
The ERP holds the record and a spreadsheet runs the work. That export is a system boundary, drawn by accident rather than by design.
-
A real change is a project
Fields, layouts and simple rules are often admin-editable now, and some ERPs draft a rule from a plain description. A new object, a cross-module rule or a customer-facing step still needs a partner, a quote and a release window, so changes get batched and the operation waits.
-
The customer-facing step does not fit
The screen your client or field team needs is not a screen the ERP was designed to produce, so somebody rebuilds it elsewhere.
-
Identifiers are reconciled by hand
The ERP's customer number and the operational tool's customer ID are matched by a person, or by a lookup that breaks whenever a name changes.
-
The upgrade is feared
Every customization is something that might break, so upgrades get deferred, which makes the next upgrade larger and more frightening.
Two ways to close the gap
Both options keep the ERP. They differ in where the differentiated process lives and who is able to change it.
| What you are deciding | Extend the ERP The process moves into the module | Build around it The process gets its own system |
|---|---|---|
| Who makes a change | An admin for fields, layouts and simple flows; a consultant or module specialist beyond that | The person who owns the operation, working in Development |
| How a change ships | Through a customization cycle and a release window | As one reviewed change set, published to Production with version restore (Pro) |
| What happens at upgrade | Customizations are re-tested against the vendor's release | The operational system versions on its own schedule |
| Where finance lives | In the ERP, authoritatively | In the ERP — it is not moved |
| Where the differentiated process lives | In configuration, extensions, or a spreadsheet beside it | In the operational system, as first-class data and workflow |
| How external participants get in | Through the ERP's own portal where it ships one, otherwise a separate product | External Portals on Pro, with no Portal-count or external-user seat limit |
| Where it stops | When the process is the thing you compete on | When the requirement is statutory and the vendor's compliance is the product |
Descriptions of ERP behavior here are deliberately qualitative. Specific vendor limits vary by product and version and are not asserted on this page.
How to evaluate it
Five steps, in order. Each one produces something you can put in front of other people rather than an opinion you have to defend.
- 01
Assign a system of record per object
Customer, order, invoice, item, shipment — one owner each, written down. Most integration pain comes from two systems both believing they own the same object.
- 02
Leave accounting and compliance where they are strongest
If a regulator or an auditor depends on it, moving it is the expensive kind of ambitious. The ERP earns its place there.
- 03
Integrate with events, not copies
Duplicated master data is the thing you will still be reconciling in three years. Every copy is a promise to keep two systems in agreement forever.
- 04
Measure the exceptions
The happy path fits the ERP by definition. Count the manual interventions per week — that number is the actual size of the gap you are deciding about.
- 05
Check who is allowed to change what
If every change needs the ERP partner, the operational layer has to live somewhere your own team can safely work, or nothing improves.
Where this leaves Bondi
Where Bondi fits
Bondi runs the differentiated operational layer and integrates with the ERP for the authoritative transactions. It reads and writes through typed actions and triggers, keeps its own dedicated PostgreSQL database, and publishes changes from Development to Production with version history and version restore on Pro.
- A dedicated PostgreSQL database per environment, separate from the ERP's
- Typed actions and triggers for integration — Bondi does not offer a general two-way sync
- External Portals, record- and field-level permissions and Development → Production publishing on Pro
The other half of the answer
When Bondi is the wrong answer
- The process should be standard, and the ERP's version of it is fine
- The requirement is statutory, and the vendor's compliance is what you are buying
- You would be duplicating master data rather than drawing a boundary
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Is Bondi an ERP?
No. Bondi can run ERP-like operational systems, but it does not ship an industry's standard modules, statutory reports or an accounting engine. It is a platform for the system that is specific to you.
Do we have to migrate the ERP database?
Usually not, and usually you should not. Start by drawing ownership boundaries and integrating; move only the data Bondi has to own in order to run the workflow.
What if the ERP itself is what has to go?
That is a modernization project rather than an integration. It is scoped and quoted separately from the subscription, and it starts with an assessment rather than a build.
How do the two stay in agreement?
Through typed actions and triggers against the ERP's API, with one system of record per object. Bondi does not offer a general two-way sync — and duplicating master data is what creates the reconciliation problem in the first place.
Sources
- NIST SP 1500-10r1 — Adoption and Modernization checked 2026-08-03
- Priority Software — ERP for small businesses checked 2026-09-25
- Priority Software — aiERP (business rules and workflows from a plain description) checked 2026-09-25
- Odoo — Pricing FAQ (Studio by plan; free portal users) checked 2026-09-25
Claims about third-party products are limited to what these documents state on the date shown. Where a document is silent, this guide describes the product's design center rather than asserting a limit.