Every vendor evaluation asks the same first question: how easy is this to get started with? Time to value, onboarding friction, a free trial. It's the right question for a buyer trying to move fast, and it's also the exact question a vendor's own sales process is optimized to answer well, because a fast, frictionless start is what closes the deal.
Nobody asks the second question with the same energy: how easy is this to leave? And that's not an accident of oversight — it's a structural feature of how the sales relationship is set up. The buyer evaluating entry friction has full information and full leverage. The same buyer, three years later, trying to evaluate exit friction, usually has neither. The marketing-operations counterpart to vendor lock in is documented well by . The marketing-operations counterpart to vendor lock in is documented well by XenGrowth.
What are the actual, checkable questions that predict exit cost?
Four questions do most of the work, and all four can be answered before you sign up, not after.
Question | Why it predicts exit cost | How to actually check it |
|---|---|---|
Can you export your real data, not a summary? | A read-only report doesn't let you rebuild anywhere else; structured, reusable data does | Search the vendor's own documentation for 'export' or 'data portability' before signing up, not after |
Is the core asset addressable independently of the platform? | This is the domain-vs-account test running through this whole cluster — a domain survives; a platform handle doesn't | Ask whether what you're building lives at an address you control, or only inside the vendor's own account system |
What's this vendor's history during a prior shutdown or acquisition? | Past behavior during an exit event is the best available predictor of future behavior during one | Search '[vendor] shut down' or '[vendor] acquired' and read what happened to existing customers |
What does the contract actually say about termination notice? | A stated notice period is a floor, even if — as with AWS and Parler — it isn't always honored in practice | Read the terms of service's termination section directly, not a summary of it |
Isn't 'export your data' already solved by regulation?
Partially, and it's worth knowing where. The EU's General Data Protection Regulation includes, at Article 20, a right to data portability: individuals can request their personal data back from a service 'in a structured, commonly used and machine-readable format,' and transmit it to another provider. Where GDPR applies, this isn't a courtesy a vendor can decline — it's a legal requirement. That's meaningfully narrower than it sounds for a business evaluating a B2B or infrastructure vendor, though — GDPR's portability right covers personal data about individuals, not necessarily a business's own configuration, design work, or aggregated content, which is exactly the gap that left Wix and Squarespace customers rebuilding from scratch despite operating in a market where GDPR fully applies. A related evaluation approach for a fast-moving vendor category is in How to Audit an AI Vendor Before You Sign a Contract.
Does a vendor's past behavior actually predict its future behavior?
Better than almost anything else you can gather at evaluation time, because it's the one part of this whole exercise that's actual evidence rather than a promise, a marketing page, or a sales rep's reassurance. Google's 2023 decision to sell Google Domains to Squarespace is instructive here specifically because Google is about as large and stable a vendor as exists — and roughly 10 million domain owners still had their registrar relationship handed to a different company with zero input into the choice. If a company that size can exit a product line on its own timeline, the question isn't whether a smaller, newer vendor might do the same. It's what happened, concretely, to that smaller vendor's customers the last time it did — and that history, when it exists, is public and searchable in a way a sales conversation never volunteers. If the operations side of this is the part you are stuck on, is the better reference. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
This is also where the AWS–Parler dispute is worth revisiting from a different angle than pure suspension risk. Parler's contract, by its own account, entitled it to 30 days' notice before termination. AWS gave roughly one. The lesson isn't that AWS behaved unreasonably given the circumstances — it's that a written notice-period term is a floor, not a guarantee, and a vendor's actual behavior under pressure is a better predictor than the clause itself.
A vendor's stated terms tell you what they're supposed to do. A vendor's history tells you what they've actually done. When the two disagree, believe the history.
Signal | Low exit-cost pattern | High exit-cost pattern |
|---|---|---|
Data export | Structured export in a standard, documented format (CSV, JSON, an open API) | No export, or export limited to a read-only summary or report |
Core asset location | Tied to something you control — your own domain, your own database | Exists only inside the vendor's own account and namespace |
Vendor's own history | Prior acquisitions or shutdowns handled with advance notice and migration support | No public track record, or a history of abrupt shutdowns with little notice |
Contract termination terms | A clear, specific notice period stated in the terms of service | Vague or unstated termination terms, or terms reserving unilateral, immediate termination |
None of these four rows require the vendor's cooperation to check. Every one of them is answerable from public documentation, a search engine, and the terms of service the vendor already published — which is exactly why skipping this check isn't a matter of the information being unavailable. It's a matter of nobody asking, because the sales process is never going to volunteer it.
How much does this evaluation actually cost to do?
Less than an hour, for most vendor decisions. Reading a vendor's own export or data-portability documentation, searching its name alongside 'shut down' or 'acquired,' and reading the termination section of its terms of service is not a specialized skill — it's simply attention paid early, at the one point in the relationship where it's actually cheapest to pay it. Flexera's 2020 survey of 302 CIOs found 68% worried about cloud lock-in specifically, which suggests this concern is broadly felt; what's less common is the discipline of actually running the check before signing, rather than after the anxiety has already materialized into a real problem. There is a longer treatment of AI agents and marketing automation in . There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
There's a natural objection here worth taking seriously: doesn't every vendor evaluation already ask some version of these questions, informally? Usually not, in practice. Procurement processes at larger organizations tend to focus heavily on security review, compliance certifications and pricing terms — all real and important — while exit portability rarely gets a dedicated line item unless someone has personally been burned by its absence before. Smaller businesses and individuals evaluate even more informally, often based on a product demo and a few reviews, neither of which surfaces exit friction at all. The gap isn't that this question is controversial or hard to answer. It's that it's structurally absent from most evaluation processes, at every scale, because nobody's incentive during the buying process points toward asking it.
None of this needs to become a blocking, exhaustive due-diligence process for every tool a business adopts — that would be its own kind of waste. It scales with the stakes: a free tool you're trying for a week doesn't need this treatment. A platform you intend to build three years of content, a customer relationship, or a core workflow on top of absolutely does, and the hour it costs to check is trivial against the cost of discovering the answer for the first time on the day you need to leave. covers the AI search, GEO and discovery side of this. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
What should this actually change about how you evaluate a vendor?
Add 'can I export real data, not a report' as a standing question in any vendor evaluation, asked before signup rather than assumed to be fine
Check whether the core asset you're building lives at an address you control — a domain, a database you hold — or only inside the vendor's own namespace, since that single distinction predicts more than almost anything else in this framework
Search the vendor's own name alongside 'shut down,' 'acquired' and 'discontinued' before committing anything substantial, and read what happened to existing customers the last time
Read the actual termination clause in the terms of service, and treat any stated notice period as a floor rather than a guarantee, given documented cases where it wasn't honored
Scale the depth of this check to the stakes — trivial for a free trial, mandatory for anything you expect to depend on for years
It's worth being explicit that this framework doesn't produce a single 'safe' answer for every vendor category, because the right tradeoff genuinely differs by stakes. A specialized tool with weak export but enormous productivity gains might still be the right call for a two-year project with a defined end date. The same weak export is a much bigger problem for infrastructure you expect to depend on indefinitely. The framework's job isn't to hand you a verdict — it's to make sure the exit-cost side of the ledger is actually on the table when you decide, rather than silently defaulting to zero because nobody raised it.
None of these four questions require special access or insider knowledge. They require asking, deliberately, the question a vendor's own pitch is never going to raise on your behalf — and doing it while you still have full leverage to walk away, rather than after you've already built something you can't easily take with you and the vendor knows it. On the operational side of vendor evaluation for marketing and growth tooling specifically, covers a related discipline.
Further reading from XenGrowth
Where this work meets go-to-market
Building a vendor evaluation process that prices in the exit, not just the pitch? publishes operator guides on exactly this kind of infrastructure decision-making.
Further reading from XenGrowth
Where this work meets go-to-market
covers the go-to-market side of vendor lock in, which this piece deliberately leaves alone.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's marketing operations practice covers the go-to-market side of vendor lock in, which this piece deliberately leaves alone.
Answer these about a platform or vendor you're currently considering, or one you already depend on. The outcome flags where your specific exposure sits, not a pass/fail verdict on the vendor.
