What to Check About Data Export and Vendor Lock-In Before Subscribing

A service can offer a download button and still be difficult to leave. The export may be incomplete, delayed, available only to a particular account owner, or delivered in a format that another service cannot reconstruct. Conversations may move while projects, memories, custom instructions, agent settings, shared workspaces, permissions, citations, evaluation history, and integrations remain behind.

That is why data portability should be tested as a workflow, not accepted as a marketing claim. The useful question is not “Can I download something?” It is “Can I preserve the records and operating context needed to continue the work somewhere else?”

NIST’s AI Risk Management Framework treats benefits, costs, assumptions, responsibilities, monitoring, and lifecycle decisions as connected concerns. Official provider documentation also shows that export coverage can differ by plan, workspace type, owner role, and product surface. The following audit turns those constraints into an exit test that can be completed before a subscription becomes operationally critical.

1. Inventory the data and workflow before choosing a provider

Start with what the workflow creates, not with the provider’s export page. List the assets that must survive a move.

Typical assets include:

• conversations and generated outputs;
• uploaded source files and extracted text;
• projects, folders, collections, or knowledge bases;
• prompts, templates, custom instructions, and saved agents;
• citations, source locations, evaluation notes, and approval records;
• user roles, sharing rules, workspace memberships, and audit logs;
• API keys, webhooks, connectors, scheduled jobs, and automation state;
• usage, billing, latency, error, and quality measurements.

Mark each asset as required, useful, or disposable. A personal brainstorming tool may need only conversations and final files. A production workflow may also require permissions, version history, source evidence, and reproducible configuration.

Without this inventory, an export can look complete while omitting the assets that make the workflow usable.

2. Distinguish an archive from a reusable migration package

An archive proves that data can be downloaded. It does not prove that the work can continue.

A reusable migration package needs enough structure to answer questions such as:

• Which message belongs to which conversation or project?
• Are timestamps, authors, roles, source links, and attachments preserved?
• Can custom prompts or agent instructions be reconstructed?
• Are file names and formats intact?
• Can another tool import the data, or must a person rebuild everything?
• Does the export preserve relationships between records, or only flattened text?

OpenAI’s current help documentation, for example, describes exporting conversation and account data, while separate transfer guidance explains that exported conversations used in another account do not recreate the original sidebar, separate chats, subscription, workspace membership, memories, GPTs, or account settings. That distinction is the difference between archival access and operational portability.

Record the export format and the work needed to make it usable elsewhere. JSON, CSV, Markdown, and original files are usually easier to inspect than screenshots or proprietary containers, but format alone is not enough. The schema and relationships also matter.

3. Verify export coverage for the exact account and workspace

Do not assume that an individual account, team workspace, education workspace, and enterprise environment have identical controls.

Check the exact plan and role you would use:

• Is export available to ordinary members or only an owner or administrator?
• Does the export include personal data, workspace data, or both?
• Are shared projects and organization-level records included?
• Are audit logs exported separately?
• Does data residency or another configuration change eligibility?
• Can a departing employee request an export, or must an administrator act?
• Does canceling the plan remove export access before the archive is ready?

Provider documentation can change, and the account interface may not match a general help article. Verify the active settings in a trial workspace and capture the date, role, and plan used for the test.

For team use, assign an owner for periodic exports and an alternate owner for recovery. Portability that depends on one person’s account is a continuity risk.

4. Inspect the exported files and metadata

Request an export early, while the test account contains only non-sensitive representative data. Do not wait until cancellation.

Inspect the package for:

• file names, extensions, encoding, and compression;
• conversation identifiers and project relationships;
• timestamps and time zones;
• message roles and editing history;
• source URLs, quotations, and citations;
• uploaded and generated files;
• settings, instructions, and configuration records;
• deleted, archived, shared, and temporary content behavior;
• a manifest or schema description.

Open several records manually and parse the package with a simple local tool where possible. Count expected conversations and attachments. Compare hashes for original files. Check whether non-English text, long documents, tables, and code blocks survive intact.

An export that succeeds technically but loses identifiers, source evidence, or attachment relationships may still fail the business requirement.

5. Reconstruct a representative workflow in an alternative

The strongest portability test is a small restore rehearsal.

Choose one representative workflow and rebuild it in an alternative service or a neutral local format. The test should include:

