Plan an AI marketing vendor exit by testing export completeness, deletion evidence, replacement portability and launch continuity before dependency deepens.

Short answer: answer: Test four things before dependency grows: whether you can export usable data, obtain defensible deletion evidence, reproduce critical workflows elsewhere and continue priority marketing during transition. Keep the export schema, integration inventory, credentials, contract triggers and named owners in an exit pack. If any critical record or customer promise exists only inside the vendor, the relationship is not exit-ready.

Procurement often asks whether a vendor has an export button. That is not enough. The export may omit prompt versions, source provenance, approval history, rights records, embeddings, audience logic or stable identifiers needed to reconstruct work.

The other mistake is postponing exit planning until renewal, acquisition, price change or service failure creates urgency. At that point, teams discover proprietary formats and undocumented automations under deadline. CDM’s position is that vendor evaluation is incomplete without tested export, deletion, replacement and continuity paths before lock-in deepens.

The Vendor Exit Dependency Test

The Vendor Exit Dependency Test has four gates: Export, Delete, Replace and Continue. Each receives 0, 1 or 2 points, but every critical gate must score at least 1. A total of 7 or 8 is exit-ready; 5 or 6 requires a funded remediation plan; 0–4 means no new dependency should be added.

These thresholds are CDM recommendations. NIST SP 800-161 addresses cybersecurity supply-chain risk across acquisition and supplier relationships, while NIST SP 1305 supports communicating supplier requirements. NIST’s Privacy Framework includes decommissioning and external-service considerations. The frameworks do not certify a vendor or prescribe this score.

Gate 1: Export

  • 0: No usable bulk export or essential objects are missing.
  • 1: Core data exports, but relationships, metadata, history or machine readability are incomplete.
  • 2: A tested export contains defined critical objects, stable IDs, relationships, versions and documented schema in a usable format.

Create a critical-object list before testing: prompts and templates, sources, outputs, approval records, audience definitions, campaign history, performance data, consent or suppression state, creator rights, billing records, user and audit logs, API configuration and deletion history. Not every object must migrate, but omission must be a deliberate retention decision.

Open the files outside the vendor. Validate row counts, required fields, encoding, timestamps, currencies, links and referential integrity. A ZIP file that cannot recreate a decision record is not a successful export.

Gate 2: Delete

  • 0: Deletion scope, timing or exceptions are unknown.
  • 1: Contract or documentation describes deletion, but completion evidence and downstream scope are limited.
  • 2: The organization can initiate deletion, identify covered stores and subprocessors, receive evidence, and record lawful or contractual retention exceptions.

Distinguish account closure, visible-history deletion, API object deletion and backend retention. Plan revocation of tokens, service accounts, webhooks and support access. Where GDPR Article 28 applies, the controller-processor contract must provide for return or deletion at the controller's choice after services end, and deletion of copies, unless EU or Member State law requires storage.

EU standard contractual clauses for covered international transfers also contain module-specific return or deletion terms. Whether either regime applies is a legal determination, not a CDM assumption.

Gate 3: Replace

  • 0: Critical workflow logic is proprietary or undocumented.
  • 1: A substitute exists but has not reproduced priority outputs and controls.
  • 2: A representative workflow runs on the substitute or manual path with tested quality, permissions, data handling and decision records.

Map each dependency: model call, prompt, retrieval, vector store, connector, identity, scheduler, approval, analytics and downstream action. Record open standards and proprietary components separately. Export prompts without retrieval sources or tool schemas will not recreate behavior.

Replacement does not mean identical output. Define required properties: supported claims, valid schema, rights evidence, suppression behavior, latency and review effort. Revalidate the new route as a system change.

Gate 4: Continue

  • 0: Vendor loss stops a critical customer promise with no fallback.
  • 1: Manual continuation exists but roles, capacity or data freshness are untested.
  • 2: A timed exercise proves priority functions continue for the approved outage or migration period.

Choose what must continue: active offers, preference and suppression enforcement, creator payments, customer support, reporting evidence and scheduled launches. Low-priority content generation can wait. Continuity should protect customers and records before convenience.

Build the exit pack

The reader asset is a Vendor Exit Readiness Scorecard plus evidence folder:

SectionEvidence
Scopeproducts, features, accounts, regions, owners and business purposes
Contractrenewal, notice, fees, assistance, export, deletion and retention terms
Dataobject inventory, classification, schema, volume, export route and control totals
IntegrationsAPIs, keys, webhooks, SSO, domains, connectors and downstream actions
Workflowspriority, logic, source, reviewer, fallback and maximum tolerable interruption
Exit testdate, sample, results, omissions, remediation owner and retest
Closureaccess revoked, deletion evidence, retained exceptions and customer/partner notices

Store the pack somewhere the vendor does not control. Encrypt sensitive exports, restrict access and apply an approved retention schedule; exit planning should not create an uncontrolled duplicate of customer data.

Run three tests before renewal

First, run a sample export test. Select representative objects from old and new periods, languages, users and workflows. Reconcile control totals and reopen the records in neutral tools.

Second, run a shadow replacement test. Process a small, non-sensitive set through the alternate route and compare required properties, operating time and review load. Do not send both outputs to customers.

Third, run a continuity tabletop. Assume the vendor becomes inaccessible at a defined time. Walk through stopping integrations, preserving consent and suppression, switching active work, informing stakeholders and reconciling results. Record gaps and retest.

