What a No-Code AI Platform Doesn't Let You Export

Ask a builder platform whether you can export your work and the honest answer is usually yes — for the parts that have a text representation. The migration estimate that goes wrong is the one built from that answer, because the parts with no text representation are the parts that took the longest to build.

Three kinds of thing that will not move

“Cannot export” covers three mechanically different situations, and conflating them produces a bad plan. Sort every component of your application into one of these before estimating anything.

• No format. The thing exists in the platform’s database, and the platform will even show it to you, but there is no defined serialisation because there is no other system that would read it. Visual flow graphs are the archetype. Cost: rebuild from a specification you write by reading the UI.
• No access. The artefact has a perfectly good format and the platform simply does not hand it over — computed embeddings, derived indexes, evaluation history. Cost: recomputation, which is money and time rather than design work, and is therefore the easiest of the three to plan for.
• No equivalent. The behaviour depends on a managed service that has no counterpart in the destination. A platform-run moderation layer or a built-in conversation store is not a file you are missing; it is a subsystem you did not know you were relying on. Cost: a build decision you have not made yet.

Workflow logic has no interchange format

The canvas of nodes and arrows is the platform’s product, and it is stored in a private graph representation. Some platforms export it as JSON; that JSON is a dump of their node types and their edge semantics, which means it is readable but not portable, because nothing else implements those node types.

What actually resists translation is not the shape of the graph but the implicit semantics attached to it. A visual branch node carries a rule about what happens when no branch matches. A loop node carries an iteration cap. An edge between two nodes carries an assumption about what part of the previous node’s output is passed on — the whole object, one field, or a merged accumulator. None of that is written anywhere in the export; it is in the runtime’s behaviour, and you learn it by testing the live system before you turn it off.

The practical consequence: your export is a starting inventory, not a source of truth. Treat the graph JSON as a list of nodes to account for and answer, per node, what its failure behaviour and its data-passing rule are. That mapping is the substance of rebuilding the flow as explicit code.

Managed retrieval is the expensive one

If the platform hosts your documents and answers questions over them, several distinct artefacts are involved and they have different export stories.

• Source documents. Usually retrievable, sometimes only as the processed text rather than the original file. If you uploaded PDFs and can only get the extracted text back, you have lost the ability to re-extract with a different parser later, which is a real capability to give up.
• Chunk boundaries. Rarely exported and rarely documented. Chunk size, overlap and the splitting rule determine what the retriever can find, and a rebuild with different boundaries is a different retriever with the same documents. Expect chunking to be the variable you have to re-derive by experiment.
• Embeddings. Almost never exported, and less of a loss than it appears — vectors from one model are meaningless to another, so unless you are keeping the identical embedding model you were going to recompute regardless. Budget the recomputation cost and move on.
• Retrieval configuration. Top-k, the similarity metric, any reranking stage, metadata filters, score thresholds. These are usually visible in the UI and absent from any export, and they are exactly the knobs that make the difference between a retriever that works and one that returns plausible irrelevance. Copy them out by hand, in the same pass where you copy the prompts.

The thing to internalise: retrieval quality was tuned, implicitly, by whoever built it clicking until the answers looked right. That tuning is not in any file. Rebuilding it means re-running that loop, which needs an evaluation set you should construct while the old system is still up and can be queried for reference answers.

State, history and the things with no schema

Three more categories that are easy to miss until the account is closed.

Conversation history. If the platform stores threads, those threads may be exportable as a bulk dump, per conversation, or not at all. Whether you need them is a product question — but it is also increasingly a data-protection question, because a subject access request or a deletion request against data you can no longer read is an obligation you cannot discharge. Establish the answer before the contract ends rather than after.

Evaluation and feedback data. Thumbs, ratings, manual annotations and test-run history accumulate over the life of the project and represent real human effort. They are frequently the least exportable thing in the product and the most expensive to recreate, because recreating them means asking people to label things again.

Integration credentials and connections. Anything OAuth-connected exists as a token the platform holds and will never give you. Every third-party connection is a fresh integration to build and re-authorise in the destination, and the count of them is often the real schedule driver.

Assessing the cost before you commit

Run this assessment while you still have full access, and write the answers down where the migration plan can be read against them.

1. Trigger every export the platform offers and open each file. The gap between what the documentation says is exported and what the file contains is the single most useful number you will get, and it takes an afternoon.
2. For each artefact that did not come out, classify it as no format, no access or no equivalent, and write the rebuild path next to it. A component you cannot write a rebuild path for is a component you have not understood yet.
3. Capture behaviour, not just configuration. Screen recordings of the flow under normal and error conditions, plus a fixture set of real inputs with their outputs, are how you preserve the semantics no export contains.
4. Check the retention and deletion clauses in your own agreement for how long the account remains readable after cancellation, and whether export access survives non-payment. Plan the extraction to finish well inside that window. What such clauses mean in general and what to ask for is a separate exercise in reading your own contract, not something to discover during the final week.