An honest answer to the lock-in question

Every provider says you are not locked in. The question is worth taking seriously anyway, because the honest answer is almost always "partly, and here is exactly where".

You can test the claim yourself in an afternoon, using only systems you already have.

Test one: can you read your own data without them?

Export a production dataset using only the tools they give you. Plain formats — CSV, JSON, standard SQL dump. Then load it into something else: a spreadsheet, DuckDB, a local Postgres.

If that works cleanly, data lock-in is low. If it requires a paid export tool, or produces files their own support cannot read, data lock-in is real and should be priced.

Test two: can you replicate one workload elsewhere?

Take a single non-critical workload. Build a minimal version of it somewhere else, using only published interfaces, without asking the provider for help.

The purpose is not to migrate. It is to discover which interfaces are actually available and documented, versus which exist because you have a relationship. Interfaces that only work with a support ticket are contractual, not technical.

Expect this to be harder than expected for anything proprietary, and easier than expected for anything genuinely standard.

Test three: what is the exit path for identity and access?

This is the one that surprises people. It is frequently the deepest coupling, and it is rarely mentioned in a proposal.

Ask:

• can we export user accounts, group memberships and role mappings
• is the provisioning model documented, or is it an opaque API
• does identity integrate with standards like SAML and SCIM, or only a proprietary endpoint
• if we leave, can we run a parallel environment with our own identity provider

Teams that have attempted an exit have discovered that the identity layer cost more to unpick than the application layer.

Test four: how is pricing structured at exit?

Not the current price. The exit price.

Look for, in the contract:

• minimum commitments that survive termination
• egress charges that make a large data export expensive
• per-seat or per-core terms that collapse when you scale down
• support and managed-service fees that are contractually fixed for a period

A reasonable provider will discuss exit terms without being asked repeatedly. Refusal, or vague answers, is itself the assessment result.

Test five: what would the replacement cost in people?

The most underweighted factor. Replacing a platform means:

• people who know it, leaving
• a learning curve on the replacement
• a parallel-running period
• changes to the processes built around it

For a specialist platform with a decade of institutional knowledge, this is frequently the largest cost in the transition and it appears in no vendor comparison.

What the answers usually look like

Honest positions tend to include: data is portable, and the format is documented. Identity is portable through standards. The specialised engine is proprietary and would need rebuilding. Exit terms exist and are negotiable.

A useful shorthand: standard the platform runs on is rarely locked; the proprietary workflow logic layered on top usually is.

Which means the lock-in assessment is really an assessment of how much of your process has been encoded into their configuration layer.

The most useful question to ask a provider

Not "are we locked in". Ask: "if we left in three years, what would be the hardest thing to move, and what would you help us move it?"

A provider who answers specifically has thought about it. One who says you are not locked in has not.