ContractsChoosing a vendorMaintenanceCode ownership
Avoiding vendor lock-in: your exit plan for custom software
7 min read
Avoiding vendor lock-in means being able to take your software and your data to another vendor, or to your own team, without starting again. It rests on five things: a complete data export, the source code or access to it, documentation, control of the technical accounts, and help from the outgoing vendor during the handover. The exit plan is negotiated when you sign the contract, never on the way out.
This article covers what you need to be able to recover, how to write it into the contract, and what European law already requires of some providers. It stays general and is not legal advice: for a specific contract, talk to a lawyer in the jurisdiction that governs it.
Why plan the exit before you sign
Software projects do not always end as planned. The vendor may close down, change direction, stop maintaining your application, or simply stop being the right fit. If nothing has been agreed, you find out at the worst moment that your data sits in a proprietary format, the hosting is on the vendor's account and nobody else knows how to deploy the code.
The cost of a poor exit is not only technical. It is leverage: whoever holds the access sets the terms of departure. Hence a simple rule: anything that must be handed back one day should be identified on day one.
What you need to be able to recover
| Item | What it includes | Common trap |
|---|---|---|
| Data | Full database, files, history | Partial or unreadable export |
| Source code | Repository, history, scripts | Code that cannot be deployed |
| Documentation | Architecture, setup, operations | It only exists in someone's head |
| Accounts | Hosting, domain, email, APIs | Opened in the vendor's name |
| Handover | Transfer, questions, overlap period | Neither planned nor priced |
Data comes first. It should be exportable in full (attachments and history included), in a documented format another tool can read. If the vendor processes personal data on your behalf and the GDPR applies, Article 28 of Regulation (EU) 2016/679 already requires the contract to provide for that data to be deleted or returned at the end of the service, at your choice.
Source code only comes to you according to the rights in your contract, as explained in who owns the source code of custom software. Even when you have access, check it is complete: deployment scripts, configuration, database migrations. A repository without them cannot be redeployed.
Documentation must let another team install, run and extend the application. It is kept up to date during the project, not written in a rush at the end.
Technical accounts are the item most often forgotten. Ideally, hosting, the domain name and third-party services (email delivery, payments, storage) are opened in your company's name, with delegated access for the vendor. Otherwise, the contract should provide for their transfer.
Writing the exit clause
A useful exit clause is specific. It answers six questions:
- When can an exit be requested: normal end of contract, termination, vendor failure?
- What is handed back, with the export formats.
- How long the transition lasts, while the service keeps running.
- What help the outgoing vendor gives: days of support, handover meetings, answers to the new team's questions.
- At what price: included, or priced in advance on an agreed rate. A price "to be agreed" opens a negotiation at the worst possible moment.
- What happens next: deletion of your data at the old vendor once the transfer is confirmed.
The clause works together with the rest of the contract: ownership, data protection, termination. Our article on software development contract clauses goes through them.
Software escrow
When you do not receive the code itself, for example under a licence or a subscription, escrow protects access to it in defined events. The source code is deposited with an independent escrow agent, and an agreement between the vendor, the client and sometimes the agent sets the release conditions: typically insolvency, the end of maintenance or the vendor disappearing.
Two limits to keep in mind. Release from escrow does not necessarily give you ownership; it gives you what the agreement says. And a deposit is only useful if it is recent and complete. Some escrow agents offer verification, where the code is compiled and tested from the deposit: it costs more, but it proves the deposit can actually be used. In France, for example, the Agence pour la protection des programmes offers both verified and controlled deposits.
What the EU Data Act changes for cloud services
Regulation (EU) 2023/2854, the Data Act, has applied since 12 September 2025. Its Chapter VI deals with switching between data processing services (cloud, hosting, software delivered online) offered in the EU. Article 25 requires the contract to include, among other things:
- a notice period of no more than two months to start switching;
- a transitional period of no more than 30 calendar days, during which the service keeps running; if that is technically unfeasible, the provider must say so within 14 working days with a justification and propose an alternative of no more than seven months;
- a data retrieval period of at least 30 calendar days;
- full erasure of the exportable data once switching has succeeded and the retrieval period has ended.
Article 29 phases out switching charges: until 12 January 2027 they may be charged but cannot exceed the costs directly linked to switching; from that date they are prohibited.
Mind the scope. Article 31 sets a lighter regime for services where most of the main features were custom-built for one customer and that are not offered at broad commercial scale: the ban on switching charges, among other obligations, does not apply, and the provider must tell you before signing which obligations are excluded. An application built only for you may fall into that category. The Data Act sets a floor for cloud services; it does not replace an exit clause in your own contract.
Test the exit before you need it
The best proof of an exit plan is a rehearsal. During the contract, ask for a full data export and check that it opens. If you have access to the code, have a third party confirm that it deploys from the repository and the documentation, without help. That is also what a one-off technical audit is for.
Your technology choices matter as much. An application written with common, documented tools is easier to hand over than a proprietary patchwork, which is the point of our guide to choosing a tech stack for business software.
Where LPR Studio stands
Exit terms depend on the model you choose and are written into the contract case by case, like the rights in the code. With the subscription model, LPR Studio remains the publisher and operator of the application: the exit question is then mostly about your data and the end of the contract, and it is settled at signature. Our stack is deliberately mainstream (React, Next.js, TypeScript), so that another team can take over the code where the contract provides for it. The three models are on our offers page and our way of working on our approach page.
Where to start
Raise the exit question in your first conversation with any vendor: the answer says a lot about the relationship to come. At LPR Studio, the visual prototype is free and presented in a video call within 5 working days, wherever you are. It is also the right moment to discuss, for your project, what each model provides when the contract ends.