Vendor lock-in occurs when dependence on a vendor, language, framework, or platform makes change difficult, impractical, or expensive. Avoiding it preserves future options, much like an insurance policy: the extra cost may protect the organization from greater disruption later. section 8.1
The trade-off is rarely binary. A platform may accelerate delivery while creating dependence on its ecosystem, proprietary services, licensing model, or operating conditions. The right choice depends on whether the organization can absorb future price increases, downtime, degraded performance, or migration work. section 8.1 section 8.2.3
Before committing to a technology, ask:
- Can the code, data, or configuration be lifted and run on another platform without a full rewrite? section 8.2.3
- What happens if licensing costs rise, the vendor experiences downtime, or performance degrades? section 8.1 section 8.2.3
- Does the additional cost of portability function as a justified safeguard against greater future disruption? section 8.1
When an administration tool becomes unusable
A storage administration system was neglected through years of upgrades and eventually depended on obsolete Flash software. Administrators had to find an old, isolated laptop to regain access before upgrading the console to HTML5. The incident illustrates how an apparently small technology decision can remove practical recourse. section 8.1
Portability through abstraction
Java separates application code from underlying hardware and operating systems through the JVM. Multiple JVM and deployment choices can support the same code, reducing dependence on one operating system, provider, or runtime implementation. section 8.1
The gray area of platforms
Salesforce illustrates the ambiguity between buying and building: its prebuilt ecosystem may satisfy organizational needs, while its development environment can also create substantial platform dependence. Portability should therefore be tested before major customization. section 8.2.3