1. one normal conversation or project;
2. one uploaded source file;
3. one reusable prompt or instruction set;
4. one generated output that requires source verification;
5. one approval or decision record;
6. one shared or permission-sensitive item if collaboration matters.

Measure what transfers automatically, what can be converted, and what must be rebuilt manually. Record the elapsed time and any lost behavior.

A successful rehearsal does not require identical user interfaces. It requires preservation of the evidence and context needed to continue the job without relying on inaccessible memory or screenshots.

Classify the result:

• portable — required assets transfer or can be reconstructed with documented, bounded work;
• partially portable — core records move, but important configuration or relationships require manual repair;
• locked in — critical assets, permissions, or workflow state cannot be recovered at acceptable cost.

6. Map hidden dependencies beyond the visible data

Vendor lock-in often comes from dependencies rather than stored text.

Inspect:

• proprietary prompt or agent features;
• provider-specific retrieval indexes and embeddings;
• connectors that cannot be recreated elsewhere;
• API response formats and tool-call schemas;
• custom functions, authentication, and permission mappings;
• model-specific behavior embedded in acceptance criteria;
• dashboards, alerts, evaluations, and billing reports;
• organization policies tied to the provider’s controls.

A workflow may export all conversations and still be expensive to move because its approval logic, monitoring, or integrations depend on provider-specific behavior.

Reduce this risk by keeping important prompts, schemas, test cases, acceptance criteria, and source records in a provider-neutral repository. Store business state outside the model conversation when possible. Treat the provider as an execution component, not the only system of record.

7. Calculate migration and exit cost before scaling

Portability has a cost even when the export is complete. Estimate it before expanding usage.

Include:

• export request and waiting time;
• parsing, conversion, and validation work;
• manual rebuilding of prompts, agents, projects, and permissions;
• re-indexing source documents;
• regression testing in the replacement service;
• security and privacy review;
• parallel operation during migration;
• user retraining and documentation updates;
• downtime, delayed work, and rollback capacity.

Use a scenario rather than one number:

Compare this cost with the benefit of the product. A high-value service can justify meaningful switching cost, but the dependency should be explicit rather than discovered during an incident.

8. Set exit triggers and repeat the export rehearsal

Portability changes as products, plans, and workflows evolve. A test performed before adoption can become stale after new features or integrations are added.

Define triggers for a new export and restore rehearsal:

• plan or workspace migration;
• major pricing or contract change;
• critical new integration;
• increased sensitivity of stored data;
• change in export eligibility or administrator role;
• repeated service outage;
• quality decline or unmet support obligation;
• merger, acquisition, product retirement, or strategic exit decision.

For important workflows, schedule periodic exports to a controlled location and verify that the archive can still be opened. Record the export date, source account, workspace, plan, file hash, expected record count, test result, and unresolved gaps.

Do not keep exports longer than necessary. They may contain sensitive conversations and uploaded files. Apply access control, encryption, retention, and deletion rules that match the original data classification.

Data portability decision matrix

Warning signs before subscribing

Pause adoption when:

• export availability differs across plans but the target plan is unclear;
• the provider cannot describe what is excluded;
• shared workspace records depend on one owner;
• the export cannot be inspected without proprietary software;
• conversations move but source files, settings, or evidence do not;
• the workflow relies on provider-specific agents with no neutral specification;
• cancellation may remove access before the export is complete;
• no one has performed a restore rehearsal;
• the product would become the only record of an important decision.

These signs do not automatically disqualify a product. They indicate that the switching cost must be understood and controlled before the workflow expands.

A short pre-subscription portability checklist

• List required data, settings, relationships, and integrations.
• Verify export eligibility for the exact plan, workspace, and role.
• Request a trial export with non-sensitive representative data.
• Inspect file formats, identifiers, metadata, and attachments.
• Reconstruct one representative workflow elsewhere.
• Record manual repair time and lost behavior.
• Store prompts, schemas, tests, and decisions outside the provider.
• Estimate normal and emergency exit cost.
• Assign an export owner and backup owner.
• Define a review date and exit triggers.

Sources reviewed

• NIST AI RMF Core (opens in a new window)
• OpenAI: Exporting your ChatGPT history and data (opens in a new window)
• OpenAI: Transfer exported conversations between ChatGPT accounts (opens in a new window)
• Google: Download your Gemini Apps data (opens in a new window)
• Google: Download your data (opens in a new window)
• Anthropic: Export Claude data (opens in a new window)