Exporting your data before you leave a SaaS platform, and what the export will not include

• A CSV export is a snapshot of fields. A usable dataset includes files, history, relationships, and the logic that made the system work.
• Attachments and activity logs are the two most commonly missed items, and both are the ones auditors and lawyers ask for later.
• API extraction gets you far more than the export button, but rate limits mean a full history pull takes days, not hours.
• Your contract sets a retention window after cancellation. Read it before you give notice, because some vendors delete on a timer.
• Validate what you pulled. Count records, check totals, and test that child records still point at the right parents.
• Some things cannot be migrated at all. Archive those in PDF or plain files so they stay legally accessible.

Most companies discover the gap on the wrong day. The subscription lapses, someone goes looking for a signed change order from three years ago, and the CSV on the shared drive has a column called attachment_url full of links that now return a login page. The data was exported. The business record was not.

Every SaaS platform will hand you your records. That is table stakes, and in some jurisdictions it is a legal duty. What almost none of them hand you is the system those records lived inside.

Think about what a single job record in your project tool really contains. There's the header information, which is the part that exports cleanly. There's a thread of forty comments where the client changed scope twice. There are eleven photos from the site. There's a log showing who moved the job to Complete and when. There are three automations that fired when the status changed. There's a permission rule that stopped the field crew from seeing the margin.

The export gives you the header. You can rebuild the rest, and we do that work, but you cannot rebuild what you never extracted. That's the part that matters. A migration where you're missing a field is annoying. A migration where you're missing four years of signed approvals is a problem with teeth.

So treat the question as two separate jobs. First, get every byte out of the vendor's system while you still have access. Second, decide what goes into the new system and what gets archived. Doing those in the wrong order is how businesses end up paying for a dead subscription for another year just to keep read access.

The specifics vary by platform, but the pattern is remarkably consistent across CRMs, project tools, and mid-market ERPs. Here's what typically does not come down with a standard export.

• File attachments. Exports usually include a URL that points back into the platform, not the file itself. Once billing stops, the link dies.
• Audit and activity history. Who changed what, when, and from what value. Frequently unavailable in any export at all, sometimes only via API, sometimes only on enterprise plans.
• Automation and workflow logic. Your rules, triggers, and approval chains are configuration, not data. They almost never export in any usable form.
• Permission structures. Roles, sharing rules, and record-level visibility live in the vendor's model and do not travel.
• Custom field metadata. You get the values but not the definitions. Dropdown option lists, field descriptions, validation rules, and which fields were required all vanish.
• Threaded notes and comments. Sometimes they export as one giant text blob with no author or timestamp. Sometimes they need a separate API call per record.
• Email and message history synced into the platform, which often lives under a separate object with its own export path.
• Deleted and archived records sitting in a recycle bin, which are still discoverable in a dispute even though they don't appear in the main export.

Attachments are the big one. We've seen platforms where pulling every file means one authenticated request per attachment, and a mid-sized company can easily have tens of thousands. That's a scripted job, not a copy and paste. Budget real time for it and start it early, because it runs longest and fails most often.

A CSV export is the front door. It's quick, it needs no developer, and for straightforward record lists it's genuinely fine. Contacts, companies, invoices, tasks. If that's all you need, take the CSV and move on.

An API is the service door. API stands for application programming interface, which in plain terms means a way for one program to ask another program for data, one request at a time. The API almost always exposes more than the export screen does. Activity logs, per-record comments, file contents, field definitions, and related records all tend to be reachable there.

The catch is rate limits. Vendors cap how many requests you can make per minute or per day to protect their servers. That cap is fine for normal use and brutal for a full historical extraction. If a platform allows a few hundred requests a minute and you need one request per record for comments plus another per attachment, the arithmetic gets unfriendly fast. A hundred thousand records at that rate is measured in days of continuous running, assuming nothing times out.

Nothing ever runs clean the whole way. So a real extraction script has to be resumable, meaning it remembers where it stopped and picks up from there. It also has to log every failed request so you can retry just those. Writing an extraction that starts over from zero after an error is the most common self-inflicted wound in this whole process.

Three clauses decide how much room you have. Find them before you give notice, not after.

The first is the data return clause. Some agreements promise an export in a specified format on request. Some promise assistance at additional cost. Some say nothing, which means you get whatever the product happens to offer that quarter.

The second is the retention window after cancellation. This is how long the vendor keeps your data once you stop paying. It ranges from immediate to ninety days to indefinite. A handful of platforms drop you into a read-only state, which is helpful. Others suspend access entirely on the renewal date while keeping the data on a deletion timer in the background.

The third is the deletion timeline. If you have any retention duty of your own, whether from an auditor, a regulator, or an insurer, the vendor's deletion clock has to be reconciled against it. You cannot produce records in year six of a dispute because the vendor purged them in month four.

Do the work in this order. It's the order that keeps your advantage intact.

