Vendor Lock-In: Warning Signs and an Exit Path Before You Connect Deeply

Lock-in does not start in the contract. It starts with one field you cannot export. The signs are testable before you connect deeply: whether a bulk export exists, whether it carries everything the screen shows, whether the schema is documented, and what the agreement says about extraction. An exit path is a routine export that has been proven by a restore.

Six warning signs you can test this week

Each of these is tested by doing, not by asking on a questionnaire. Six checks you can run against a system you already have:

• No bulk export. You can export one screen or one report, but not the whole entity at once. The tell: the action exists only inside a results view and is limited to whatever is filtered right now.
• The export returns less than the screen. Open one record on screen and compare it field by field against its row in the file. What usually goes missing: attachments, notes and threads, change history, custom fields, and rows marked as deleted.
• No documented schema. There is no document explaining what each column is, what values it is limited to, and how a relationship between entities is represented.
• A proprietary or opaque format. The export is a file only the vendor's own tool can read, or an archive with no published specification.
• Contractual limits on extraction. A frequency cap, a fee per export, a required notice period, or a clause governing deletion at the end of the engagement.
• No test restore has ever been done. Nobody has taken an export and loaded it somewhere neutral to see what actually comes out.

The second sign is the most common and the easiest to miss, because the export file looks full. It is full - just not of the same fields.

What does a complete export actually have to include?

"We have an export" is an answer that has to be taken apart. This table is the checklist against a typical entity:

That last row is what ruins migrations. An export that expresses a relationship only through an internal identifier produces a file you cannot join to anything else, unless you also exported the identifier table.

The identifier problem: why you need a key of your own

A vendor's internal identifier belongs to the vendor. The moment you move to another system it is meaningless, and every link between records falls apart. The fix is simple and has to start early:

• Define your own external identifier for each core entity - customer, document, project.
• Store it in a custom field inside the system, and also in a separate table you control.
• Confirm it appears in every export, not only on screens.
• Never derive it from something that changes, such as an email address or a name.

This is the smallest piece of work on this list and the one that matters most on the day you decide to move.

Your exit file: what to export, how often, and where it lives

An exit path is not a plan document but a folder that keeps updating. Its components:

1. A full export of every core entity, at a fixed cadence matched to how fast your data changes.
2. A more frequent export for entities that change daily, to shrink what is lost between runs.
3. Storage outside the vendor's system, and not on one employee's drive.
4. Several generations retained, so you can go back to a period and not only to the latest day.
5. A field dictionary updated alongside the export, including changes you discover.
6. One complete sample record per entity, so structure can be compared later.
7. A note of the tool, version and parameters the export was produced with.

The last item sounds bureaucratic right up until the first time an export behaves differently and nobody knows what changed.

How do you prove a restore actually works?

By drill, not by assertion. A successful restore drill looks like this:

1. Pick a defined period, for example one calendar month.
2. Load that period's export into a neutral place - a database or a spreadsheet - that is not the vendor's.
3. Compare the record count against exactly the same filter in the system's own screen.
4. Compare at least one monetary or quantity total, not only a count.
5. Open three attachments from the export and confirm they open and belong to the right record.
6. Take one complete record and compare it field by field against the screen.
7. Write down what was missing. That list is the real output of the drill.

The expected result the first time is a list of gaps, and that is entirely fine - it is precisely why you do this before you need it. A drill that repeats on a fixed calendar is the difference between a backup and a hope.

What to settle before you connect deeply

The deeper the integration, the more expensive the exit, so some of these questions belong to the contracting stage rather than the build stage: who owns the data and the derived outputs, what extraction rights exist and at what frequency, what happens to the data at the end of the engagement and within what timeframe, who holds the accounts and secrets for the integration, and whether critical business logic will live only inside a vendor's tool. These are contractual questions, and the answers are settled with a lawyer rather than with a development team.

Related: a migration plan off an Access system, moving from Excel to an Israeli ERP, handing over a critical spreadsheet with one owner.

Sources

• GDPR Article 20 - Right to data portability
• European Commission - The Data Act
• Microsoft - Restore and recovery overview in SQL Server