In brief
- Exit requirements belong in architecture and contracts before signing.
- Prompts, configurations, permissions, tests and logs are as relevant as documents.
- Exportability does not mean another system can use the format without adaptation.
- Deletion, access revocation and remaining backups need a verifiable close-out.
Identify what must actually move
A complete exit covers business data, application logic and operational evidence. The more proprietary platform features the solution uses, the more needs clarification in advance.
| Exit artefact | Portable form or replacement | Test before termination | Close-out evidence |
|---|---|---|---|
| Source data and permissions | Open document or data formats plus an exportable permission mapping | Reconcile record counts, versions and representative access cases in a neutral environment. | Final consistent export, checksum and named data owner acceptance. |
| Prompts, workflows and agent configuration | Versioned text, schemas, rules and tool definitions outside proprietary editors | Recreate one production path without the provider's visual builder. | Repository version, dependency list and documented non-portable features. |
| Indexes and embeddings | Documented export format or a reproducible rebuild from approved sources | Rebuild a sample and compare retrieval quality and permissions. | Rebuild runbook, source snapshot and quality baseline. |
| Evaluations and operating evidence | Test cases, expected results, feedback, logs, costs and incident history | Run the same release gate and operating report in the target environment. | Accepted comparison, retained audit evidence and owners for open issues. |
| Accounts and retained copies | Revocation list and contractual deletion process for live data, backups and subprocessors | Disable a test account and verify that integrations and keys stop working. | Revocation log, deletion confirmation, known backup periods and residual-risk decision. |
The contract must enable exit
Generic deletion promises are insufficient. Timelines, formats, support, cost, backups and subprocessors should be addressed explicitly.
- Export formats, interfaces and access period after termination
- Migration support and defined fees
- Deletion periods for live systems, backups and subprocessors
- Deletion evidence or confirmation
- Continuing confidentiality, security and incident notification
- Rules for insolvency, service discontinuation or sudden suspension
Test portability in practice
An export can be complete and still be difficult to use. An early rehearsal shows whether content, permissions and configurations are readable, complete and reconstructable.
- Step 1
Inventory
Map all data, configurations, keys and dependencies to the system.
- Step 2
Run a test export
Download files and metadata and check completeness.
- Step 3
Test restoration
Reconstruct a small sample in a neutral or alternative environment.
- Step 4
Record gaps
Make non-portable features and required rework visible.
Complete the exit with controlled retirement
After migration, old integrations, accounts and keys must be disabled. Remaining data and legal retention are reconciled, and the close-out is recorded in the AI inventory and operational evidence.
- Stop writes and create the final consistent export.
- Revoke users, service accounts, API keys and single sign-on connections.
- Disable webhooks, connectors and data feeds.
- Preserve deletion confirmation and known backup timelines.
- Monitor for residual traffic and broken dependencies.
- Have accountable owners confirm migration, deletion and closure.
Example: Moving a knowledge assistant
A company owns the original documents but lacks exportable source permissions and evaluation cases. Before moving, it reconstructs the permission model and exports prompts and feedback. It rebuilds the index from source material at the new provider. Keys are revoked and deletion at the former provider is confirmed only after a successful parallel test.
What to remember
Test export and reconstruction while the provider relationship is normal. An exit plan is credible only when data, logic, permissions and operations are practically portable.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed
Reviewed 17 July 2026. General information, not legal advice. The specific legal position and applicable scope must be assessed for each use case.