Sunsetting a software product: what to do with customer data

What does sunsetting a product require for customer data?#

Sunsetting a product requires following what each customer was promised about notice, access, export and deletion. Those promises live in master subscription agreements, order forms, data processing agreements, online terms of service and privacy notices, and acquired products often carry several versions of each.

The first job for a group COO is to separate two kinds of data that teams tend to lump together. Customer content is what customers put into the product. Operational records are what the company created while running it: tickets, issues, code reviews, release notes and runbooks. The rules for each differ, and so does the opportunity.

The sunset checklist, in order#

The sunset checklist works best in a fixed order, because several steps cannot be undone. Deleting before exports are confirmed, or shutting down before holds are placed, creates problems that no later step can fix.

• 1Collect every customer agreement version and note the notice period, transition assistance and deletion terms each one requires.
• 2Send end-of-life notices with the last day of service, export instructions and a support contact.
• 3Open an export window with self-serve exports and an assisted path for larger customers.
• 4Track which customers exported, which declined and which did not respond.
• 5Place legal holds on any records tied to disputes, audits or open claims.
• 6Return or delete customer content as each agreement requires, including backups on the committed schedule, and send deletion confirmations where promised.
• 7Separate the company's operational records and decide which to retain, archive or review for value.
• 8Scan code repositories for secrets before archiving or any further use.
• 9Cancel infrastructure, vendor subscriptions and domains only after the steps above are signed off.

What may the company retain after shutdown?#

The company may retain what its agreements and applicable law allow, and nothing more by default. That usually includes records finance needs for tax and accounting, records under legal hold, and the company's own operational history, subject to the confidentiality and privacy limits that attach to customer details inside it.

Some customer agreements contain a clause letting the vendor keep aggregated or de-identified data derived from use of the service. Read the exact wording for each contract version, because these clauses vary widely in scope. Where a deletion commitment and a retention wish conflict, the commitment wins.

Before you delete, review the product's records for value#

A retired product's records can hold years of finished work: customer issues linked to fixes, code reviews that explain why a change was made, release notes, escalations from support to engineering and the runbooks used during incidents. AI developers building coding and support tools look for exactly this kind of linked, human-written history.

The value review needs metadata only: which systems hold the history, how many years are accessible, how records link and what restrictions apply. Run it before the shutdown date, while the engineers and support leads who know the product are still employed, because they are the ones who can explain which projects and fields matter.

A finished history has one advantage over a live product's: nothing new is being added, so the scope is fixed and easier to document. Capture the product's architecture notes, the meaning of custom fields and the labels used in the issue tracker while people can still explain them; without that context, an archive is much harder to prepare later.

Preparing a retired codebase and its history#

A retired codebase needs a security and rights pass before it is archived or licensed. Old repositories often contain passwords, API keys and tokens committed years ago. Open-source scanners such as Gitleaks detect secrets in git repositories and files, and TruffleHog scans sources including Git, chats, wikis and logs. Treat any scanner's output as a starting point for human review, not as proof the code is clean. Check tool status too: in May 2026 the Gitleaks README was updated to say the project is feature complete, with future releases limited to security patches.

Rights need the same care. Custom integrations built for a single customer under a statement of work may belong to that customer. Contractor-written code depends on the IP assignment in each contractor agreement. Third-party and open-source components carry their own license terms, so keep the dependency inventory with the archive.

Illustrative: a holding company retires an on-premise job costing product#

Illustrative: a fictional vertical software holding company owns a cloud job costing product for specialty contractors and an older on-premise version it bought years earlier. The group COO sets a sunset date for the on-premise product and asks the product GM, finance and outside counsel to run the checklist.

Customers receive notices and an export utility. Customer databases hosted for a handful of clients are returned and deleted, with written confirmations. The company keeps its Jira project, its Git history and its support desk archive, which link many years of contractor questions to fixes. A secret scan finds old database credentials in early commits, which are rotated and stripped. One customer-funded payroll integration is excluded. The remaining engineering and support history is documented for a value review before the last server is decommissioned.

How SourceX handles a product retirement#

SourceX approaches a retired product through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The Rights step reads the customer agreements and DPAs alongside the company's own records, so customer content the company promised to delete is never part of the scope.

Preparation removes personal and confidential details from tickets, commit messages and code, and the supplier approves the final package. The SourceX Evidence Packet documents provenance, licensing rights, permitted use, the privacy record and release authorization, which gives the holding company a clear record if a former customer later asks what happened to the product's history.