Product sunset checklist for software acquirers

What a product sunset checklist must cover#

A product sunset checklist must cover six phases: decide, notify, migrate, preserve, shut down and close out. Software acquirers retire products for familiar reasons, such as features that overlap with a sister product, an aging codebase or a customer base too small to support, and the first, second, third and fifth phases are usually well understood.

The preserve phase is where acquirers lose value and create risk. Teams often delete hosting environments, repositories and helpdesk accounts on the same schedule, without separating what must go from what the company may keep. A gate between migration and shutdown fixes that.

The phase-by-phase checklist#

The phase-by-phase checklist gives each task an owner so nothing depends on memory. Adjust the timing to your customer contracts and notice obligations.

What the end-of-life notice should tell customers#

The end-of-life notice should tell customers what is ending, when each milestone falls, what their options are and what happens to their data. Notices that leave the data question vague generate support tickets and, from enterprise customers, formal requests from their own counsel.

Give the end-of-sale, end-of-support and end-of-life milestones as dates, describe the migration path and any export tools, and state how and when customer data will be returned or deleted, with a contact for confirmation requests. Check each contract for the notice period and delivery method it requires, because negotiated enterprise agreements often specify both.

The data-preservation gate#

The data-preservation gate is a sign-off that no system is deleted until its records have been sorted into what is returned, what is deleted and what the company keeps. It is short, but it needs both the CTO and counsel to sign.

• 1Inventory every system the product used: repositories, issue tracker, CI logs, helpdesk, chat channels, docs wiki, analytics and hosting.
• 2Classify each record family as customer data, company records or mixed.
• 3Confirm customer data obligations under each contract and data processing agreement.
• 4Check retention duties and any legal hold before deleting anything.
• 5Export and archive company records in documented, readable formats.
• 6Scan code and tickets for secrets and pasted customer data before archiving.
• 7Record the decision, the signers and where the archive lives.

Customer data vs company records at sunset#

Customer data and company records follow different rules at sunset. Customer data is generally governed by the customer contract and the data processing terms, which commonly require return or deletion when the service ends. The company's own engineering and support history is generally its own, subject to confidentiality, open-source licenses and any customer-specific terms.

Preparing code repositories before they are archived#

Code repositories need two checks before they are archived: a secrets scan and a component inventory. Retired products often carry old API keys, database passwords and service tokens in their commit history, and some of those credentials may still work against systems the group uses today.

Open-source scanners are a common first pass. Gitleaks, an MIT-licensed tool, detects secrets such as passwords, API keys and tokens in git repositories and files, though its maintainer stated in May 2026 that it is feature complete and will receive security patches only. TruffleHog, an AGPL-3.0 scanner, says it can log in to confirm whether a detected secret is still live, which means it sends real authentication requests and should be run with operational care.

The component inventory lists third-party and open-source libraries with their licenses, plus any code a customer paid for under terms that give it ownership. Both lists decide what can be kept and what could ever be shared.

Illustrative: retiring an acquired bid management tool#

Illustrative: a fictional vertical software acquirer owns two construction products and decides to retire the smaller one, a bid management tool, after moving its customers to the sister product. The original plan deletes the hosting environment, the GitHub organization and the Zendesk account on the end-of-life date.

The head of portfolio operations adds the preservation gate. Customer bid documents are returned and deleted under each customer's contract. The code, Jira history, code reviews, release notes and internal design docs are exported, scanned for secrets and pasted customer data, and archived in the group's storage. Support tickets are archived with restricted access after counsel reviews the customer terms. One enterprise customer's custom integration is excluded because its contract assigns ownership to the customer.

The product shuts down on schedule. The archived engineering history stays available for internal reference and for a later decision on whether any of it should be licensed.

How SourceX fits into a product retirement#

SourceX fits into a product retirement at the preservation gate, before records are deleted rather than after. A metadata-only fit check on the retiring product's company records, covering systems, years of history and record families, shows whether a licensing conversation is worth having, and nothing is shared during that assessment.

If the records proceed, the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery keeps the company in control at each step. Customer data that the contract says must be returned or deleted stays out of scope.