Write the Vendor Exit Plan Before You Need It

The worst time to discover that an export is incomplete is after the account is suspended, the product is discontinued, or the relationship has become commercially untenable. “We can always migrate” is not a plan. It is a claim that needs a timed test.

The operations chapter covers vendor security and contracts. This guide adds the exit mechanics. It does not compare current vendor prices.

Inventory what the vendor really does

Start with the visible service, then trace the hidden dependencies: authentication, workflow triggers, webhooks, customer identifiers, logs, support history, billing state, file storage, secrets, DNS, analytics, and staff habits. Name the internal owner and the business process that stops if the service disappears.

NIST’s supply-chain guidance is written for broader and often more formal environments, but its lifecycle point transfers: supplier risk needs identification, assessment, mitigation, and tested contingency planning rather than a one-time procurement check (NIST SP 800-161 Rev. 1).

Define an exit packet

For every critical vendor, keep: contract and renewal date; notice window; data categories; export method and format; API limits; encryption or key dependencies; service accounts; integration map; deletion process; subprocessor implications; replacement candidates by capability, not price; target recovery time; maximum acceptable data loss; and the person authorized to act.

Store emergency credentials outside the vendor being exited. A password manager cannot be the only place holding the recovery instructions for that same password manager.

Worked hypothetical: the export that was not a restore

Worked hypothetical. A support platform holds 40,000 tickets, customer attachments, assignment rules, macros, and an authentication integration. The standard export contains ticket text and timestamps but omits attachments, internal macros, and identity mappings. The team’s first estimate says migration takes two days.

A restore test with 200 sampled tickets takes one engineer three days. Attachments require a separate API pull, identity mapping needs a translation table, and rebuilding routing rules takes another four days. The measured exit time becomes two weeks, with a planned read-only period and a manual intake fallback. The company has not switched vendors; it has replaced optimism with an executable estimate.

Test reversibility in layers

Run a quarterly or semiannual test proportionate to criticality:

1. Export a dated sample and hash or count it.
2. Load it into a neutral store or test destination.
3. Verify representative records, attachments, timestamps, permissions, and relationships.
4. Exercise credential recovery without relying on one employee.
5. Simulate loss of write access and run the manual fallback.
6. Record elapsed time, missing fields, and remediation owner.

NIST contingency guidance emphasizes that recovery requirements should follow business impact and that plans need testing and maintenance. Its federal-system scope is broader than a startup’s, so use the principle rather than copying the bureaucracy (NIST SP 800-34 Rev. 1).

Make the renewal meeting a decision

Before renewal, review incidents, export-test results, switching time, concentration, contract changes, and any new product dependency. Decide: accept, mitigate, dual-run, renegotiate, replace, or consciously retain the risk. Price matters, but a cheaper tool with no usable export can be more expensive at the first disruption.

Limitations: an export test cannot prove a full migration, replacement vendors may share infrastructure, and contractual deletion or portability rights vary. Counsel may be needed for regulated data, insolvency, disputed access, or termination terms.