What happens to your data when you cancel a SaaS subscription

You cancel a software subscription and assume your data is yours. It is, sort of, for a short window, in a shape that may not be usable. The gap between "we gave you an export" and "you can actually run your business on this" is where most companies get hurt.

Open your vendor's terms and search for "retention" or "termination". You will find a sentence that reads something like this. After termination, the customer may request an export of customer data for a period of 30 days, after which the vendor may permanently delete all customer data.

Thirty days is common. Sixty and ninety show up too. Salesforce, HubSpot, Monday, Asana, Smartsheet, NetSuite and the rest all publish something in this family. The specifics differ. The pattern does not.

Two details catch people out. First, the clock usually starts when your subscription lapses, not when you ask for help. If you cancel on the 1st and your admin goes on vacation, you have burned a third of the window. Second, "may request an export" is doing real work in that sentence. Some vendors give you a self-service button. Others require a support ticket, and support tickets from cancelled accounts do not get answered fast.

An export is a file. A migration is a working system with the same information in it. People use the words interchangeably and it costs them.

Here is what a typical CSV export actually contains. Text fields. Numbers. Dates. Dropdown values, flattened into whatever label was showing at the time. Here is what it usually does not contain. The actual files people uploaded, because a CSV cannot hold a PDF. The comment threads, because comments live in a separate table the export tool ignores. The audit trail showing who changed the close date and when. The definitions behind your custom fields, so a dropdown that allowed six specific values becomes plain text that allows anything. And the internal ID numbers that tie records together.

That last one matters more than anything else on the list. Your CRM knows that deal 4471 belongs to company 802 and has eleven activities attached. Strip the IDs and you have a pile of deals and a pile of companies with no reliable way to reconnect them. Matching on company name works until you hit "Acme Corp", "Acme Corporation", and "ACME Corp." as three separate rows.

What a CRM export looks like when it goes wrong

Picture a 40 person sales organization with six years in a mainstream CRM. They export contacts, companies, deals, and a file called activities.csv. It all looks fine in Excel.

Then they load it into the new system. The activities file has 380,000 rows and every one references a record ID from the old platform that no longer exists anywhere. Emails logged against a contact are now orphaned rows. The proposal PDFs attached to closed deals are not in the export at all, they were links to the vendor's file storage, and those links stopped resolving the week the account closed.

Reconstructing that by hand means someone opening old email archives and reattaching documents deal by deal. At a few minutes per deal across several thousand closed deals, you are looking at months of someone's time. Most teams give up and declare the history "archive only", which is a polite way of saying they lost it.

Most platforms have an API, which is a way for one program to pull data from another program automatically. The API almost always returns more than the built-in export button does. If your team or your developer can spend a few days scripting against it, you will get a far more complete picture.

Here is what to collect while your account is still live and paid.

• The object schema. A list of every field on every record type, including the field type, whether it is required, and the allowed dropdown values.
• The attachment binaries. The actual files, downloaded, with a mapping file that says which record each one belonged to.
• All record IDs, including the IDs of related records. Never delete an ID column because it looks like noise.
• Comments, notes, and activity logs pulled as their own datasets, not as a summary column.
• The user and permission map. Who had access to what, and which roles existed.
• Your automation and workflow logic, documented as screenshots or written rules. Nobody exports this. You rebuild it from memory otherwise.
• Integration configuration, including webhook endpoints and any API keys you own, so you know what else was listening to this system.
• Report and dashboard definitions, at minimum a screenshot of each one with its filters visible.

Store all of it somewhere you control. Cloud storage you pay for directly, or a server in your office. Not inside another vendor's trial account.

When we build a system for a client, the database sits in an account the client owns. Their cloud subscription, their credentials, their backups. We have access because they granted it, and they can revoke it.

That changes the cancellation question completely. There is no export window because there is no vendor holding the data. If the client stops working with us tomorrow, the database is still sitting there with every row, every file, every audit record. Any competent developer can pick it up.

The arithmetic is worth running honestly. Say you pay 80 seats at 120 dollars a month. That is 115,200 a year, and it climbs at renewal, and you own nothing at the end of year five. Now price a custom build against that number, including the yearly hosting and maintenance, and see where the lines cross. Sometimes they cross in year two. Sometimes they never cross, because the SaaS tool is cheap and does everything you need. Do the math with your real seat count before you assume either answer.

The advantage of building your own target system is that you get to design the destination around the source. Off the shelf platforms force your old data into their shape. A custom build lets you keep the shape you had.

In practice that means a few things. Old record IDs get stored in a dedicated legacy ID column, so every link from the old system still resolves. Attachments get downloaded as real files and stored in your own file storage, with the record association preserved. Activity history comes in as timestamped rows with the original dates and original authors, not with today's date and the name of whoever ran the import. Closed and historical records can keep values that would fail today's validation rules, because a 2017 deal should not be forced to obey a 2026 process.

The work is not glamorous. It is mostly writing scripts, running them, checking counts, and fixing the rows that failed. But it is a known job with a known end, and when it is done the history is genuinely yours.

Custom is the wrong call more often than software firms admit.

If you have twelve people using a standard CRM in a standard way, renew it. You are not going to beat the economics and you will spend attention you need elsewhere. If your industry has a dominant platform that your clients and partners also use, leaving it creates friction with everyone outside your walls. That cost is real and it does not show up on a spreadsheet.

There are honest limits on the migration side too. If your vendor genuinely does not expose attachments through the API, there is no clever trick. Somebody downloads them manually or you lose them. Perfect fidelity is rarely achievable. Some things, like a platform's internal search ranking or the exact render of an old report, cannot be recreated and should not be promised.

And a custom system needs an owner inside your business. Somebody who decides what changes and when. Companies that buy software specifically so they do not have to think about it will struggle with that responsibility.

Start with the contract. Find the retention clause in every major platform you pay for and write the number of days on a single page. Then log in as an admin and find out whether export is self service or requires a ticket.

Next, pull a full export of your most important system while everything is still active and healthy. Not because you are leaving. Because you want to know what you would get if you did. Open the files. Look for attachment columns. Look for ID columns. Check whether comments came through.

Whatever you find, that is your actual exit cost, and now you know it before you need it. If the answer makes you uncomfortable, that is useful information about how much power your vendor has over you.

If you are weighing a renewal against building something you own, bring your seat count, your renewal quote, and a sample export. That is enough to have a real conversation about whether custom makes sense for you or whether you should stay put. You can book a free strategy session and we will tell you honestly which one it is.

Read this next: our breakdown of what it actually costs to own your software versus renting it, including the maintenance side people forget.

Related articles

• How to run a data migration without losing your history
• When a custom build beats another SaaS renewal
• Who owns your code, your data, and your hosting account