"The contact person at the development agency that built our internal business system a few years ago resigned, and the agency itself became difficult to reach. When we ask for small fixes, their response is slow, and when we try consulting another agency, we have neither the source code nor the specifications on hand. In the end, we just keep paying the expensive maintenance fees they demand." We received this consultation from a company in the wholesale sector. Once a system is built, nobody except that agency can touch the internals, leaving the client powerless to negotiate even price hikes. This state of being tied to a specific vendor and left with no room to maneuver is called vendor lock-in.
The troublesome aspect is that most lock-in is determined not after completion, but by how requirements are pinned down when commissioning the work. What you secure in your contracts and deliverables determines whether you can later hand over the system to another company. In this article, we break down why organizations get locked in, what to establish at the commissioning stage to prevent it, and why lock-in has become particularly prevalent in recent years, all from the client's perspective.
Why do systems end up in a state where only that agency can touch them?
Lock-in does not happen solely through malicious entrapment. In most cases, it arises naturally because proper arrangements were not made at the time of commissioning. It generally stems from three primary causes.
The first is the issue of source code and copyright. Unless specified otherwise in the contract, the general legal principle is that the copyright to developed programs remains with the party that created them. Consequently, the client does not have the legal right to hand over the code to another company for modifications and has no choice but to keep relying on the original agency. The second is the absence of documentation. Without architecture designs or operational procedures, any other company trying to take over must begin by deciphering the system from scratch, which causes quotes to skyrocket or leads them to decline the project altogether. The third is proprietary architectures that only that agency can handle. When built using custom, proprietary frameworks unique to that agency rather than widely adopted technologies, the pool of engineers capable of maintaining it is severely limited, effectively rendering them your exclusive provider. When these three overlap, the cost of switching to another company becomes prohibitively high, making escape virtually impossible.
What to establish in contracts and specs before commissioning
The greatest opportunity to prevent lock-in is before signing the contract. Demanding the source code after development is finished will lead to difficult negotiations if it was not written into the agreement. Simply formalizing the following points during the commissioning phase will dramatically safeguard your future options.
| Checkpoint | What to confirm and specify when commissioning |
|---|---|
| Copyright and usage rights | Specify either the assignment of copyright for deliverables to your company, or broad usage rights allowing free modification and migration |
| Source code delivery | Include the complete source code package in the deliverables, not just the compiled product |
| Documentation | Designate specification documents, operational procedures, and environment configurations as deliverables |
| Technologies used | Require development using widely adopted technologies rather than vendor-proprietary frameworks |
| Data portability | Condition the contract on the ability to export accumulated data in standard formats |
Particularly effective are the treatment of copyright and the delivery of source code. If you include these in the contract, you can take the code and rights to another agency even if your relationship with the original developer is severed. We have compiled guidance on organizing requirements and gathering quotes prior to ordering in our article on custom software development RFPs and costs, so please review that as well. Conversely, if an agency's contract lacks these clauses and they simply offer verbal assurances like "don't worry, it's fine," that alone is sufficient reason to withhold the order.
At a small manufacturing company that GleamHub assisted with vendor procurement, the initial quote completely omitted any mention of deliverable copyrights or handover assets. Left unchanged, they would have headed straight into the lock-in scenario described earlier. Before signing, we had them add two clauses: "including the complete source code and design specifications as deliverables" and "granting usage rights to freely modify and migrate deliverables." While the development fee increased by a few tens of thousands of yen, when they later wanted to switch maintenance to a different provider, they were able to obtain quotes simply by handing over the code and specifications, making the transition seamless. A minimal amount of upfront effort completely protected their bargaining power years down the road.
Why AI-built systems are actually easier to get locked into
In recent years, a new catalyst has been added to this problem: the widespread adoption of development using generative AI. While having AI write the bulk of the code to deliver in a short timeframe is appealing in terms of cost and turnaround, from a client's perspective, it has the side effect of actually increasing lock-in risks.
There are two reasons for this. First, with massive amounts of AI-generated code, sometimes even the person who prompted it cannot explain the intricate details, and projects tend to be delivered without accompanying documentation. When bugs emerge months later, nobody grasps the overarching picture. Second, while AI-generated code may run, it frequently harbors "invisible debt" with poorly structured internals, making modifications progressively harder over time. This phenomenon of "AI-written code deteriorating after six months" is covered in detail in our article on AI-generated code rot. Behind the marketing pitch of building cheaply and quickly, is handover documentation or structural clarity being cut? Clients are now in a position where they must verify more rigorously than ever whether deliverables include not just running code, but a state that another company can read and take over.
How to break free if you are already locked in
Even if you think, "We already built it, and our contract specifies none of this," there are still steps you can take. The key is not trying to migrate everything at once.
The first thing to tackle is securing your accumulated data. If your daily business data can be extracted in standard formats, your operational records remain protected even if you eventually rebuild the system core itself. Approaches for migrating data safely are summarized in our article on business system data migration. Next, rather than replacing the current system entirely, migrate functionality step-by-step to alternative mechanisms. By transitioning incrementally while keeping the system in use, you can break free from lock-in without halting business operations. Rushing into a wholesale replacement carries the risk of getting locked into a new vendor in the exact same manner, so it is vital to ensure the contractual clauses covered in this article are included in your next engagement.
Behind the promise of "cheap and fast": Is the system truly handover-ready?
What you should truly evaluate when commissioning system development is not just immediate costs and delivery deadlines. If that development agency disappears, can you take the code, data, and documentation to hand the system over to another company? Securing this single point before commissioning completely transforms your organizational freedom years later. Especially now, with the rise of proposals pitching rapid builds via generative AI, it is well worth verifying whether maintainability has been traded away for speed.
Whether you want someone to review your upcoming contract to ensure source code and copyright terms are included, want to discuss an exit path from a system locked into a specific vendor, or need to assess whether a proposal to build cheaply with AI presents long-term risks, feel free to reach out via GleamHub's development, AI, and automation consultation. We will help you structure your project from both contractual and architectural standpoints so your business remains completely unconstrained.
Sources
- Vendor's Obligation to Provide Source Code in Software Development Entrustment Contracts | Uchida & Samejima Law Firm
- What Is Vendor Lock-In? Countermeasures and Case Studies for Breaking Free | Monstarlab Inc.
- What Is Vendor Lock-In? An In-Depth Explanation of Concepts, Causes, and Avoidance Strategies | IT Procurement Navi
