Sunsetting a software product: data retention and archive checklist

What should a product sunset keep, return or delete?#

A product sunset should sort every record family into one of four outcomes: return to customers, delete, archive internally, or evaluate before deletion. Deciding per family, before teardown starts, prevents the two classic failures: deleting something you needed and keeping something you promised to destroy.

The table is a default starting point. Your contracts, retention schedule and any legal holds can move a family from one outcome to another.

The sunset checklist, phase by phase#

The sunset checklist works best as phases with named owners, because a retirement spans product, engineering, support, legal and finance. The order matters: nothing irreversible happens before the archive and the rights record exist.

Run the plan in one tracker, with each checklist item as a task linked to its evidence: the notice, the export logs, the release tag, the restore test and the deletion certificates. That tracker becomes the audit record of the retirement.

• 1Announce: customer notice with dates for end of sale, read-only mode, export deadline and deletion.
• 2Return: export tools, migration help and a record of each customer's export.
• 3Freeze: final release tag, locked dependency versions and a build that runs from the archive.
• 4Capture: issue tracker, wiki, design files and support archive exported with their links intact.
• 5Record: a rights record covering authorship, contractor assignments, open-source components and customer-funded work.
• 6Retain: a retention period for each archived family, taken from your retention schedule.
• 7Delete: customer data removed from production, backups and sub-processors, with certificates.
• 8Tear down: infrastructure shut off only after a test restore of the archive succeeds.
• 9Hand over: a named role that owns the archive after the team moves on.

Code freeze: what to capture before the team moves on#

A code freeze for a retired product captures enough to rebuild, understand and evaluate the code years later, after the people who wrote it have left. A bare repository rarely meets that bar.

Tag the final release, commit lockfiles and vendored dependencies, record compiler and runtime versions, and keep CI configuration with secrets removed. Export the issue tracker with its links to commits and pull requests, because the reasoning behind a fix usually lives in the ticket rather than the diff.

Interview the last engineers before they move to other teams. A short recorded walkthrough of the architecture, known defects and odd workarounds turns an opaque archive into one that a future team, an acquirer or a licensee can actually use.

Where retention and deletion rules collide#

Retention and deletion rules collide when one system holds both your records and customer data. In a product retirement the colliding systems are usually shared with products that stay live: the help desk, the data warehouse and the backup set.

Resolve each collision system by system. In a shared help desk, select the retired product's tickets by brand, form or tag, delete attachments and personal fields, and keep a de-identified ticket body. In the warehouse, drop the retired product's customer-keyed event tables and keep only aggregate metrics your contracts allow. For backups that mix live and retired data, record when the retired data ages out rather than claiming it was deleted at once. Write the basis for each decision into your retention schedule.

Do not keep customer personal data because it might be useful someday. Privacy laws such as GDPR expect personal data to be kept no longer than its purpose requires, and an archive full of it is a liability rather than an asset.

The rights record: before you delete, value it#

A rights record documents who owns each part of the retired product and what the company may do with it, and it decides whether the archive can ever be licensed or sold. Teams that skip it often discover, years later, that nobody can confirm the code is clean.

The Data & Trust Alliance's Data Provenance Standards offer a useful vocabulary here. Their Use group includes elements for confidentiality classification, consent documentation location, license to use, intended data use, and copyright, patent and trademark status, which map closely onto what a buyer will ask about a retired archive.

• 1Authorship: employees and contractors who contributed, with assignment agreements on file.
• 2Open-source inventory: components, licenses and any copyleft obligations.
• 3Third-party code: vendored SDKs and their redistribution terms.
• 4Customer-funded work: modules built under services agreements that assign deliverables.
• 5Escrow and source access: customer escrow arrangements and their release conditions.
• 6Data sources: where each archived dataset came from and which notices or contracts covered it.

Illustrative: retiring an on-premise reporting module#

Illustrative: a fictional HR software company retires an on-premise reporting module after its customers move to the cloud product. The CTO runs the sunset as a project with a product lead, a support lead and outside counsel.

Customers receive export tools and a deletion date. The team tags the final release, captures the build environment, exports the Jira project with commit links and keeps a de-identified copy of the module's support tickets. The rights record shows that an early report designer component came from a contractor with no assignment, so that folder is flagged for exclusion.

Before the infrastructure is torn down, the CTO asks whether the code, code reviews and support history have value beyond the company. The archive is kept under the retention schedule while that question is assessed, rather than deleted by default.

How SourceX looks at a retired product#

SourceX treats a retired product's code, issue history and support records as candidate supply, assessed from metadata in the Supply step of the SourceX five-step transaction before anything is deleted or shared. Customer tenant data is excluded unless a customer licenses its own records.

If the archive proceeds, the rights record feeds the SourceX Evidence Packet: provenance, licensing rights, permitted use, the privacy record and release authorization. The archive stays in your own storage throughout.