Do not claim deletion was tested if the exercise only reviewed documentation. A true production deletion test can be destructive and may require specialist authorization; use a disposable workspace or contracted test method when available.

Work an illustrative exit score

A creator-campaign platform stores briefs, contract references, usage rights, generated variants and performance. Its CSV export includes campaigns and creators but omits asset-version relationships and approval history, so Export scores 1. Contractual deletion is documented but completion evidence is not defined, so Delete scores 1.

The team has reproduced briefs and approvals in an alternate system, so Replace scores 2. A tabletop shows creator payments continue but live suppression data cannot be refreshed, so Continue scores 1.

Total: 5. The vendor remains in use, but procurement makes schema-complete export, deletion confirmation and suppression portability conditions of renewal. New workflows do not store sole copies of rights evidence there. This is illustrative; CDM did not inspect a vendor, contract or migration.

Set trigger and authority rules

Exit triggers can include material price or terms change, security incident, repeated availability failure, missed service level, deprecation, ownership change, unacceptable model behavior or strategic consolidation. Define who may invoke a test, stop new data, authorize migration and accept residual loss.

Run the score before purchase, before renewal, after a material product or contract change and after a failed export. High-dependency vendors deserve more frequent sample exports. Version the schema and compare changes rather than assuming last year’s test still passes.

Mandatory requirements and specialist review

Contracts, privacy law, records rules, litigation holds, intellectual-property licenses and sector obligations may determine what must be returned, retained, deleted or proven. Security teams should manage credentials and evidence; privacy and legal specialists should decide deletion and notification obligations; finance should confirm invoices and remaining commitments; operations should own continuity.

A readiness score does not establish compliance or guarantee a successor. Vendors may restrict exports, charge for assistance or preserve data under lawful exceptions. Surface those limits before the organization builds an irreversible process around them.

Related guides

Frequently asked questions

When should an AI vendor exit plan be created?

Create it during evaluation, before sensitive data and critical workflows accumulate, then update it before renewal and after material product, model, contract or integration changes. Early planning gives procurement leverage and lets teams design portable identifiers and records.

The caveat is proportionality: a disposable public-copy experiment needs less evidence than a platform holding consent, rights or customer decisions. Document the limited dependency rather than skipping the question entirely, and expand the plan when scope grows. Assign an owner before the first production dependency begins.

Is a CSV export proof that we can leave?

No. Test whether the export contains critical objects, stable identifiers, relationships, versions and evidence needed to operate or audit the workflow. Open it in neutral software, reconcile counts and recreate a representative decision. A CSV may flatten or omit prompts, rights, approvals, sources and automation logic.

The caveat is intentional omission: some transient outputs need not migrate. Record the retention decision and confirm that legal, contractual and customer obligations do not require the missing history. Preserve schema documentation beside every tested export.

How do we verify that a vendor deleted our data?

Use the contractual process, identify covered systems and subprocessors, revoke access, submit the request and retain completion evidence plus stated exceptions. Test what the customer can observe in a disposable workspace where authorized. The caveat is limited visibility: customers generally cannot inspect every backup or security log.

Procurement and legal teams should obtain proportionate attestations, timing commitments and audit rights while acknowledging lawful retention. A blank user interface alone does not prove complete backend deletion. Record precisely which stores remain outside verification.

Must the replacement vendor produce identical AI output?

No. It must meet the required properties of the task: factual support, format, rights, privacy, suppression behavior, latency and human-review load. Exact prose equality is neither realistic nor necessarily desirable. Build a regression pack around outcomes and hard failures, then compare the replacement route.

The caveat is customer-facing consistency: material changes in claims, eligibility or experience may require additional approval, notice or retraining. Treat migration as a system change rather than a simple file transfer. Preserve the old baseline until acceptance is signed.

What if the vendor will not provide a complete export?

Reduce dependence, keep system-of-record data elsewhere, negotiate export and transition rights, and maintain a manual or alternate path for critical functions. Price the known loss into procurement and prohibit the platform from becoming the sole store for consent, rights or decision evidence.

The caveat is that scraping or reverse engineering may violate terms, law or security controls. Obtain qualified advice and do not improvise an extraction that exposes personal data or credentials. Escalate unresolved loss as an explicit acceptance decision.

How often should exit readiness be tested?

Test high-dependency vendors before renewal and after material schema, product, contract or integration changes; run sample exports more frequently when critical data changes quickly. CDM recommends at least an annual full score for material vendors, with quarterly lightweight evidence checks where loss would interrupt customers.

The caveat is that this cadence is a recommendation, not a standard. Use maximum tolerable interruption, data volume and vendor volatility to set the interval, and retest immediately after a failed export or continuity exercise.

Next decision: How Do You Audit Marketing Access for Agencies and Former Contractors?

Related reading: How Do You Build a Data-Risk Register for Marketing AI Tools? · What Should a Marketing Team Do When a Critical Tool Fails on Launch Day? · What Should a Small Team Document—and What Can Stay Informal?

Sources and research notes

Limitations: CDM did not inspect a vendor, contract, export, deletion process or alternate workflow and did not execute the illustrative tests. Scores and cadence are CDM recommendations. Obtain procurement, privacy, security, legal, records and operations review for actual exits.

CDM Editorial

This article is editorial guidance. Apply the principles in proportion to your market, evidence, and responsibilities.