When people talk about vendor lock-in, they usually mean contracts. Licensing terms that make it expensive to leave, multi-year commitments, exit fees. Those are real costs. But they're the obvious ones. The costs that do more damage are the ones that accrue invisibly over years.
What You Need to Know
- The most expensive form of lock-in isn't contractual. It's the gradual loss of internal capability to operate without the vendor
- Data portability is a technical problem that becomes a business problem. If you can't export your data in a usable format, you can't leave
- Lock-in compounds: each year of dependency makes switching more expensive, which makes switching less likely, which deepens the dependency
- Strategic flexibility, the ability to change direction when the market changes, is the real casualty
The Three Hidden Costs
Capability atrophy
This is the one that concerns me most. When you outsource a capability to a vendor, your internal team stops practising it. Over three to five years, the institutional knowledge of how that capability works fades. The people who understood it move on. The documentation, if it existed, becomes outdated.
The vendor becomes not just a service provider but a dependency. You're not paying for their product any more. You're paying because you can no longer do without it.
I've seen this happen with CRM platforms, with content management systems, with analytics tools. The organisation chose a vendor to save time and money. Five years later, they're paying more than the internal capability would have cost, and they've lost the ability to switch.
64%
of CIOs say they feel locked in to at least one vendor, limiting their ability to make strategic technology changes
Source: Flexera State of Tech Spend Report, 2022
Data portability
Every vendor says they support data export. Few make it practical. The exported data often comes in proprietary formats, missing relationships between records, or stripped of the metadata that makes it useful. You can get your data out. You just can't do anything with it.
The test is simple: could you export your data today and load it into an alternative system within a month? For most enterprise tools, the honest answer is no. Not because the data is locked behind legal barriers, but because extracting it in a usable form is a project in itself.
I always ask vendors one question during evaluation: "If we want to leave in three years, what does that process look like?" The quality of the answer tells me more about the relationship than any sales pitch.
Isaac Rolfe
Managing Director
Strategic inflexibility
This is the compound effect. Capability atrophy means you can't do it yourself. Data lock-in means you can't easily switch. Together, they mean your technology strategy is constrained by your vendor relationships rather than your business goals.
When the market shifts, when a new opportunity appears, when your business model evolves, your ability to respond is limited by what your vendors support. That's the real cost of lock-in. Not the licensing fees. The lost optionality.
Where Lock-In Hides
The most common lock-in points we see in NZ enterprises:
Cloud platforms. AWS, Azure, and GCP all have proprietary services that are excellent but create dependency. Building on Lambda, Azure Functions, or Cloud Run is efficient until you need to move. The compute is portable. The integrations aren't.
Business platforms. Salesforce, HubSpot, Dynamics. The more you customise, the deeper the lock-in. A vanilla Salesforce instance is portable. One with 200 custom fields, 50 automation workflows, and integrations to six other systems is not.
Content management. Enterprise CMS platforms accumulate years of content, templates, and editorial workflows. Moving to a different CMS means migrating content (straightforward), templates (harder), and workflows (often impossible to replicate exactly).
Analytics and reporting. Dashboards, custom reports, and data transformations built inside a vendor platform are rarely exportable. The data might be, but the intelligence built on top of it isn't.
How We Think About It
We don't tell clients to avoid vendors. That's not practical. Vendors exist because building everything in-house is expensive and slow. The question isn't whether to use vendors, it's how to use them without losing strategic flexibility.
Prefer open standards. When choosing between a proprietary solution and one built on open standards, the open option gives you more exit paths. APIs over custom integrations. Standard data formats over proprietary schemas. Open-source foundations over closed platforms.
Maintain internal knowledge. Even when a vendor manages a capability, keep someone internal who understands how it works. Not to do the work, but to evaluate whether the vendor is still the right choice and to manage a transition if needed.
Negotiate data portability upfront. Make data export, in usable formats, a contractual requirement. Not a vague commitment to "support data portability" but specific formats, timelines, and inclusion of relationships and metadata.
Review annually. Once a year, ask: if this vendor disappeared tomorrow, what would happen? If the answer is "catastrophe," you've got a lock-in problem worth addressing.
Lock-in isn't something that happens to you. It's something you let happen gradually by not paying attention. The good news is that the same gradual approach works in reverse. Small, consistent investments in portability and internal capability compound over time, just like the lock-in does.