The Lock-In Reality#
ERP vendors are not neutral parties. Their business models benefit from customer lock-in. Understanding lock-in mechanisms is essential for negotiating favourable terms and preserving future options.
Forms of Lock-In#
Data Lock-In#
Your data is in the vendor's proprietary format.
Symptoms: - Data export is difficult or expensive - Data format is poorly documented - Historical data cannot be easily extracted - Data portability is not guaranteed in contract
Customisation Lock-In#
Customisations bind you to the specific implementation.
Symptoms: - Customisations are not documented - Customisations depend on specific vendor resources - Customisations are not portable to other instances - Vendor claims ownership of customisations
Integration Lock-In#
Your ecosystem is built around the ERP.
Symptoms: - All systems integrate through ERP-specific APIs - Integration expertise is vendor-specific - Integration middleware is vendor-proprietary - Changing ERP requires re-implementing all integrations
Knowledge Lock-In#
Your organisation has lost the ability to operate without the vendor.
Symptoms: - Internal expertise has departed - Processes are not documented independently - Vendor provides critical ongoing support - Switching would require rebuilding internal capability
Contractual Lock-In#
Contract terms make leaving expensive.
Symptoms: - Long contract terms with auto-renewal - Termination penalties - Data extraction fees - Transition support not guaranteed
Lock-In Risk Assessment#
Evaluate your lock-in risk across these dimensions:
| Dimension | Low Risk | Medium Risk | High Risk |
|---|---|---|---|
| Data export | Standard formats, documented APIs | Export possible but complex | No clear export path |
| Customisation | Configuration only | Documented extensions | Undocumented modifications |
| Integration | Standard protocols | Some vendor-specific | Entirely vendor-specific |
| Knowledge | Strong internal team | Some internal expertise | Dependent on vendor |
| Contract | Short term, portable data | Medium term, some penalties | Long term, high exit costs |
Mitigation Strategies#
Data Portability#
- Negotiate data export rights in contract
- Require documented data schemas
- Test data export before committing
- Maintain independent data backup
Customisation Discipline#
- Prefer configuration over customisation
- Document all customisations thoroughly
- Ensure customisation code is owned by you
- Review customisation necessity rigorously
Integration Independence#
- Use standard integration protocols where possible
- Consider middleware that abstracts ERP specifics
- Document integration architecture independently
- Plan for integration portability
Knowledge Retention#
- Maintain internal expertise alongside vendor support
- Document processes independently of vendor
- Cross-train to avoid single points of failure
- Periodically assess internal capability
Contract Negotiation#
- Negotiate reasonable contract terms
- Include data portability provisions
- Limit auto-renewal
- Define transition support obligations
The Exit Strategy#
Every ERP relationship should have an exit strategy, even if you never use it.
Data extraction: How would you extract all data?
Migration path: What would migration to an alternative look like?
Contract termination: What are the notice periods and penalties?
Transition support: What support would be available during transition?
NZ/AU Considerations#
Vendor presence: Lower local presence may affect transition support.
Partner dependency: If partner holds customisations, what happens if relationship ends?
Data residency: Ensure data can be extracted to locations you choose.
Conclusion: Preserve Optionality#
Lock-in is not inherently wrong—deep vendor relationships can provide significant value. But lock-in should be a conscious choice with understood trade-offs, not an accidental outcome of poor planning.