You recognise it from the phone call that usually comes around year-end. "The system won't generate the tax return, the vendor hasn't picked up the phone in three days, and the bookkeeper needs to close the month tomorrow — what do we do?". The story is always similar: a few years back they trusted the "guy who's good with computers". He is good. Too good. Because he's the only one.
There's no documentation. The source code lives on his laptop. The database password was last remembered six months ago. And the service contract is a PDF from 2019 with no data-return clause. That's lock-in. And in Polish SMEs it's far more common than owners think.
How you get here
It rarely looks like someone locking you in on purpose. Usually the opposite — a small vendor, a nice price, one talented developer, "we'll give you a system tailored exactly the way you need it". The contract is short. The contract says nothing about data return, documentation, source code, server passwords. Why bother — "we'll figure it out if something happens".
Three years later that one person gets promoted, moves abroad, starts their own shop, or simply has sixty other clients and no time for you. That's when the problem starts. Not with your system — with your dependence on one person and one company that no one on your side ever backed up.
Five signals that you're locked in
Test this in your own company. Honest answers to five questions.
- Data export. When you ask for a full export in a standard format (CSV, XML, JSON, SQL dump), do you get it within 5 days, no debate? Or does "we'll set a date" drag on for weeks and come back as an incomplete file?
- Admin access. Does anyone on your side have an administrator login to the database and the server? Or does everything go "through our guy"?
- Incident response. Does the service contract state clearly how many hours you wait for a critical-fault repair? Or is it "we'll call when we can"?
- Documentation. Do you have — on paper or in SharePoint — a database schema, an integration description, and a recovery procedure? Or is all of that in the vendor's head?
- Plan B. When you ask "what if you shut down tomorrow?", does the vendor laugh and say "come on, we're not going anywhere"? That is not an answer. That is a wish.
Three "no" answers out of five means lock-in. You don't have to escape today. You do have to know about it.
A real example
A 22-person electrical wholesale in Greater Poland. Since 2014, they'd been running sales and warehouse on a custom ERP built by a local software house — then a 3-person team. The system worked, changes shipped "when the guy has time", the price was stable. In 2023 the lead developer moves to Germany. The rest of the vendor — the owner plus two people servicing other clients — keeps the system alive, but their knowledge of the code is essentially zero.
Result: a request for a data export took six weeks and produced a file missing four years of stock-movement history. The database was in a non-standard format, several indexes were corrupt, the source code got lost somewhere between laptops. Migration to Comarch Optima ERP XL took 6 months, cost PLN 130,000 (analysis, mapping, manual reconstruction of missing data, training), and for 2 months the company operated on reduced functionality.
Had the 2014 contract contained four sentences about source-code escrow and required data-export formats — the migration would have cost a third and taken two months. Four sentences.
Contract clauses that change everything
This isn't about a hundred-page contract. It's about four or five clauses that every agreement with an IT vendor building you custom software — or handling your critical data — must contain.
- Source-code escrow with a third party. A notary or a specialised escrow firm. Refreshed quarterly. Released to you if the vendor goes bankrupt, stops responding for 30 days, or unilaterally terminates the contract.
- The right to export all your data on demand, in an open format (CSV, XML, JSON, SQL dump), within 5 business days, at no extra cost. Crucially: "all" means history, attachments and configuration too.
- Documentation as a delivered artefact. Database schema, module descriptions, admin procedures. Updated with every significant change. Without it, the project is not accepted.
- A 90-day termination notice, with a support obligation during that period. Not "we terminate — from tomorrow we're out of reach".
- A cap on unilateral price increases at inflation + 3 percentage points per year. Without this, a vendor who realises you're dependent can raise the monthly fee by 200% on short notice.
None of these clauses is controversial. A vendor who refuses them is telling you themselves that something is off.
Already locked in — how to get out
No panic. In this order:
- Get a copy of your data, even in an ugly format. Any CSV, any export, any database backup. Held by you, in your cloud, in your office. Anything — as long as it's not only with the vendor.
- Find out what database engine the system runs on and what language it's written in. You don't need to understand it. You need to know it. That's already half the negotiation with a second vendor.
- Ask for a list of integrations and a rough architecture diagram. Even a sketch on paper. Vendors usually agree if you ask calmly and directly.
- Write down what the system actually does. Probably 12 things, of which 4 are critical, 6 useful, and 2 nobody's needed in 3 years. Migration only needs to rebuild the critical and useful ones.
- Talk to two or three alternatives in parallel. Comarch Optima, enova365, Symfonia, Streamsoft, Subiekt — depending on your scale. Ask each for an initial migration quote from your specific situation. The spread of the quotes tells you who understands the problem and who is selling slides.
The cost of a migration done without panic is typically 4–8× the annual maintenance cost of the current system. If you do it in panic after an outage, it can be three times higher.
Next time
With every future IT vendor — ERP, WMS, CRM, hosting, specialised application — ask three questions before signing anything.
- What does my exit from this contract look like in 5 years? If the answer is "we don't plan for those scenarios", that's a signal.
- In what format will I get my data if I ask for it? You want to hear specific format names, not "in the system's own format".
- How many people on your side know this system well enough to keep it running if developer X gets sick tomorrow? An answer of "one" means you're buying not just the system, but the biographical risk of one person.
A good vendor doesn't take offence at these questions. They answer them gladly, because they know a stable, orderly client relationship is their asset — not a threat.
Next steps
If you suspect you're sitting in a lock-in and want to assess it honestly — no pressure, no migration pitch on the first call — let's talk for 30 minutes. The first step is usually a list of four or five things worth securing in the coming quarter, before they turn into a drama.
"We're not going anywhere" is not a continuity strategy. It's a wish.