Vendor Lock-In

Vendor lock-in occurs when an organization's systems are architected in ways that make switching vendors impractical without significant cost and disruption. Technical lock-in happens through proprietary data formats, vendor-specific APIs, and platform-native services with no portable equivalent. Contractual lock-in happens through long-term commitments, termination penalties, and data export restrictions buried in enterprise agreements. Operational lock-in happens when the vendor's consultants are the only people who understand how the system works — because the organization's own engineers were excluded from the implementation.

The most expensive forms of vendor lock-in in enterprise technology are core banking platforms (where the cost of migration exceeds the lifetime cost of staying), ERP systems (where customization has made the standard product unrecognizable and unmovable), proprietary cloud services (where workloads that use AWS-specific or Azure-specific services cannot be migrated without rebuilding), and system integrator consulting programs (where the SI has deliberately designed systems to require ongoing SI involvement). In healthcare, Epic dominance represents a form of market-level lock-in — the switching cost for a large health system to replace Epic is so high that it rarely happens.

Lock-in is not always the result of malicious vendor behavior — sometimes it is the result of technical decisions made by the client organization's own architects. Choosing a vendor-specific database service over a portable alternative, building business logic in a cloud provider's proprietary serverless platform, or adopting a low-code platform that stores logic in a proprietary format are all lock-in decisions. The architecture choices made in the early phases of a system's life determine the lock-in profile for the next decade.

We architect systems to minimize lock-in by default — using portable open standards where vendor-specific services offer no decisive advantage, documenting all vendor dependencies explicitly, and designing data models and APIs that are exportable without vendor cooperation. For clients experiencing existing lock-in, we execute vendor exit programs that extract and re-platform data and logic on vendor-neutral infrastructure. We have inherited locked-in systems from every major enterprise vendor and built the migration path out.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.