When the Vendor Goes Dark: A Tabletop Exercise for the SaaS Exit You Never Planned

Somewhere in your contract repository is a business continuity clause. It was negotiated, probably by someone who has since changed roles, and it says something reassuring about the vendor providing reasonable assistance in the event of a service termination. It has likely never been tested. For a growing number of American enterprises, that untested clause is becoming a very live problem.

The SaaS market has matured into a consolidation phase. Products get sunset. Acquirers fold overlapping platforms into their own roadmaps. And occasionally, a venture-backed vendor simply runs out of runway. When that happens, the enterprise is left holding a question it never prepared to answer: how do we get our data out, in what format, and how fast?

The most effective way to find out — before it matters — is a tabletop exercise. Not a theoretical review of the contract, but a simulated walk through the vendor's failure. What follows is how that exercise typically unfolds, and where it tends to expose gaps.

Hour One: Locating the Data

The exercise begins with a deceptively simple prompt: point to where the vendor's data lives and describe everything connected to it.

In most sessions, this is the first stumble. Teams know the primary application. They rarely know the periphery — the API integrations feeding reporting tools, the exports a finance analyst downloads monthly, the archived workspaces former employees created, the customer records synced to a marketing automation platform that itself depends on the failing vendor.

A useful framing question for the group: if this vendor's servers went dark this morning, what would tomorrow look like? Which processes stop immediately, which degrade over weeks, and which teams won't notice for a quarter? The answers usually reveal that the blast radius is considerably wider than the software line item suggested.

The Ownership Question Nobody Asked During Onboarding

The second phase examines legal ownership, and this is where contracts earn their keep — or fail to.

Most enterprise agreements state that the customer owns its data. Fewer specify what happens to derived data: the vendor's proprietary analytics built on your inputs, machine-learning models trained on your workflows, metadata about how your organization uses the platform. When an acquirer absorbs a vendor, that derived data often transfers with the deal — sometimes to a competitor of yours.

Legal counsel should be asked three pointed questions during the exercise. First, does the contract define customer data broadly enough to cover derivatives and metadata? Second, is there a data deletion obligation on the vendor side after termination, and is it verifiable? Third, if the vendor is acquired, does the agreement permit the customer to terminate and retrieve data without penalty? A yes to all three is rarer than it should be.

The Export Clock

The third phase is the most concrete: time the extraction.

Contractual data-return windows commonly range from thirty to ninety days after termination. That window, however, measures the vendor's obligation — not your team's actual capacity to absorb the data. A full export of a decade of records, delivered in JSON dumps or opaque database formats, can take weeks to parse before a single record is usable in a replacement system.

Run the math in the room. If the vendor provides ninety days and the migration realistically takes four months of engineering effort, the gap is your exposure. Some organizations discover their only viable path is paying the failing vendor for extended access — a position with remarkably poor negotiating leverage.

What the Migration Actually Costs

The final phase attaches dollars to the scenario. Beyond licensing a replacement platform, the realistic budget includes: data transformation and cleanup, integration rebuilding, retraining, the productivity dip during cutover, and — the line item most often forgotten — parallel running of both systems during validation.

For mid-market US enterprises, a forced migration from a core operational platform routinely lands in the low-to-mid six figures once internal labor is priced honestly. That figure belongs in the vendor risk assessment, next to the subscription cost it currently dwarfs.

A Due-Diligence Checklist for Renewal Season

The exercise should end with contract changes, not just awareness. Before the next renewal, procurement and legal should confirm:

• Export format specified in writing — CSV or another documented, non-proprietary standard, not "commercially reasonable format."
• Export frequency rights — the ability to pull a full data snapshot periodically, not only at termination.
• Defined assistance obligations — named hours of migration support, with fees capped in advance.
• Source code or data escrow for vendors critical to operations.
• Change-of-control termination rights allowing exit without penalty if the vendor is acquired.
• Verified deletion timelines post-termination, with a certificate of destruction.
• Financial health disclosures — for private vendors, at minimum an annual assurance that material adverse changes will trigger notice.

Continuity as a Capability, Not a Clause

None of this argues against SaaS adoption; the model's advantages remain decisive for most workloads. It argues instead for treating vendor exit as an operational capability — mapped, rehearsed, and priced — rather than a paragraph in an appendix.

The enterprises that run this exercise once rarely need to be told to run it again. The ones that skip it will meet the question eventually, on a timeline set by someone else's balance sheet.