The Vendor Lock-In Math: What "Only 6% Could Switch" Actually Means
94% of organizations worry about vendor lock-in, and only 6% believe they could switch their primary vendor without material disruption. Here's what that number actually implies, and what's concretely built to address it versus what isn't.
Vendor lock-in surveys tend to produce numbers dramatic enough to quote and vague enough to not actually change anyone's evaluation process. 2026 enterprise data on this is sharper than usual, and worth sitting with the actual figures rather than the headline: 94% of organizations report being concerned about vendor lock-in; 45% say lock-in has already blocked them from adopting a tool they judged to be better than what they had; only 6% believe they could switch their primary AI vendor today without material operational disruption; and 57% of IT leaders report spending over $1 million on platform migrations in the last year alone.
Read together, those numbers describe something more specific than generalized anxiety about vendors. They describe an asymmetry: the number of organizations worried about lock-in (94%) is enormously larger than the number who've actually done anything that would test whether they could switch (6% confident they could, and a documented $1M+ migration cost for over half of those who tried). Most organizations are carrying the risk without having priced it, which is exactly the situation that turns into an unpleasant surprise later.
What lock-in actually is, mechanically
"Lock-in" isn't one thing — it's at least two different risks that get talked about as if they're the same:
Model lock-in — being unable to move your AI workloads to a different model provider without rewriting how your application calls AI. This is what a multi-provider AI gateway addresses directly: if the gateway your applications call routes to whichever provider you choose — OpenAI, Anthropic, Google, others — rather than hard-coding calls to one provider's SDK, switching which model or provider handles a given request is a routing decision, not an application rewrite. That's real, concrete portability at the model layer, and it's a materially different claim than "we support multiple providers" as a marketing line — it's specifically that your own application code isn't the thing tying you to one provider.
Data lock-in — being unable to get your actual data (documents, spreadsheets, presentations, files) back out of a platform in a usable form if you decide to leave. This is the harder, more consequential version of the two, and it's the one worth being precise about rather than gesturing at broadly.
What's actually built, stated narrowly
Here's the honest scope: Piskes has real, working export paths for specific file types — Drive files can be downloaded directly, spreadsheets round-trip through a real xlsx export and import path, and presentations export to and import from PPTX in both directions. Those are concrete, working capabilities for the file types they cover.
What that is not is a platform-wide, verified "export everything" guarantee covering every data type across all 17 apps — CRM records, chat history, workflow definitions, knowledge-base articles, and everything else the platform holds. Claiming a blanket export guarantee that hasn't actually been verified across the full breadth of the platform would be exactly the kind of overstatement this piece is arguing against making. The honest claim is narrower and more useful: specific, real export paths exist for the file-based content types named above; a comprehensive platform-wide data-portability guarantee is not something that's been built and verified yet.
What this means for how to actually evaluate lock-in risk
The 6% figure is a warning about complacency, not really about any single vendor. Most organizations haven't tested whether they could leave a given platform, which means most organizations' actual lock-in exposure is unknown to them until the day they try — usually under worse conditions than a calm evaluation period. The useful question to ask any vendor, including this one, isn't "do you support switching" in the abstract. It's specific: which data types have a real, working export path today, which don't, and is model-level portability (not being locked into one AI provider's API shape) separate from data-level portability (getting your actual content out) — because they're genuinely different risks with different answers, and a vendor that only addresses one shouldn't be credited for solving both.