Leaving a Platform? Four Export Routes Compared, and the Paperwork That Decides Which You Get

The question of whether you can get your data out has an answer long before you ask it. It was settled when somebody clicked through the terms at signup, and it was settled again every renewal after that. By the time a migration is live, you are not negotiating. You are discovering what was already true. Anyone who has moved a company off a billing system, a CRM, a document store and a media library learns to run the discovery first and the decision second.

What follows is how the four practical export routes compare, what each one actually produces, and the small stack of paperwork that turns a vague entitlement into files on a drive you control.

The four routes, and what each one really gives you

Nearly every exit runs on one of four mechanisms. They differ in cost, in fidelity, and in how much of the vendor's attention they require.

Route	Typical output	Who controls the clock	Main failure mode
Self-serve export in the admin panel	CSV or ZIP per module, often capped by row count or date range	You	Silently drops attachments, custom fields, audit history
API pull	JSON, complete down to field level if the endpoints exist	You, within rate limits	Some objects have no endpoint; pagination errors go unnoticed
Vendor-assisted extract	Database dump or structured archive delivered to storage you name	The vendor	Priced as professional services and queued behind other work
Manual capture	Screenshots, printed PDFs, retyped records	You, expensively	Transcription error, and it does not scale past a few hundred records

Most real migrations use three of the four. The self-serve export carries the bulk, the API fills what the export omits, and manual capture handles the handful of configuration screens that exist nowhere else: permission matrices, workflow rules, email templates, the tax table somebody built in 2019. Vendor-assisted extract is the route you reach for when the relationship is ending well and you have budget, or when it is ending badly and your contract compels it.

Format tells you how much rebuilding is ahead

A file you can open is not the same as a file you can load. The gap between the two is where migration budgets go.

CSV is the most common and the least informative. It flattens relationships, so a customer with four addresses and nine invoices arrives as rows that no longer know about each other. You can rebuild the links if every row carries the original system's record ID. If the export strips IDs in favor of display names, you are matching on text, and text has duplicates. Check for an ID column before you accept a CSV route as sufficient.

JSON from an API preserves structure and usually preserves the fields that the user interface never showed you: creation timestamps, soft-delete flags, the user who last touched a record. That history matters more than people expect. It is what lets you answer a question about a transaction from three years ago after the old system is gone.

Media is its own problem. Images, audio and video export as files, but the context that made them useful is held in the database: who uploaded what, which album or matter or job it belonged to, the captions, the order. An export that hands you forty thousand files named by hash is technically complete and practically useless. Ask for the manifest, a file that maps each asset to its original record. If the vendor cannot produce one, plan on generating it yourself from the API before you give notice.

Scale shapes the answer here. A venue coordinator running a qr code photo album for a single event may be dealing with a few hundred images and a download link, which is a weekend of filing at worst. A firm with eleven years of client galleries is in a different conversation entirely, and the difference is almost all about the manifest.

The paperwork that decides which route you get

Five documents do most of the work. Pull them before you shop for a replacement, not after you have signed one.

The master agreement and its termination section

Look for a return-of-data clause. Good ones state a format, a delivery window measured in days after termination, and whether assistance is included or billed. Weak ones say the provider will make data available for a reasonable period, which means the period the provider considers reasonable. If the clause is weak and you are mid-term, the renewal conversation is your opening to fix it.

The data processing addendum

Even for purely domestic operations, the DPA is often where deletion and return obligations are stated most precisely, because it was drafted to satisfy privacy regimes rather than sales targets. It frequently gives you a cleaner entitlement than the commercial agreement does.

The retention and deletion schedule

Two numbers matter: how long the vendor keeps your data after you stop paying, and how long backups persist after that. The first is your safety margin if an export turns out to be incomplete. The second is what you cite when a client asks whether the old copy is really gone.

A dated written export request

Send it by email, name the systems and date ranges, name the formats you want, and ask for confirmation of the retention window. This single message converts an informal support ticket into a record. When a migration slips and someone asks what was requested and when, the thread answers it. The Federal Trade Commission is responsible for how companies represent their data practices to customers, and a vendor's written commitments are a good deal more durable than a verbal one from a support agent who may change roles next quarter.

Your own inventory

One spreadsheet: every data object, where it lives, record count, who needs it after the move, and whether a legal or tax retention obligation attaches. Record counts are the point. They are what you compare after import.

The sequence that keeps a migration from slipping

Order matters more than tooling. This is roughly how it goes when it goes well.

1. Run a test export during the trial, not at the end. Before you commit to any platform, export a sample and try to load it somewhere else. You learn in an hour what the sales call will not tell you in a year.
2. Take the inventory and the record counts before giving notice. Counts taken after the account goes read-only are counts you cannot verify.
3. Do a full dry run while the old system is still live. Export everything, import everything, reconcile, and list what broke. Nothing about this step is wasted; the second pass reuses the mapping.
4. Keep both systems running through one full business cycle. A month-end close, a quarterly filing, a billing run. Cycles surface the fields nobody mentioned.
5. Reconcile on counts and on spot checks. Totals confirm nothing arrived short. Pulling twenty records at random and reading them confirms the contents survived.
6. Archive the raw export separately from the new system. Store the original files, unmodified, on storage you own. If the new platform mangles something in year two, the raw archive is the only version that still reflects the source.
7. Get deletion confirmed in writing, then cancel billing. In that order.

The running cost of software has never been only the subscription. It includes the day you leave, and that cost is set years earlier by a clause most buyers skip. Read the termination section before the pricing page, keep the inventory current, and the exit becomes a scheduled project with a known shape rather than an emergency.