Almost no one chooses a management system thinking about the day they will leave it. Yet that day is what tells you whether your data was really yours. You want to switch vendors, or the vendor raises the fee, or simply shuts down: and you discover that taking away years of customers, orders and documents is harder than you thought. This is vendor lock-in, and almost always you sign up for it without realizing.
What being stuck actually means
Lock-in does not mean switching is impossible. It means the cost, in money, time or risk, is so high that you stay where you are even when it no longer makes sense. It often comes not from a clause in the fine print, but from how the software is built. The signals are always the same:
- The data does not come out, or comes out in a format only that software can read.
- There is no export procedure, nor a schema explaining how the data is organized.
- Integrations go through undocumented APIs, or no API at all: every connection is a project of its own.
- The code is not yours, and the contract does not say on what terms it could become so.
The result is a loss of bargaining power: when the only alternative to a rising fee is starting over from scratch, you are no longer negotiating, you are taking what you are given.
Who owns your data
Your operational data (customers, contracts, work history) is yours: you produced it. The point is not ownership on paper, but whether you can get it back in a form that is good for something. A PDF export is not a data export: it is a snapshot, not data you can reimport into another system. An export in CSV or JSON, with a documented schema, is data another system can read.
The right question is not “can I export?”, but “in what format, and does anyone besides you understand that format?”.
Who owns the code (the honest answer)
There is a convenient and often false promise about code: “the code is always yours”. It is not, and be wary of anyone who guarantees it upfront. Source code ownership is a contractual matter, usually tied to payment: it depends on what you sign, not on a law of nature.
What you can demand is clarity. What stays yours, on what terms and at what point must be put in writing in the contract, before you start, not argued the day you want to leave. No technical lock-in is one thing: standard, documented technologies, data that comes out. Code transfer is another: it is agreed, if you need it. They are two different guarantees, and they should be kept distinct.
The checklist: what to ask before signing
These questions cost ten minutes and tell you a lot. Ask the vendor before signing, while you still have bargaining power, and demand precise answers, not reassurances:
- What format does my data come out in? (CSV and JSON are standard; “PDF” or “we'll send it to you” are not.)
- Is there a documented data schema that explains how the data is organized?
- Is there an export and migration procedure, and can I use it on my own whenever I want?
- Do integrations go through documented APIs? Can I see the documentation?
- Who owns the code, and on what terms can it be transferred? Is it written in the contract?
- What happens to my data if I end the contract, or if you shut down?
- What technologies is it built on? Are they standard or proprietary?
If the answer to any of these questions is vague, it is not a technical detail: it is the price of your exit, and they are hiding it from you.
What makes software “lock-in free”
Lock-in free software is not one that promises you will never leave: it is one built so that you can. The proof is simple: your data stays readable even without the vendor.
- Export in standard formats (CSV, JSON), not just views or printouts.
- A documented data schema: you know what each field means and how it relates to the others.
- Standard, documented technologies, not a black box only its author can open.
- Documented APIs, so integrating another system does not start from scratch every time.
- Exit terms written in the contract: data, and if needed code, with clear timing and conditions.
This holds for management systems and even more so when data has to move from one system to another: it is the same reason a well-built integration works on documented APIs and not on connections that break at the first update.
The European direction: the Data Act
This is not just common sense, it is becoming a rule. The Data Act (Regulation (EU) 2023/2854, applicable from 12 September 2025) requires cloud service providers to make switching to another provider easier, with defined timeframes and the gradual end of switching fees set by 12 January 2027. It does not automatically cover every management system (it concerns cloud data processing services and connected-product data), but it shows the direction: data portability is no longer a favor, it is a right. The exact conditions should be checked case by case with an advisor.
How we see it
When we build custom software we work on standard, documented technologies, not on proprietary platforms that tie you down. What stays yours (data, content and, if needed, source code) we define in the contract, in the clear from the start: we can handle maintenance, but by your choice, not because you technically could not leave.
The same principle applies to Verso Flow, our management system for field work: Reports come out in PDF and Excel, and the data sits on European cloud with protected access. The question “who owns my data?” must have an answer before you need it, not after.
If you are evaluating a management system, or want to understand how tied you are to the one you already have, let's talk: we start from where your data lives today and from what it would take to move it elsewhere.