Avoiding Lock-In to a Development Vendor or Platform: The Risks to Assess Before You Sign

“We want another company to maintain the system, but the original vendor says they can’t give us the source code.” “The engineer opened the hosting account with his own email, and since he left we can’t reach him.” “Ten years of customer data sits in the system, and the export is a single file nobody can read.” These are classic cases of being locked in to a development vendor or platform, and they are almost always discovered at the moment you want to leave.

Vendor lock-in does not necessarily come from bad intent. Often it is simply that, to hit a launch date or for convenience, accounts were opened in the vendor’s name, nobody agreed on delivery of the source code, and nobody asked for documentation. Over time, every critical part of the system ends up out of your hands, and the cost of switching becomes so high that you have no choice but to keep going.

This article is about assessing the risk in advance: seeing clearly, before you sign or choose a platform, where you might end up tied down. If you are already changing vendors and dealing with an actual handover, go straight to Source Code Ownership and Project Handover. What follows covers, in order, how lock-in forms, source code and accounts, ownership of cloud and third-party services, proprietary technology and data export, documentation, and exit terms.

How lock-in forms

First, the concept: vendor lock-in means the cost of switching vendors is unreasonably high, to the point that you lose bargaining power over price, service quality, and direction. It usually comes from several sources stacked together:

• Ownership lock-in: the source code, accounts, and domain are not in your name, so you have no legal or technical control.
• Technical lock-in: the system uses a vendor’s proprietary framework or a platform’s exclusive features, so nobody else can take it over or move it.
• Data lock-in: the data lives in someone else’s system and cannot be exported, or the export comes in a format that cannot be used anywhere else.
• Knowledge lock-in: how the system works, how it is deployed, and what exceptions it handles exist only in the heads of the original vendor’s engineers.
• Contract lock-in: the contract has no exit terms, or leaving carries an undefined cost.

These forms of lock-in often exist at the same time. None of them looks serious on its own, but stacked together they make “let’s try another vendor” an impossible option.

Source code and accounts: the most basic, and the most common trouble

Source code

For a custom-built system, the source code is your most important asset. Before signing, confirm:

• Ownership or usage rights. The contract should state clearly who holds the rights to the source code. Even if the vendor keeps the rights to some generic components, the client should receive a license sufficient to maintain and modify the system itself and to have a third party maintain it.
• Delivery method and frequency. Do not wait until the project closes. A better arrangement is to keep the source code in a repository in the company’s name, with the vendor developing as a collaborator, so every day’s progress is in your hands.
• Open-source component licenses. The open-source packages used in the system each come with their own license terms, which may affect how you can use it later. For details, see Open-Source Licensing Basics.

Accounts

Accounts are even easier to overlook than source code, and harder to fix afterward. There is only one principle: every account is opened with a company email address in the company’s name, and the vendor only gets collaborator access. The accounts to take stock of include:

• Domain registration and DNS management accounts
• Cloud hosting or virtual hosting accounts
• App store developer accounts and signing certificates
• Code repository accounts
• Email delivery, SMS, and push notification service accounts
• Accounts for integrated services such as payments, logistics, and e-invoicing
• Analytics, ad tracking, and search engine webmaster tools

Every account should have at least two administrators inside the company, so that one person leaving does not mean losing control.

Cloud and third-party services: whoever gets the bill owns it

Modern systems rely heavily on cloud and third-party services. The lock-in risk here has two layers.

The first layer is ownership. If the cloud server was opened under the vendor’s account and the vendor pays the bill and invoices you for it, then technically that server belongs to the vendor. When the relationship ends, moving it is not just a technical question; it depends on whether the other side cooperates. For choosing and managing a cloud hosting plan, see Cloud Hosting Options for SMBs.

The second layer is dependence on proprietary features. Every cloud platform offers convenient services of its own, and using them speeds up development, but they have to be rewritten if you move to another platform. That does not mean you cannot use them; it means choosing consciously:

• For general needs (servers, databases, file storage), prefer services that have common substitutes.
• When a proprietary service is genuinely needed, design it behind a layer of interface so that replacing it later means changing one place.
• List in the technical documentation which proprietary services the system depends on, so there is a basis for evaluating a future move.

Proprietary technology and data export

Proprietary frameworks and platforms

Some development vendors use frameworks or admin systems they built themselves to speed up development. That helps efficiency, but it also means only they really understand it later on. When evaluating, ask:

