How to shut down a SaaS product: customer data export and notice plan

What does a SaaS shutdown plan need to cover?#

A SaaS shutdown plan covers six workstreams that run in parallel: contracts, customer notice, data export, billing, deletion and the company's own records. Treating the shutdown as one announcement email is how many end in disputes or in support backlogs that outlive the product.

Assign one owner to each workstream and one person to the overall date. In a small software company the CTO usually owns export and deletion, the CEO owns notice and contracts, and finance owns refunds and final invoices.

• 1Contracts: master agreements, terms of service, order forms, data processing agreements and any negotiated transition-assistance clauses.
• 2Notice: who is told, in what order, through which channels, and what each message must contain.
• 3Export: a self-serve download, API access and hands-on help for accounts with unusual data volumes.
• 4Billing: stopping renewals, prorated credits or refunds, and final invoices.
• 5Deletion: production data, backups, logs and copies held by subprocessors.
• 6Company records: issues, code, internal documents and finance files the company keeps after the product ends.

What should the customer notice timeline look like?#

The customer notice timeline should start from the longest notice period any contract requires and add a margin on top. Your terms of service may set a default, but enterprise order forms often contain negotiated notice or transition terms that override it, so review those accounts first.

Send every notice through at least two channels, such as email to the account owner and billing contact plus an in-app banner. Keep a log of who received each notice and when; that log is your evidence if a customer later says they were never told.

The 90, 60, 30 and 0-day offsets in the table are an example planning pattern, not a legal standard. If any contract requires a longer notice period, move the whole schedule earlier so the announcement still clears it.

How should customers export their data before access ends?#

Customers should be able to export their data themselves, in a standard format, without filing a ticket. CSV suits tabular records, JSON suits nested objects such as comments and activity, and a zipped folder suits attachments when it includes a manifest mapping each file to its parent record.

Test the export on your largest and oldest accounts before you announce. Exports that work on a demo tenant often time out on accounts with years of history, and a failed export during the final notice period puts the most pressure on a small team.

• 1Stable record IDs and parent IDs, so relationships survive the export.
• 2Created and updated timestamps with time zones.
• 3Attachments and files themselves, not links that will stop working.
• 4User and owner fields, so customers can rebuild assignments elsewhere.
• 5A field dictionary explaining custom fields, status values and codes.
• 6A short guide to importing into the replacement products customers most often choose.

What happens to customer data after the product is turned off?#

Customer data after shutdown is deleted or returned exactly as your data processing agreement and terms describe. Many agreements let the customer choose between return and deletion, and some require written certification of deletion on request.

Deletion has to reach every copy: database snapshots, object storage, search indexes, logs that captured request bodies, and data held by subprocessors such as email delivery, analytics or error tracking. Privacy laws such as GDPR or CCPA may also apply depending on where customers and their users are, so confirm the deletion plan with counsel.

Which records does the company keep after a shutdown?#

The company keeps its own operating records after a shutdown: Jira or Linear issues, GitHub or GitLab repositories with pull requests and reviews, Confluence or Notion documents, internal Slack history, release notes and finance files. These describe how the company built and ran the product, which is different from the content customers stored in it.

Export those records before you cancel the tools that hold them, because vendor windows after termination can be short or nonexistent. Salesforce's Main Services Agreement makes customer data available for export only if requested within 30 days after termination, and HubSpot's terms say most hubs give no access to customer data after the subscription ends. On Slack's Free plan, messages and files older than one year are permanently deleted. Store exports in company-controlled storage with a short index of what each archive contains.

Support tickets sit in between: the conversation is a company record, but it may quote customer content, so tag tickets for a rights review rather than keeping or deleting them by default.

Kept records can have later uses, including licensing engineering and support history to AI developers. That happens only after a rights review, with customer personal data excluded or de-identified, which is why a clean separation at shutdown matters.

Illustrative: sunsetting a fleet maintenance add-on#

Illustrative: a fictional vertical software company sells a fleet maintenance scheduling add-on beside its main dispatch product. Usage is low, the add-on depends on an aging mapping library, and leadership decides to retire it while keeping the core product.

The CTO finds that two enterprise customers have order forms with longer notice and transition-assistance terms, so the timeline is built around them. The team ships a CSV and JSON export with a field dictionary, tests it on the oldest account, and sends reminders by email and in-app banner.

After the final export date the team deletes customer data, collects subprocessor confirmations, and archives the add-on's Jira project, repository and design documents in company storage. Later, that archived engineering history is reviewed for licensing, with customer content excluded from the start.

Shutdown mistakes that create disputes#

Most shutdown disputes come from a gap between what the notice promised and what actually happened. These are the mistakes worth checking for before the announcement goes out.

• 1Announcing a date before checking negotiated notice terms in enterprise contracts.
• 2Shipping an export that drops attachments, comments or custom fields.
• 3Cancelling hosting or a subprocessor before deletion is confirmed and recorded.
• 4Deleting company records such as issues and repositories along with customer data.
• 5Leaving the support inbox unanswered during the final notice period.
• 6Promising backup deletion on a schedule the infrastructure cannot meet.

How SourceX approaches records from a retired product#

SourceX looks only at the company's own records from a retired product, such as engineering issues, code reviews, release history and support conversations, and starts with a metadata fit check. Nothing is shared during the initial assessment; the company describes its systems, years of history and record families.

If a package proceeds, it follows the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The rights review weighs customer terms and the shutdown commitments you already made, and the SourceX Evidence Packet documents what was licensed, from provenance through release authorization.