1. Inventory what exists. List every object, module, and report in the platform. Note record counts for each. This list is your checklist for everything that follows.
2. Pull the easy exports first. Every CSV the UI offers, dated and stored somewhere you control.
3. Get API credentials issued while an admin still has full rights. Do this early. Admin seats get deprovisioned in the churn of a transition.
4. Run the attachment extraction. It's the slowest and it fails most, so give it the most calendar time.
5. Pull history, comments, and audit logs through the API.
6. Screenshot or document the configuration. Automations, field definitions, permission roles, and report filters. No export exists for these. A structured document beats nothing by a mile.
7. Validate. Then cancel. Never the other way around.

Keep the subscription alive through validation. The cost of one extra month is trivial against a failed extraction you can no longer repeat. We've never regretted paying for the overlap. We have regretted trusting a vendor's thirty day grace period.

Validation is where most migrations quietly go wrong. The files look right, everyone signs off, and six weeks later the sales team notices that contacts created before 2021 have no owner assigned.

Start with record counts. Every object you inventoried should have a matching count in the extracted set. A shortfall of two percent is not a rounding error. It's usually a filter you didn't notice on the export screen, or a page of API results that failed silently.

Then check totals that have a real-world answer. Sum last year's invoices in the export and compare against what your accountant filed. If those two numbers match, you have strong evidence the financial records came across whole.

Then test relationships, which developers call referential integrity. In plain English, it means every child record still points at the right parent. Pick a hundred random line items and confirm each one attaches to the invoice it belongs to. Pick fifty tasks and confirm each sits under the correct project. Broken links are the single most common defect in a migrated dataset, and they're invisible until someone opens a record and finds it empty.

Finally, spot check by hand. Pull twenty records that your team knows well and read them side by side against the live system. Include the messiest ones on purpose. The account with the name in all caps, the job that got reopened twice, the client with two addresses.

Not everything should move. Ten years of comment threads on closed jobs has no place in a new operational system, and forcing it in there makes the new system slower and uglier for no benefit.

Archive it instead. The rule we use is simple. If you might need to read it or produce it, but you will never work in it, it belongs in an archive. That means files in an ordinary folder structure, records as CSV or JSON alongside a plain readable index, and PDFs for anything with signatures or approvals on it. Store it somewhere your business controls and can still open in a decade with no vendor account required.

What this process genuinely cannot do

Be clear-eyed about the limits, because a few of them are real.

• Some platforms simply do not expose audit history to customers on any plan. If it isn't in the product and isn't in the API, it doesn't exist for you. No amount of scripting invents it.
• Automation logic cannot be migrated. It has to be rebuilt. Documenting it well makes the rebuild fast, but it's still a rebuild.
• If the platform is how you share live information with clients or subcontractors, your export doesn't solve that. Those external users have to be moved, trained, and in some cases contractually renegotiated. That's a real cost and pretending otherwise wastes everyone's time.
• Rendered views are gone. Dashboards, charts, and saved reports are configuration on top of data. You keep the data and rebuild the view.
• Extraction takes technical work. If nobody on your team can write or run a script, you need help for the API portion, full stop.
• A custom replacement isn't automatically the right call. If you use a narrow amount of a cheap tool and it does the job, staying is the correct answer. The math turns when you're paying per seat for something you've outgrown and can't change.

How long before cancellation should I start extracting?

Start while you have at least one full billing cycle left, and more if you have a large volume of attachments. The pulling isn't the slow part. Validation and rebuilding your automations are.

Can I just ask the vendor for a full database dump?

You can ask, and it's worth asking. Most will decline, because their database holds other customers' data in the same tables. A few offer a paid extraction service. Read what's included before you pay for it, since some of those packages are the same CSVs you could have pulled yourself.

Do I need all the old history in the new system?

Usually no. Bring over open work, active customers, and enough closed history for reporting comparisons. Archive the rest. Your new system stays fast, and you still have everything.

What if we already cancelled and lost access?

Ask immediately and in writing, because retention windows often run longer than access windows. The data may still be on their servers even though you can't log in. Some vendors will reinstate temporarily. Do not wait to find out.

Is exporting the same as a backup?

No. A backup can be restored into a working system. An export is a set of files you'd have to rebuild around. Both are useful. Only one of them gets you running again on a bad Tuesday.

Pick your most business-critical platform this week. Click the export, open the file, and try one attachment link while logged out. Then look up the retention clause in the contract. That hour tells you whether you own your operational history or you're renting it.

If the answer makes you uncomfortable, we build systems where the data sits in a database the client owns, on infrastructure the client controls, with no renewal date attached to access. You can book a free strategy session and we'll look at what's actually extractable from your current stack before you commit to anything.

Read this next: our walkthrough of how to plan a migration off a platform you've outgrown, which picks up where this article stops.

Related reading

• Why per seat pricing quietly becomes your biggest software line item
• Rebuilding automations when you switch platforms
• Owning your software versus renting it, and how to run the numbers