Migrating Off a SaaS AI Platform Without Losing Your Agent

What can you actually export from a SaaS AI platform?

Three classes of asset, and they behave very differently on the way out.

Prompts and skill definitions. These are the instructions that tell the agent what its job is and how to do it. On almost every platform they are plain text or structured text, and you can copy them out. If they were written as documentation a person could follow, they are fully portable. If they were built by clicking through a visual editor, you may be exporting a screenshot of a flowchart rather than something a new runtime can execute. Check which one you have before you need to know.

Memory and context. This is everything the agent learned while operating: preferences, corrections, facts about your customers, the running state of long tasks. Some platforms let you export it as structured data. Many expose only conversation history, which contains the memory in raw form but not in a shape a new agent can load. A few retain it entirely on their side. This is the asset most likely to be lost, and the one to ask about hardest before you sign anything.

Integration credentials. API keys, OAuth grants, service accounts for your CRM, your email, your accounting system. These were always yours. The platform held copies. You rotate them, point the new deployment at the same systems, and the platform's copies stop working. This class is the easy one, and the one to do first, because rotating credentials is also how you confirm the old platform no longer has access.

What you lose when you leave, and why it is usually less than you fear

You lose three things that belonged to the vendor, not to you.

• The orchestration layer. The code that decides which step runs next, retries on failure, and routes work between tools. Every platform has one. None of them export it, because it is the product.
• The interface. The chat window, the dashboard, the approval buttons. Rebuildable, and often better rebuilt as a channel your team already uses, such as Telegram, Slack or email, rather than as another tab.
• Vendor-specific tool wrappers. The connectors that let the agent talk to your CRM through the platform's abstraction. The underlying APIs on your side are unchanged; only the wrapper has to be written again.

All three are rebuildable in days to weeks rather than months, on one condition: that the skills were written as documentation. If the logic of what the agent does lives in readable procedures, a new harness can run them. If it lives only in the vendor's visual builder, you are reconstructing it from memory, and that is where migration timelines go wrong. The customer-owned infrastructure article covers why we insist on skills as documents from the first day of every deployment.

How long does an AI platform migration take?

It depends almost entirely on where the logic lived, not on how much of it there is. These are the ranges we scope against, stated as ranges because every real case has a detail that moves it.

Starting position	Typical range	What dominates the timeline
Skills written as documents, under five integrations, memory exportable	Two to four weeks	Credential rotation and re-testing each integration against live data
Skills partly in a visual builder, five to fifteen integrations, memory exportable as history only	One to three months	Rewriting builder logic as procedures and reconstructing memory from conversation exports
Logic exists only inside the vendor platform, memory not exportable	Treat as a new deployment, not a migration	Discovery. You are re-scoping what the agent should do, informed by what it used to do

The honest instruction for the third row is to stop calling it a migration. Nothing is moving. You are deploying a new agent that happens to do a job an old one used to do, and scoping it as such produces a better result than trying to replicate a system you can no longer inspect.

The export checklist to run before you commit to any AI vendor

Run this before signature, and get the answers in writing. A vendor that cannot answer a question precisely has answered it.

1. What can I export? Prompts, skills, memory, logs, conversation history. Ask for the list by name, and ask which items are excluded.
2. In what format? Structured data that another system can load, or a PDF of the dashboard. The difference is the difference between a migration and a rebuild.
3. On what notice? Immediately through a self-service control, or by request with a turnaround time. Thirty-day turnarounds are common and are a problem if you are leaving because something broke.
4. Is export still available after termination? Many platforms disable export the moment the subscription lapses. Confirm the window and put it in the contract.
5. Where do the logs live, and can I read them without you? If the audit record of what the agent did lives only on the platform, you lose it when you leave, and you may need it afterward.
6. Can I rotate my own integration credentials unilaterally? You should be able to cut the platform off from your systems without asking.
7. Which model provider does the agent call, and under whose account? If the model relationship is the vendor's, your usage history, your negotiated terms and any provider-side data controls stay behind.

Why customer-owned deployment makes this question disappear

When the agent runs inside your own AWS, GCP or Azure account, there is no export step, because there is nothing to export from. The prompts, the skills, the memory, the logs and the credentials are already files and records in infrastructure you control. Changing vendors becomes a question of who maintains the system, not whether the system survives the change. That is the whole design argument behind Sovereign Agent, and the comparison page lays it out against the SaaS alternatives on ownership, data residency and exit risk. For the mechanics of how the deployment is isolated and who holds the keys, see the security baseline; for what the deployment costs, including the cloud and model spend that is billed to you directly, see pricing.

Ownership does not make the migration question trivial for your next vendor. It makes it a configuration change rather than a project, which is the most honest claim anyone in this category can make.