Vendor lock-in in ERP: what it costs you and how modular architecture avoids it

Vendor lock-in is the hidden cost of monolithic ERP.

Most ANZ buyers underestimate it at selection time; most discover it at year four.

Here is what vendor lock-in actually costs, and how modular ERP architecture changes the calculus.

What vendor lock-in actually means

Vendor lock-in is the cost of changing vendors after you have committed to one. In ERP specifically, lock-in compounds across five surfaces:

• Data lock-in: your customer, product, transaction, and historical data sits in vendor-specific schemas. Exporting it cleanly is non-trivial.
• Customisation lock-in: code you wrote against the vendor's extensibility framework (SuiteScript, ABAP, AL, custom Python on Odoo) does not port to another vendor.
• Integration lock-in: every connector you built between your ERP and other tools targets the vendor's API surface.
• Process lock-in: your team's muscle memory and your documented procedures are vendor-specific.
• Contractual lock-in: multi-year contracts, early-termination penalties, partner relationships that span multiple vendors.

A monolithic ERP has all five surfaces concentrated. Switching means rebuilding all five.

What ERP lock-in actually costs

The realistic ANZ cost of switching from one monolithic ERP to another:

• Data migration: NZ$15,000–80,000 for SMB; NZ$80,000–400,000 for mid-market
• Re-implementation: NZ$50,000–300,000 for SMB; NZ$200,000–1,500,000 for mid-market
• Customisation rebuild: highly variable; can be 2–5× the implementation cost if there is heavy custom code
• Integration rebuild: NZ$2,000–10,000 per integration, times however many you have
• Training: NZ$500–2,000 per user, times your headcount
• Operational disruption: the harder-to-cost piece; typically 6–18 months of productivity drag

Total realistic switching cost for a 50-user mid-market business is NZ$300,000–1,500,000 over 12–18 months. That cost is the lock-in.

Why monolithic ERPs lock in harder

The architecture choice determines the lock-in depth. Monolithic ERPs lock harder because:

Single database, shared schema. All modules write to one database with shared tables. Inventory writes touch finance writes touch HR writes. Extracting "just the inventory module" without the rest is essentially impossible.

Shared customisation layer. Code customisations written against the monolith's extensibility framework usually depend on multiple module APIs simultaneously. Moving one module out breaks the customisations on others.

Coupled UI. The user interface is one application; users learn one navigation. Splitting that into multiple products forces a UX retrain.

One contract, one renewal. The vendor negotiation covers everything; partial migration is not a renewal option.

The lock-in is architectural, not just commercial. A vendor cannot un-architect a monolith; they can offer discounts, but the structural depth of the lock-in stays.

How modular ERP changes the calculus

Modular ERP separates each functional domain into independently-deployable services with their own data boundaries and APIs. The lock-in shape changes:

• You can replace Inventory without touching Finance
• You can swap CRM modules while keeping Orders and Warehouse
• You can integrate a third-party module alongside your existing modular ERP
• Customisations live against module-specific APIs, so a module swap breaks only that module's customisations
• The contract can be module-by-module renewal rather than all-or-nothing

The lock-in does not disappear (every system has some) but it shrinks from "company-wide six-figure switching cost" to "per-module five-figure switching cost".

The trade-off: modular architectures require more disciplined integration design between modules. Monoliths get integration "for free" via shared database; modulars pay the integration cost upfront. Most modern modular ERPs use event-driven architecture with stable APIs to manage that overhead.

Lock-in by ERP tier in ANZ

The honest map of lock-in depth by ERP category:

Maximum lock-in: Enterprise suites (NetSuite, SAP, Oracle, Dynamics 365):

• Multi-year contracts (typically 3–5 years)
• Heavy custom code (SuiteScript, ABAP, AL)
• Partner-dependent for changes
• Six-figure to seven-figure switching cost

High lock-in: Mid-market suites (MYOB Acumatica, Sage X3, Acumatica):

• 2–3 year contracts via partners
• Moderate custom code
• Partner ecosystem changes hurt
• Mid-five-figure to six-figure switching cost

Medium lock-in: Inventory + light ERP (Cin7 Core, Unleashed, Katana):

• Annual contracts with auto-renewal
• Less custom code (lighter extensibility)
• Standard integrations (Xero / MYOB) port
• Five-figure switching cost

Lower lock-in: Modular ERP (OpsUI, Odoo Community):

• Per-module contracts
• API-driven extensibility, less proprietary code
• Module-by-module swap possible
• Four-figure to low-five-figure per-module switching cost

The lock-in tier is not the same as the cost tier. NetSuite is expensive AND locks you in hard; OpsUI is cheaper AND locks you in less. The two scale together at the enterprise tier and decouple at the modular tier.

What to ask a vendor about lock-in

Questions to surface lock-in depth during evaluation:

1. Data export. Can I export all my data in a structured format (JSON, CSV, SQL) on demand at no cost?

2. Schema documentation. Is the database schema documented publicly?

3. API surface. Is there a documented REST or GraphQL API on every module?

4. Customisation portability. Are customisations written in a proprietary language or in standard SQL / JavaScript / Python?

5. Contract length. Annual? Multi-year? Auto-renewing with notice periods?

6. Early termination. What is the cost of cancelling mid-contract?

7. Module isolation. Can I run only some modules and replace the rest?

8. Partner dependency. Can I switch implementation partners without losing my customisations?

The depth of these answers separates serious modular vendors from monoliths claiming modularity.

How OpsUI handles lock-in

OpsUI is built modular by architectural choice, not as a marketing claim:

• Per-module pricing and contracts. You can cancel any module annually without affecting others.
• REST API on every module. Documented, versioned, available to all customers.
• No proprietary scripting language. Customisations are JavaScript or REST API calls.
• Data export on demand. Full structured export in standard formats; no fee.
• Public schema. Module data models are documented in the OpsUI docs.
• No partner dependency. Direct onboarding by OpsUI; no implementation partner required.

The trade-off is depth: OpsUI does not match NetSuite's 20-year enterprise feature catalogue. But for SMB and lower-mid-market ANZ operators, the lock-in trade-off favours modular by a large margin.

See also

For deeper coverage of vendor lock-in and ERP architecture, see Beyond Xero, Modular vs Monolithic, and the vendor lock-in risks deep dive on the OpsUI knowledge base.