Try handing tomorrow morning to someone else
Imagine a fictional Bangkok training company whose assistant prepares course enquiries and updates a customer system. The owner wants to switch tools. They export the chat history and discover that it does not explain which drafts were approved, which messages actually went out or which policy version each answer used.
The useful exit question is concrete: can another person continue tomorrow's open enquiries without sending duplicates or making new promises? That is a business continuity test. You can run it even if you have no intention of changing vendors.
A vendor change can arrive through a pricing decision, a changed permission, a product closure or a model retirement. OpenAI publishes model and endpoint deprecation notices, illustrating why a supplier dependency needs an owner. OpenAI deprecations, checked 20 October 2026. This is not a prediction about any particular product's future.
Separate the business record from the conversation
Keep a stable record for each piece of work: customer or order reference, original request, current state, assigned owner, approved action and destination receipt. Chat messages can support that record, but a long conversation should not be the only way to reconstruct it.
Preserve relationships. An exported list of messages is less useful if attachments, source versions and customer IDs no longer connect. Ask whether the export includes stable identifiers and timestamps, and whether you can map them to the records in your own systems.
For sensitive information, portability does not mean copying everything everywhere. Export only what the next operator needs, protect it appropriately and follow the applicable retention rules. Keep a manifest describing what you included and intentionally excluded so a missing attachment is not mistaken for a complete record.
Store approved instructions and business rules in readable documents under your control. Identify which rules belong to the business and which settings are specific to the vendor. Another provider may interpret the same prompt differently; portability of text does not guarantee equivalent behaviour.
What belongs in a small exit bundle
| Item | Why it matters |
|---|---|
| Open-work register | Shows what still needs an owner or action |
| Business rules and source versions | Explains which decisions are valid |
| Action ledger and receipts | Prevents repeating completed sends or updates |
| Representative test cases | Checks the replacement against the same job |
| Connection inventory | Identifies permissions to reconnect or revoke |
| Manual operating instructions | Keeps essential work moving during the switch |
Use ordinary formats where practical: CSV for a simple register, JSON for structured relationships, text or Markdown for instructions, and original documents for evidence. Preserve encoding and timezone information. A Thai name corrupted during export is a practical migration failure, even if the row count matches.
You do not need to reproduce every vendor feature. Decide which historical records must remain searchable, which must remain auditable and which active workflows must resume. Those are different requirements and can have different solutions.
A portable case should explain its next action
Fictional portable work item Work ID: ENQ-419 Customer reference: CRM-882 Request received: 2026-10-20T09:15:00+07:00 Status: approved, send not yet attempted Approved draft: draft-3 Recipient reference: verified contact on CRM-882 Policy version: COURSES-2026-10 Approval actor and time: recorded internally Send receipt: none Next owner: course coordinator Next action: recheck availability. Send only if the draft remains accurate and approval still applies; otherwise revise and obtain required approval. Different item, send status unknown: Next action: reconcile destination before sending again.
The distinction between not attempted and unknown prevents a replacement system from treating all incomplete records as safe retries. A migration can create duplicates even when both the old and new products work exactly as designed.
Include the old system's final processing position or cutoff time where relevant. Events arriving around the switch need an explicit owner. Without one, each system may assume the other handled them, or both may process them.
Rehearse a narrow exit before you need it
Pick a small, safe sample containing an open case, a completed case, an exception and a case with an attachment. Export it using the actual account and plan you operate. Read the result with ordinary tools or the proposed destination, then reconstruct each case without reopening the vendor interface.
Have the normal operator try the manual instructions. If they need the original builder to explain every field, improve the handoff. Record the time and missing information; these observations give a more useful estimate of switching effort than a promise that everything is exportable.
For a replacement trial, keep action execution disabled. Feed the same safe inputs to both systems and compare proposed outcomes. Do not let two live automations write to the same customer thread while you are still deciding which one should own it.
A manual fallback may be enough for a small team. Buying and maintaining a second AI provider merely for theoretical portability can add cost and complexity. Invest first in clean records, understandable rules and a workable interruption plan.
Make the switch a controlled handoff
Choose a cutoff, pause the old action path and record its pending work. Reconcile actions with uncertain outcomes. Transfer the remaining queue with stable business identifiers, then enable the replacement for a limited set of work. Keep the old system available for readback if your contract and retention requirements allow it.
Revoke old credentials after you confirm that the new path owns the work and no required job still depends on them. Deleting access too early can destroy your ability to reconcile an uncertain action; leaving it indefinitely can allow the retired automation to resume unexpectedly.
Exit rehearsal worksheet Workflow and owner: Essential outcome during interruption: Export tested on actual plan and account: Stable IDs and relationships preserved: Open, completed and unknown states preserved: Attachments and source versions readable: Manual operator completed sample: Old workflow pause and queue policy: Replacement acceptance evidence: Credential revocation owner and timing:
Ask for this demonstration before a major expansion or renewal. The result may be that your current supplier is still the best fit. You will nevertheless know that the business process belongs to your team and can survive a change in the tool that runs it.
Sources and dates
Sources checked on 20 October 2026. Worked examples are teaching examples unless explicitly attributed. Provider documentation describes product behaviour; the operating recommendations are DLVX editorial judgement.
- OpenAI deprecationsPublished model and endpoint retirements illustrate dependency lifecycle risk; the exit method is editorial guidance. Checked 2026-10-20.