• Does the framework have public documentation? Can other engineers get up to speed in a reasonable time?
• After the contract ends, can the client keep using the framework? Is a separate license needed?
• Is the system built with languages and frameworks common in the industry, or does it depend heavily on the vendor’s own tools?

The same questions apply to low-code platforms and SaaS. They let you build things quickly, but process settings, automation rules, and data structures are often tied to the platform. For those trade-offs, see the Low-Code and No-Code Platforms Guide and Build or Buy: SaaS or Custom Software.

Data export

Data is the hardest thing to rebuild. Before signing or choosing a platform, confirm specifically:

1. Can it be exported in full? All fields, attachments, history, and relationships, not just a simplified list.
2. Is the format common? For example, spreadsheet formats, a standard data interchange format, or a database backup, rather than a proprietary format only the original system can read.
3. Who can run the export? Can the client export at any time on its own, or does it have to ask the vendor?
4. Can the export be restored? Ideally, test it once: load the exported data into another environment and confirm it can be read and used, with relationships intact.
5. What happens to the data when the contract ends? How long the other side keeps it, when it is deleted, and whether you get one last full export before deletion.

Regular data exports are also part of a backup strategy, so plan them together with Website Backup and Disaster Recovery.

Documentation: moving knowledge out of people’s heads and onto paper

Knowledge lock-in is the most hidden kind, because it never appears in a contract or an account list. Whether someone else can take over a system depends largely on whether these documents exist:

• System architecture: what parts the system is made of, how they communicate, and which external services it uses.
• Build and deployment instructions: how to build a working system from the source code and how to deploy it to production. See Environments and Deployment Explained.
• Environment configuration list: where each setting and key is stored and who manages it (record only the location and the person responsible in the document, never the keys themselves).
• Data structure: the main tables and what their fields mean.
• Known issues and special handling: where temporary workarounds exist and which exceptions need manual handling.

The documents do not have to be thick, but they must be updated along with the system. You can agree in the contract that the relevant documents are delivered at each milestone’s acceptance, rather than pieced together when the project closes.

Exit terms: agree on how to part before you start

Talking about parting ways at the start of a relationship is awkward, but it is exactly when it is easiest to discuss. Exit terms should include at least:

• Termination conditions and notice period: under what circumstances either side can end the relationship, and how much notice is required.
• Handover obligations: what the vendor must deliver on termination, such as the latest source code, full permissions on every account, documentation, and data exports.
• Handover support period: whether, for a period after termination, the original vendor provides limited consulting support to whoever takes over, and how that support is charged.
• Data handling: when the data held by the original vendor is deleted and how deletion is demonstrated.
• Settlement: how work completed but unpaid, and work paid for but not completed, are handled.

Lock-in risk assessment before you sign

Use this table directly when comparing vendors or platforms, rating each item low, medium, or high risk:

Item	What low risk looks like	What high risk looks like
Source code	In the company’s repository, accessible at any time	Delivered only at project close, or not at all
Accounts	All in the company’s name, vendor as collaborator	Opened by the vendor or an individual
Cloud and third-party services	Bills go directly to the company	Vendor pays and invoices you
Technology choices	Common industry languages and frameworks	Heavy dependence on the vendor’s own tools
Data export	Client can export a common format on its own	Must go through the vendor; proprietary format
Documentation	Delivered and updated with each milestone	Never agreed
Exit terms	Clear handover obligations and support period	Not mentioned in the contract at all

A high-risk item does not necessarily mean you cannot work together, but raise it for discussion before signing, or know clearly what you are accepting. For the other factors to compare when choosing a vendor, see How to Choose a Software Development Company.

If you do not want to discover lock-in after the fact, the best time to act is before you sign or choose a platform. NETVANA keeps source code in the client’s repository and opens accounts in the client’s name, and early in a project we confirm data export and handover arrangements with you. If you already have a contract or a system in place, we can start by reviewing your current lock-in risk. All software work is quoted after a consultation, so get in touch. The scope of our development and maintenance services is listed in the software services overview.

Further reading: If you are already changing vendors and need an actual handover, see Source Code Ownership and Project Handover. To decide between off-the-shelf SaaS and building your own, read Build or Buy: SaaS or Custom Software. For the trade-offs of low-code platforms, see the Low-Code and No-Code Platforms Guide. For how to read the licenses on open-source packages, read Open-Source Licensing Basics. And for what to ask when choosing a vendor, see How to Choose a Software Development Company.