Reid Jackson, Unison, CEO
Switching Costs Are the Real Lock-In
Vendor lock-in doesn’t necessarily start with a poor purchase. It can start with success, too. A system works. People embrace it. Integrations spread. But when pressure builds and security rules tighten, missions evolve, or teams are asked to do more with less, what once felt reliable becomes a limitation. The cost of switching is too high. So, progress stalls.
While lock-in is tough to avoid, it can be understood and managed. The key is to focus on switching costs, because lock-in is just another name for when those costs become too high to bear.
Lock-In Happens When Systems Outlast Their Options
Path dependency refers to how past decisions shape current options. Once a choice is made, especially one that requires time, money, or coordination to implement, future alternatives narrow; not because the options are poor, but rather because the cost of changing direction becomes too high.
Defense programs illustrate this issue. Tooling, training, and supply chains render a fighter jet platform nearly impossible to replace mid-process. Enterprise software involves lighter materials but carries similar significance: data models, workflows, custom reports, and connections to several systems. Replace one component, and you tug on the rest.
In federal acquisitions, when software is selected, implemented, and adopted, processes are built around it. Support teams form. Training materials are created. The longer it’s used, the more dependent the agency becomes on that path.
But if the system fails to be flexible at a turning point, it hinders progress. When the agency realizes it needs something new, it assesses the costs of re-acquiring, re-deploying, and re-training, leading to a sense of being trapped with its current vendor.
Common Myths That Lead to Expensive Mistakes
Myth: Custom-Built Software Eliminates Vendor Lock
Some agencies avoid commercial products altogether, opting instead to build systems in-house. They believe that owning the IP ensures independence and overcomes path dependency. But really, they’re just manifesting internal lock-in. As Yogi Berra once said, “Wherever you go, that’s where you are.” Agencies that go with custom-built software find themselves deeply locked into their solution. They can change the people or contractors who support and evolve the system, but adaptability is compromised when only a few individuals grasp how the system functions or when support relies on irreplaceable institutional knowledge.
You might be wondering: Isn’t it at least better for an agency to be locked into itself than to depend on a vendor? Not at all. With a vendor, the agency has some leverage. However, with their agency’s IT department, they have none. This is why most agency CIOs have stepped away from hosting systems. System sponsors have discovered they can obtain secure, scalable hosting solutions from the market far more cost-effectively and efficiently than through the agency’s internal hosting team.
Myth: Low-Code Platforms Provide Easy Switching
Low-code platforms are frequently promoted as a quicker, more adaptable alternative. They claim to result in less dependency on developers and simpler updates via drag-and-drop interfaces. However, this flexibility is superficial. Beneath the surface, these platforms are closely tied to proprietary runtimes and closed architectures.
Agencies may define the application logic, but they don’t control the environment on which it relies. If the platform falls behind on security, alters its roadmap, or fails to meet evolving federal standards, there is little room for maneuvering. Replacing it often necessitates a complete rebuild, undermining the flexibility that initially made the platform appealing. Custom components, embedded scripts, and platform-specific logic add up quickly. Over time, the promise of agility yields to hardwired dependencies that are challenging and costly to unravel.
Practical Ways to Stay in Control
Don’t make the goal to avoid lock-in. Make it to achieve a flexible commitment.
Here’s how:
- Assess Switching Costs Early: During the initial procurement, assess the implications of abandoning the solution. Account for retraining, data migration, and reintegration costs in your total cost of ownership (TCO) analysis.
- Require Open Data and APIs: Ensure that contracts require comprehensive access to data via open APIs and straightforward data export options. Maintaining data accessibility lowers reliance on any single vendor.
- Emphasize Configuration Over Customization: Prioritize solutions that enable configuration changes through built-in tools instead of modifying core software code. Configurable systems retain flexibility without restricting future options.
- Prioritize Federal Security and Performance Standards: Choose platforms that meet current federal security requirements (FedRAMP, zero-trust architecture, 508 compliance, and role-based access controls) and ensure compliance as these standards evolve. Security gaps often lead to urgent, costly replacements that force agencies into hasty decisions with limited options.
Progress Demands Calculated Commitments
In every aspect of life—whether it's mortgages, jobs, or relationships—switching costs are a reality. Attempting to eliminate them entirely means missing out on long-term value.
The same holds true for federal acquisitions. Agencies that try to avoid lock-in delay progress. Those who plan for it stay ready to adapt when the mission changes. That means understanding switching costs from the start, building with flexibility in mind, and working with vendors who support adaptability, not those who punish it.
With procurement teams facing more work with fewer resources, managing lock-in becomes essential. The path to smarter acquisitions begins with commitments that can flex under pressure.
