Getting your data out: what to ask before you sign for business software
Everyone asks what a system can do. Almost nobody asks how their data comes back out if they leave.
Before signing for business software, establish that you can export all of your data, in a format something else can read, as often as you like, without asking. If any of those four is missing, the cost of leaving later is much higher than the subscription suggests, and that affects what the product is worth.
Key takeaways
- Ask how data comes out before you ask what the system can do.
- A report is not an export. An export includes the records, the relationships and the attachments.
- Test the export during the trial, with your own data, rather than trusting the feature list.
- Attachments and history are the parts most often left behind when a business switches.
- The answers tell you something about the vendor as well as the product.
Why this question gets skipped
Software is bought at the point of optimism. Somebody has found a product that solves a visible problem, a demo went well, and the conversation is about what it can do. Asking how to leave feels pessimistic, and the person asking it is the awkward one in the room.
It is also the only moment when the question has any force. Before signing you can walk away, so a vague answer costs the vendor something. Two years later, with your records inside and your team trained, a vague answer costs you.
The asymmetry is the whole argument. You are not being difficult by asking. You are asking the one question that cannot usefully be asked at any other time.
There is a quieter reason it gets skipped, which is that nobody in the room owns the question. Sales cares whether it helps them sell, operations cares whether it fits the work, finance cares about the monthly cost. Whether the data can be retrieved in three years belongs to a future problem with no present owner, so it falls off the list without anyone deciding to drop it.
The four things that make an export real
Export is a word that covers everything from a genuine complete copy to a button that produces a spreadsheet of whatever was on screen. Four properties separate them.
A sixth property matters for larger systems: whether there is an interface a program can use, rather than only a button a person clicks. For a few thousand records the button is fine. For a system that will hold years of history, or that needs to feed a report or another tool continuously, an export you can automate is the difference between a copy you actually keep and one you take once and never again.
Price all of this into the decision rather than treating it as a separate concern. A product that is slightly worse day to day but gives you a complete export whenever you want is often the better buy, because the cost of being wrong about it is recoverable. One that fits beautifully and holds your records hostage is a larger commitment than its monthly figure suggests, and should be judged as one.
- Completeness: every record type, not just the main list. Contacts, deals, notes, tasks, history, attachments, custom fields.
- Format: something another system can read, such as CSV or JSON, rather than a PDF report or a proprietary archive.
- Frequency: whenever you want, not once on departure and not as a paid service request.
- Self-service: you can do it from the interface without asking anybody, which is what makes it a right rather than a favour.
- Relationships: that the export preserves which note belongs to which customer, which is what makes the data usable rather than merely present.
A report is not an export
This is the most common misunderstanding and vendors rarely correct it, because a reporting feature can honestly be described as exporting data.
A report answers a question: these deals, these dates, these totals. An export is a copy of the underlying records with their relationships intact. The difference becomes obvious during a migration, when you have a spreadsheet of customers, a spreadsheet of notes, and no column connecting the two. The data is technically in your possession and practically useless.
So the question to ask is not whether you can export. It is whether the export preserves the relationships between records, and the way to find out is to do it and look.
A practical way to put this to a vendor without sounding adversarial: ask what a migration to their product looks like from a competitor. They will describe importing records, relationships and attachments in detail, because that is a sales conversation. Then ask what the same thing looks like in reverse. The gap between the two answers is the most honest measure of how portable the product is.
Attachments and history, which get left behind
Two categories are routinely missing and both are discovered late.
Attachments are the first: the signed contracts, the site photographs, the scanned delivery notes. Many exports produce records with a reference to a file and no file. For a business whose records are the evidence of what was agreed, that is the most valuable part of the system and the part most likely not to come with you.
History is the second: who changed what and when, and the thread of emails and notes against a record. Some systems treat that as operational rather than as data, and it does not appear in an export at all. Whether that matters depends on your obligations. For anything where you might need to show what was said and when, it matters a great deal, and backup of the underlying platform is a separate question again, which we cover in backup that actually restores.
Deleted records are a third category worth asking about. Many systems keep a recycle bin for a period and then remove items permanently, and an export taken afterwards will not contain them. If your sector expects you to be able to produce a record years later, retention is a configuration decision rather than something to assume. Microsoft documents how retention works for its own platform, and the useful habit is knowing the equivalent answer for every system holding records that matter.
Test it during the trial, not at the end
Every answer above can be verified in an afternoon, and the trial period is exactly when to do it. Put a realistic amount of your own data in, including an attachment and a few notes against a record, then export it and open what comes out.
Three things will become clear quickly. Whether the export includes what you put in. Whether the relationships survive. And how long it takes, which matters if the honest answer turns out to be that a full export is a support ticket with a queue.
If the vendor cannot be tested this way because export is only available on a higher plan, that is itself the answer, and it is worth knowing before rather than after.
Check one more thing during the trial, which is what happens to the export if your subscription lapses. Some products restrict access the moment billing fails, which turns an administrative mix-up into a data problem. Knowing whether you have a grace period, and how long, is a reasonable question and it is answered in minutes.
Keep what the test produces, as well. An export taken during a trial is a small, free snapshot of how the system structures your data, and it is a useful reference later when somebody asks what a field means or whether a record type exists. It costs nothing to file it with the contract.
The same questions apply to something built for you
Custom software is not automatically safer here, and in some ways it is worse, because the people who built it are the only people who understand the structure.
The equivalent questions are whether the database is yours and you can take a copy, whether the schema is documented well enough that somebody else could read it, and whether export is a built-in feature rather than something that would have to be written. A custom system where only the original developer can extract the data is a stronger dependency than any product.
We build export in from the start for that reason, and it is part of what the custom CRM page describes. The related question of who holds the code, the repository and the hosting is covered in what handing over the code should mean.
The database question has a sharper version worth asking of any developer, including us: if you disappeared tomorrow, could a competent person take a copy of this database and understand it? A schema with meaningful table and column names and a short document explaining the relationships makes that a yes. One with cryptic names and logic living only in the application makes it a no, however clearly the contract says the data is yours.
Whether to build at all is the prior question, and the honest answer is usually no: off-the-shelf CRM or something built for you sets out how to tell.
What the answers tell you about the vendor
Beyond the practical value, the response itself is information. A vendor confident in its product answers these questions plainly, because it expects to keep you by being good rather than by being difficult to leave.
Hesitation, vagueness about formats, or export positioned as a paid service tells you how the relationship is likely to go when something else goes wrong. It is one of the cheapest signals available during a purchase, and it costs nothing to collect.
Ask early, test during the trial, and write the answers into whatever you sign. If you want help working out what a specific product actually gives you back, get in touch.
It is worth separating the two risks this protects against, because only one of them is about vendors behaving badly. The first is a relationship ending, which is ordinary and manageable. The second is a vendor ceasing to trade, which gives no notice and no cooperation. A recent export in a readable format is the only thing that helps with the second, and it is the scenario nobody plans for because it feels unlikely until it is not. The UAE government's overview of data protection law covers your obligations to the people whose data you hold, which do not pause because a supplier closed.
None of this requires suspicion of any particular supplier. It is the same instinct as keeping a copy of your own accounts rather than relying on your accountant's filing: not a judgement about them, just an acknowledgement that your records should exist somewhere you control. Vendors worth working with understand that, and the ones who take offence at the question have told you something useful.
Frequently asked questions
Ownership and access are different things, and the second is what matters operationally. You may clearly own the data and still have no practical way to retrieve it in a usable form. The contract question is ownership; the question that decides whether you can leave is whether there is a working export you can run yourself.
Something another system can read without special software: CSV for tabular records, or JSON where there is structure and nesting. What to avoid is a PDF report, a proprietary archive only that vendor can open, or a database backup in a format tied to their specific setup. The test is whether you could open it and understand it.
Periodically rather than only when leaving, and the useful habit is a scheduled copy kept with your other records. It protects against more than switching vendors: an account dispute, a billing lapse or a vendor going out of business all produce the same problem, and a recent export turns each of them from a crisis into an inconvenience.
It is weaker than it sounds. On request means somebody else decides when, in what form and whether there is a charge, and requests take longest at exactly the moment the relationship has soured. Self-service export is a different thing, and it is reasonable to ask for it before signing rather than to accept a promise.
Ask specifically, because they are the most common omission and the most valuable content. Many exports give you a record with a filename and no file. For a business whose contracts, photographs or scanned documents live in the system, that is the part worth testing first during a trial.
Yes, and both provide reasonable export paths, which is one of their advantages. The point still holds that you should know what yours produces before you need it, and that a platform's own deletion and retention behaviour is a separate question from export. Testing a restore is the related habit worth having.
Written by Srinivasan Ramachandran, Founder, Listonics · Published Oct 11, 2026 · Last reviewed October 11, 2026 · 2,070 words
