Every managed AI platform has an export button, and the export button is not the answer to this question. What you own is what you can rebuild somewhere else. Some of what a platform holds for you passes that test trivially, some passes it only if you kept something you probably did not, and some does not pass it at all.
The only question that matters
The instinct when planning an exit is to inventory what the platform will hand back. That is the wrong inventory, because a file you cannot use is not an asset. A managed vector index will happily export as a few million rows of floats, and those floats are worthless the moment you stop calling the embedding model that produced them.
The useful question is narrower and harsher: can I reconstruct this artifact, to the same quality, from inputs I hold, using a component I can obtain elsewhere? Three answers are possible. Yes, cheaply — it is text and you have it. Yes, at a cost — you hold the inputs but rebuilding burns compute and then requires a verification pass. No — the inputs were never yours, or the transform is not reproducible, or the artifact is a server-side object that never had a downloadable form.
Sorting your stack into those three answers takes an afternoon and it is the whole of migration planning. Everything else — the schedule, the dual-run window, the budget — falls out of it. What follows is how the components of a typical managed stack usually sort, and why.
Tier one: things you already own
Text is portable. This sounds trivial and it is the reason the tier exists: an artifact whose canonical form is a string, and whose meaning does not depend on which model reads it, moves without loss. That covers more than people expect.
- Prompt text. The literal strings, including the system prompt, few-shot examples and any templating. Portable as bytes. Not portable as behaviour — the same string produces different output on a different model family, which is a separate problem covered in what breaks when prompts move between families. But nothing is lost in the transfer itself.
- Source documents. The PDFs, tickets, wiki pages and database rows you fed into retrieval. If these live in your own systems and the platform merely read them, you have lost nothing. If you uploaded them and deleted your copy, they are in tier three and you should fix that today rather than on the way out.
- Evaluation cases. Inputs and expected outputs are text. A golden dataset is the single most valuable thing you can carry across a migration, because it is what tells you the new stack works.
- Conversation transcripts, to the extent the export includes them — and the extent is smaller than it looks, which is what what conversation exports leave out is about.
Tier two: derived artifacts
These are computed from tier-one inputs by a component you may or may not be able to obtain again. You can rebuild them; you cannot copy them.
Embeddings and the index built from them. An embedding is a coordinate in one specific model version’s space. Two models’ vectors are not comparable, so a swap means re-embedding the entire corpus, not translating the vectors. That is real compute against your whole document set, and it is the largest single line item in most migrations. It also invalidates every tuned number downstream: similarity thresholds, top-k, reranker cutoffs and any score-based filter were fitted to the old distribution and have to be refitted.
Chunking. If the platform chose your chunk boundaries, the boundaries are not in the export in any reusable form — you get chunks, not the splitter that produced them. Reproducing retrieval behaviour means reimplementing a chunking strategy you were never shown. If you configured the splitter yourself, this drops to tier one.
Fine-tunes. The distinction that matters here is between the training file and the trained artifact. The training file is text you uploaded and it is tier one. The resulting weights or adapter are usually a server-side object with no download path, and even where one exists the artifact is tied to a base model you cannot take with you. Re-running the job elsewhere is a different job with a different base, a different tokenizer and different hyperparameters — see re-running a fine-tune on a new provider. Keep the training file, in its original form, outside the platform.
Tier three: hosted state
The last tier is the one that surprises people, because none of it feels like data. It is configuration, and configuration expressed in a proprietary form is not portable at any price — it is a rewrite.
- Workflow and graph definitions. A pipeline built in a visual editor or a platform-specific DSL exports, at best, as a description of itself. There is no runtime elsewhere that consumes it. Budget this as reimplementation, in engineer-days, not as a transfer.
- Connector and tool configuration. Which tools were exposed, with what schemas, under what auth. Usually recoverable by reading the console, rarely present in an export.
- Guardrail and policy configuration. Thresholds, blocked categories, allowlists. The values are portable; the classifier they were tuned against is not, so the values are starting guesses on the other side.
- Evaluation history and observability. Run records, traces, score history. This is the record of every decision you made and why, and it is typically the least exportable thing in the stack. Losing it does not break the new system — it removes your ability to explain the old one.
What to do before you need this
The pattern across all three tiers is the same: an artifact is portable to the degree that you retained the input that produced it. That is a decision you make while everything is working, not while you are leaving, and it costs almost nothing at the time.
- Keep the input next to every derived artifact. The document, not just the chunk. The training file, not just the fine-tune id. The raw request and response, not just the score.
- Log the reproduction key on every call. Model identifier including version, the prompt version, the parameters, and the request id the provider returned. Without those, a transcript is a story rather than a record.
- Run the export once, now, while you are happy. An export you have never opened is an assumption. Opening it is how you discover which tier each artifact is really in — and you would much rather discover that this quarter.
- Keep the golden dataset outside the platform. It is the cheapest artifact to preserve and the one that determines whether a migration can be verified at all.
None of this is an argument against managed platforms. They are worth it precisely because they hold state for you. The argument is that the state they hold should be derivable from something you keep, so that the day you leave is an engineering schedule rather than a negotiation. For the component-by-component version of this assessment, with a score at the end, see the lock-in checklist by component.
Top comments (0)