A six-person insurance agency decided to leave its client management system after four years. The contract said, in plain language, that the customer owned its data. The renewal was three weeks out. Someone clicked Export, got a zip file in under a minute, and assumed the job was done. The zip contained the contact list and nothing else. Not the notes attached to each contact. Not the uploaded documents, which were the actual work product. Not the custom fields the agency had built its renewal calendar around. Those existed, and the vendor would supply them, but only through a paid professional services engagement with a four-week lead time. The renewal date arrived first.
Nothing here was hidden. The export scope was documented. Nobody read it, because nobody tried the export until they needed it to work.
Run the export while you are still a happy customer
The simplest version of this is a test export, performed now, on real data, with no intention of leaving. It takes an afternoon. It is the only method that tells you what you actually have, because the feature either produces usable files or it does not, and no amount of contract language changes which.
Do it properly. Export everything the interface offers, not a sample. Then open the files in whatever you would realistically use to read them: a spreadsheet, a text editor, the import screen of a competing product if you have a trial. Count records. If the system says you have 4,100 contacts and the file has 3,860 rows, find out why before you need the answer. The gap is usually something sensible, like archived records excluded by default, and it is usually fixable with a setting. That is exactly the kind of thing you want to discover on a quiet Tuesday.
Check the parts that are not rows in a table. Most business data has a shape that spreadsheets do not hold well: a file attached to a record, a thread of messages, a history of who changed what. Those are where exports thin out. Ask specifically whether attachments come down, whether they keep their original filenames, and whether anything in the export tells you which record each file belonged to. A folder of 9,000 PDFs named with random identifiers is technically your data and practically useless.
What your contract owes you, and where the real deadline sits
Read the data section of your agreement looking for four things. Who owns the data. What format the vendor will provide it in. How long after cancellation you can still reach it. Whether retrieval assistance costs money.
Ownership language is usually generous and usually not the constraint. Almost every vendor will state that customer data belongs to the customer. The operative clauses are the other three. A post-termination access window of 30 days is common, and 30 days is shorter than it sounds once you account for a billing cycle, a holiday, and the week it takes to realize the first export was incomplete. Some agreements shut off access the day service ends. If yours does, your migration has to finish before cancellation, not after.
Look for the word "commercially reasonable" near any promise of export help. It means the vendor decides what effort is reasonable. That is not a trap, but it tells you the obligation is soft and you should not build a timeline on it.
Also find out whether an export costs anything. Some vendors include it. Some charge for a bulk database extract or for engineering time to produce a format their standard tool does not generate. A fee is not unreasonable on its face. A fee you learn about in week three of a four-week transition is a problem. Get the number in writing while you still have leverage, which is to say before you renew.
Formats, and why three of them are not equivalent
When a vendor says you can export your data, ask which of these they mean. The differences matter more than anything else in the conversation.
| What you are offered | What it is good for |
|---|---|
| CSV or Excel files per object | Importing into another system. Loses relationships between records unless identifier columns are included. |
| JSON or XML archive | Preserves structure and nesting. Needs someone technical to turn it into a loadable file. |
| API access | Most complete and most flexible. Requires either a developer or a migration tool, and may be rate-limited. |
| PDF or printed reports | Archival only. This is a record, not data. You cannot import it. |
If the only export is PDF, you do not have portability, you have a filing cabinet. That is sometimes genuinely fine. A closed set of historical records you are legally required to keep for seven years does not need to be queryable. But decide that deliberately rather than discovering it later.
The question worth asking out loud: if identifier columns are what make a CSV export usable, why are they not in the export by default? Often they are, in a column named something unhelpful. Ask the vendor's support team to point at it. A vendor who answers that question in one email is telling you something useful about the next four years.
The rules and protections that apply from your side of the table
Business-to-business software portability in the United States is governed mostly by your contract, not by a single federal portability statute. That is the honest shape of it. There is no general rule that compels a vendor to hand a business customer a structured copy of everything on demand.
What does apply is worth knowing. The Federal Trade Commission is responsible for policing unfair and deceptive practices in commerce, which covers the gap between what a vendor advertised and what it delivers. If a product page promised full data export and the product cannot do it, that gap is a consumer protection question and not merely a disappointment. Keep screenshots of marketing claims you relied on. They cost nothing to save and they change the tone of a support escalation.
Sector rules reach further than general ones. If you handle protected health information, a business associate agreement already governs what happens to that data at termination, including return or destruction. Financial services, legal practice, and anything touching payment card data carry similar retention and handoff obligations that sit on top of the software contract. In those sectors your strongest lever is often not the portability clause but the compliance clause, because the vendor has already agreed to something specific.
Several states now grant residents rights to access and port their personal information. Those rights belong to the individuals, not to you as a business customer. They can still be relevant: if your customer base sits in one of those states, the vendor has already built machinery for producing structured personal data on request, which means the capability exists even when the self-service button is limited.
The order to run it
- Export everything today, on live data, and open every file.
- Reconcile record counts against what the system reports.
- Confirm attachments, notes, custom fields, and history are included or priced.
- Find your post-termination access window and write the date down.
- Load a sample into the system you might move to, before you commit to it.
- Only then decide whether to renew.
The agency in the first paragraph renewed for one more year, which cost real money it had not planned to spend. It also spent that year doing the export properly, in pieces, with the files landing in a folder structure it controlled. When the next renewal came, the decision took an afternoon instead of a quarter. That is the position worth getting to, and the way there is simply to try the thing before you need it.