Planning an Exit from an Agent Knowledge Platform
A practical guide to evaluating license risks, securing knowledge export portability, preserving metadata provenance, and executing vendor lock-in migration plans.
Key takeaways
- Separate three outcomes: A backup supports restoration to the same system; a portable export makes data interpretable outside it; a migration proves a different product can use the needed data and workflows.
- Inventory what matters before choosing a format: Record content, identifiers, relationships, permissions, attachments, tables, provenance, integrations, and any required history, then mark each item included, excluded, or rebuild-required.
- Prove the replacement independently: Import representative data into a restricted staging environment, test real tasks and access boundaries, reconcile changes to an agreed cutoff, and document losses, effort, limits, and rollback conditions.
- Negotiate exit terms for your workload and risk: Agree on owners, dates, costs, formats, continued access, acceptance criteria, retention exceptions, and deletion evidence rather than relying on universal timelines.
- Retest when risk changes: Rehearse after material schema, export, integration, or access-control changes; do not treat Git history, format validation, or matching record counts as proof of a complete migration.
An exit plan should show how an organization could recover its knowledge and move it to another system. This guide focuses on a practical test of what can be recovered, what can be interpreted elsewhere, and what must be rebuilt. It is a technical and procurement planning guide, not legal advice; have counsel review applicable licenses, contracts, and retention obligations.
Three different exit tests
“Can we export it?” is not a complete exit test. Define which of these outcomes you need:
| Test | What it establishes | What it does not establish |
|---|---|---|
| Backup and restore | A backup can be restored to a supported recovery environment, with the required application dependencies and configuration. | That another product can interpret the data, or that all external assets and identity settings were backed up. |
| Portable export | Data and documentation can be read outside the source platform in a documented format with identifiers, structure, and context. | That a replacement product can ingest it or reproduce the same behavior. |
| Cross-product migration | A target system can import mapped data, maintain required relationships and access boundaries, and support representative work without depending on the old platform. | Exact agent answers, identical indexing, or zero migration effort. |
Treat these as separate workstreams. Git history may preserve revisions of files in a repository, but it is not a complete backup of a system that also stores database records, object bytes, identity/access state, configuration, or external services. A successful restore into the same product is useful evidence, but it is not proof of cross-product portability.
Establish the exit scope and decision rights
Start by naming an accountable technical owner and the procurement or legal owner. Agree what is in scope, who can approve the target mapping, and which business tasks must continue during a transition. Review the license for the exact deployed version, applicable dependency licenses, contribution or commercial agreements, and the rights needed to retain, export, transform, and use the material in a replacement. Source access or self-hosting alone does not remove execution or operational lock-in: dependencies, license conditions, build and deployment skills, and the ability to operate the service still matter.
License questions are version- and agreement-specific. Permissive licenses and copyleft licenses can impose different conditions on distribution of modified or combined software; “modifications allowed” does not mean every license requires every derivative to use identical terms. Future releases may use different terms where the relevant rights and agreements permit it, but that does not by itself erase valid permissions already granted for an earlier version. For BSL 1.1, review the exact license text and its Additional Use Grant; restrictions are not one universal seat or revenue rule. Do not infer relicensing authority from the presence of a CLA or CAA alone: review the rights actually granted, ownership, relevant contributions, and dependencies. This guide does not decide those legal questions.
Before a contract is signed or an exit begins, document the negotiated arrangements for the workload and risk: accountable contacts, trigger and delivery dates, export format and method, transition access, assistance and cost, acceptance tests, backup retention/expiry, legal holds or other retention exceptions, deletion timing and exceptions, and what evidence the provider will supply. Distinguish primary-system deletion from backup expiry and deletion by subprocessors. Confirm which records must remain under a legal hold or other retention duty, who can authorize release, and what happens to copies that cannot be deleted immediately. Set dates and acceptance thresholds with the parties; there is no universal timeline or test cadence that fits every service.
Build an export inventory
Use formats the target can interpret and that have documented structure. JSON, CSV, Markdown, and YAML may be useful components, but a file extension alone does not preserve meaning. For each row below, record the source, owner, extraction method, target mapping, inclusion status, any exclusions or rebuild work, and validation evidence. Mark sensitive fields and keep secrets out of exports; reissue credentials separately through the target’s approved process.
| Data area | Inventory and mapping questions | Disposition and evidence to capture |
|---|---|---|
| Documents and metadata | Are original text or Markdown, YAML/frontmatter or equivalent metadata, stable IDs/URIs, source references, versions, and timestamps included? | Mark included, excluded, or transformed; map IDs and fields to the target and compare sampled records. |
| Revision history | Is historical content, diffs, authorship, or timestamps required for business, audit, or recovery needs? | Export only the history required and permitted; state what is unavailable and test selected historical versions. A current snapshot is not history. |
| Attachments and inline media | Are the actual bytes included, not only links? Record MIME type, size, stable reference, and checksum. | Verify sampled bytes and checksums after import; remap references. A pointer or catalog entry is not the asset itself. |
| Tables and structured records | Capture table schemas, column names and types, constraints if relevant, actual rows, stable keys, and null/encoding behavior. | Map types and keys; compare row counts and test representative values and relationships. A schema without rows is not a table export. |
| Relations and provenance | Include relation edges, source-to-claim links, source revision references, and the meaning of each relationship. | Map identifiers and edge types; test links resolve and provenance can be followed to the intended source version. |
| Approvals and audit evidence | Determine whether approvals, access changes, administrative actions, and audit records are required and exportable. | Record retention requirements and omissions; verify a sample can answer the required audit questions. |
| Ownership and access | Inventory owners, groups, roles, ACLs, identity-provider identifiers, and inherited/public access. | Document old-to-new identity mapping and test both permitted and forbidden access. If a mapping is ambiguous, fail closed rather than broadening access. |
| Integrations and workflows | List connectors, API endpoints, schedules, prompts or workflow configuration, and downstream dependencies. Exclude credentials and secret values. | Record configuration and replacement steps; reissue credentials and test each critical connection independently. |
| Derived indexes and embeddings | Identify index contents, model/version, dimensions, chunking and preprocessing settings, and dependencies. Confirm rights and technical ability to export or reuse them. | Mark as portable, excluded, or rebuild-required. If rebuilt, record expected work, duration, and cost; prioritize preserving source content and permissions. |
| Platform and recovery configuration | Inventory database, object storage, encryption/key dependencies, deployment configuration, and backup/restore requirements. | Keep protected backup material separate from portable content exports; document restoration prerequisites and retention/expiry behavior. Never place secrets in the export. |
An export manifest should identify the snapshot and cutoff, source version, record and asset counts by type, and checksums where practical. Counts and checksums help detect missing or altered files, but they do not prove semantic completeness, valid relationships, correct permissions, or usable search results. Record known gaps and unsupported constructs instead of treating an export as complete by default.
Rehearse a migration to another product
- Agree the scope and two cutoffs. Select representative and high-risk knowledge, required history, access roles, integrations, acceptance measures, and owners. Define the initial export snapshot separately from the final cutover cutoff. Agree whether changes between them will be captured by a write freeze or delta sync, including how deletions will be recorded. Confirm contract permissions, transition access, fees, retention exceptions, and who can authorize cutover.
- Create a manifest and a protected initial export. Capture the initial snapshot time, source version, counts and checksums, schemas, identifiers, relationships, files, and configuration. Keep credentials and secrets out. Retain the original export securely and document any export size, duration, rate, or object limits.
- Run a restricted staging import. Import representative data into an isolated target environment with least-privilege access. Document field and ID mappings, unsupported structures, manual steps, work hours, duration, and dependent services. Do not assume a format validator is an importer or that an available export is a complete backup.
- Verify content, structure, and access. Reconcile counts; compare sampled document content and revisions; resolve links; check table schemas, types, rows, and attachment bytes; and test required provenance and audit records. Test authorized access, unauthorized access, revoked access, and identity mappings. Mapping errors must not grant broader access. Run representative tasks and inspect grounded answers and citations against source material; do not require exact deterministic agent wording.
- Reconcile from the initial snapshot to the final cutoff. Freeze writes or use the agreed delta-sync process. Account for every created, changed, and deleted item between the initial export and final cutoff. Apply the final delta to the target, then repeat the agreed acceptance checks against the final state. Record anything that cannot be reconciled.
- Approve, cut over, and close out. The named owner approves the final acceptance results and rollback plan before switching users or integrations. At cutover, disable obsolete write and automation credentials. Retain only specifically authorized, restricted rollback access for the defined rollback window. Confirm the replacement can operate without the old platform. After that window and approval under the closure plan, revoke remaining old access and verify retention, backup expiry, deletion exceptions, and deletion evidence under the agreement.
Set acceptance thresholds to the organization’s data volume, risk, and workload. Report export/import duration and size limits, failed or unsupported items, manual effort, rebuild time and cost, dependent services, and unresolved risks. A test is useful even when it fails: the result is a specific remediation list rather than an untested assumption. Repeat the relevant test after material changes to schemas, export behavior, integrations, identity mappings, or access controls; choose the cadence based on risk and operational change.
A scoped AKB example
The AKB public repository describes documents, tables, files, explicit relations and MCP access. Verify the storage backend and export capabilities of the deployed version rather than assuming all resource types share one history or export mechanism. Those capabilities are useful to inventory, but they do not by themselves prove that a particular deployment’s complete state can be restored or moved to another product. Test the exact deployed version and separately verify the extraction and mapping of content, file bytes, relationships, access state, configuration, and any required history. Do not treat version history or a format check as proof of a complete backup or a tested migration.
FAQ
What is the difference between a backup, export, and migration?
A backup is tested by restoring it to a recovery environment. A portable export is tested by reading its documented structure outside the source platform. A migration is tested by importing into a different product and validating the mapped content, relationships, permissions, and representative work. Passing one test does not prove the others.
What proves that an export is complete?
No single count or checksum proves completeness. Use a manifest, compare counts and sampled content, verify IDs, links, tables, attachment bytes, required history and provenance, and test access boundaries. Record exclusions and unsupported constructs, then reconcile changes and deletions through the agreed final cutoff.
Do we need to migrate embeddings and indexes?
Not always. Determine whether the target can use them and whether export and reuse are permitted. Many derived indexes may need rebuilding; record the model and version, dimensions, chunking and preprocessing settings, rebuild effort, duration, and cost. Preserve source content and access rules first.
How often should we rehearse an exit?
There is no universal quarterly requirement. Rehearse based on risk and workload, and retest after material changes to schemas, export paths, integrations, or access controls. Use results to update the inventory, mappings, estimates, and rollback plan.
Does Git history prove that I have a complete backup?
No. It may preserve file revisions, but it does not by itself prove that all database records, file bytes, permissions, configuration, dependent services, or required audit evidence are recoverable. Test backup restoration and cross-product migration separately.
When should we disable or revoke old credentials?
At cutover, disable obsolete write and automation credentials. Keep only specifically authorized, restricted rollback access for the defined rollback window. After that window and approval under the closure plan, revoke the remaining old credentials and access, then confirm retention, backup expiry, legal holds or other exceptions, subprocessors, and deletion evidence against the agreement. If access mappings are uncertain, do not broaden permissions to make the migration pass.
Run an independent migration rehearsal
Use the staging-import sequence above to test what transfers, what must be rebuilt, and whether the replacement can operate without the old platform.