Software companies
How much notice should customers get before a software product is retired?
By SourceX Editorial · Updated
Short answer
No general legal standard sets the notice period for retiring business software. The right period is the longest of three: what your contracts require, the time left on customers' committed terms, and how long a realistic migration takes. Then add a defined data export window, and publish one end-of-life policy so every retirement follows the same rule.
Key takeaways
- Contracts set the floor, so read discontinuation, term, termination and data return clauses before announcing any date.
- Customers on multi-year or prepaid terms usually need service to the end of the term, a refund, or a successor they accept.
- Notice should cover a realistic migration, including data export, integration rewiring and staff retraining.
- Announce end of sale, end of support, end of service and data deletion as separate dates.
- Before shutting systems down, decide which of your own records to keep: code, tickets and product history.
The rule: the longest of contract, term and migration#
The notice customers should get before a software product is retired is the longest of three periods. First, any notice your contracts require before discontinuing the service. Second, the time left on customers' committed or prepaid terms, unless you offer refunds or a successor product they accept. Third, the time a typical customer needs to choose, implement and move to an alternative.
Many vendors publish end-of-life policies with a fixed minimum notice measured in months, and longer minimums for removals with high customer impact. A published policy makes each retirement predictable, gives sales and support one answer, and keeps a single product decision from becoming a negotiation with every account.
Contract clauses that set the minimum#
Contract clauses set the minimum notice, and they vary more than most teams expect. Enterprise contracts are often on customer paper, so customers of one product can hold quite different rights; build a register of each customer's clauses before choosing a date.
| Clause | What it can require | What to check |
|---|---|---|
| Discontinuation or end-of-life clause | A stated notice period before service ends | Whether notice runs from a public announcement or a written notice to each customer |
| Term and renewal | Service through the paid or committed term | Multi-year and prepaid orders, and renewals already triggered |
| Termination for convenience | Whether the vendor may end the contract mid-term at all | Negotiated contracts often remove this vendor right |
| Service levels and support | Support commitments until the term ends | Security patches and bug fixes during the wind-down |
| Data return and deletion | An export window after termination | Format, duration and who pays for assisted export |
| Escrow and continuity | Release of source code on discontinuation | Whether a retirement would trigger release |
How long migration really takes for your customers#
Migration time for customers depends on how deeply the product is embedded. A standalone tool with a CSV export moves quickly; a product wired into ERP, billing or identity systems, with custom reports and trained staff, can take a full budget cycle to replace.
Ask a sample of customers, especially the largest and most integrated, what replacement would involve. If you offer a successor product, notice can be shorter for customers who move to it, but customers who choose another vendor still need time to run a selection and sign a contract.
Notice by customer situation#
Notice by customer situation differs because each group's risk differs, even when the product end date is the same for everyone. Segment the customer base first, then set the announcement order and the support offered to each group.
| Customer situation | What sets the notice | Typical approach |
|---|---|---|
| Monthly or annual self-serve plans | Your published policy and the current billing period | Policy minimum, with a prorated refund for prepaid time |
| Multi-year committed contracts | The remaining committed term | Serve to term end, or offer a refund or successor |
| Customers with heavy integrations | Realistic selection and migration time | The longest notice, plus assisted export |
| Customers moving to your successor product | Migration effort to the successor | Shorter notice, agreed in writing |
| Regulated customers | Their own change-control and record-keeping duties | Early direct outreach and a documented export |
| Resellers and partners | Partner agreement terms | Notice to partners before end customers |
Pair the end-of-life date with an export window#
An end-of-life announcement should state when new sales stop, when support ends, when the service ends and when customer data is deleted. Between the last two dates, customers need a defined export window with documented formats.
Published examples show the pattern. Salesforce's main services agreement gives customers 30 days after termination to request an export, after which Salesforce has no obligation to keep the data and deletes it. Atlassian's end-of-support notice for the Bitbucket Cloud issue tracker and wiki set a removal date of August 20, 2026 and offered two exits for issues: a zip export or migration into Jira.
A read-only period is a useful middle step. Before Autodesk fully retired BIM 360 Team and A360 Team at the end of 2023, it first switched their files to read-only, with options to copy them to Autodesk Docs or download them. Customers keep access to history while new work moves elsewhere, which reduces last-minute export requests.
End-of-life announcement checklist#
An end-of-life announcement goes better when the contract work, the export path and the customer messages are finished before the first notice is sent.
- Register every customer's discontinuation, term, data return and escrow clauses.
- Set the end-of-sale, end-of-support, end-of-service and deletion dates.
- Write the customer notice, FAQ and migration guide together.
- Document export formats and test them at real customer volumes.
- Brief sales, support and customer success with the same answers.
- Track each customer's acknowledgment and follow up with those who have not exported.
- Decide which of your own records to keep before shutting systems off.
Illustrative: retiring an on-premise reporting product#
Illustrative: a fictional workforce software company decides to retire an on-premise reporting product after launching a cloud successor. Some customers are on multi-year maintenance contracts; others renew annually.
The COO's contract register shows a discontinuation clause in the standard terms and customer paper for the largest accounts, several of which bar termination for convenience. The company sets end of service after the last committed term ends, offers a migration credit toward the successor, and publishes an export guide with a read-only period before deletion.
Before turning off the product's build and support systems, engineering archives the code, issue history and support tickets, while customer data is handled under each contract's return and deletion terms.
What your company should keep after retirement#
Your company should keep its own product records after retirement, separate from customer data that must be returned or deleted. Source code, Jira or Linear history, code reviews, support tickets and product decision records belong to the vendor and document how the product was built and supported.
Those records stay useful for warranty and legal questions, for the successor product's team, and possibly for licensing. A retired product can be a sensible place to start licensing engineering and support history, because commercial sensitivity is often lower once the product is off the market. SourceX reviews such archives through the SourceX five-step transaction, starting with a metadata-only fit check, and the company approves every step.
Frequently asked questions
Is there a legal minimum notice period for retiring software?
Not a general one in US law for business software. Contracts set most obligations, and consumer protection rules may matter if the product is sold to consumers. Regulated customers may have their own duties that lead them to ask for longer notice, so check sector requirements with counsel.
Can we shorten notice if customers move to our new product?
Often, for customers who accept the successor, because their risk is lower. Get that agreement in writing. Customers who decline keep their contractual rights, so the overall end-of-service date usually cannot move earlier for them.
Should end of sale and end of support get different notice?
Yes. End of sale affects only new purchases and can be announced with little notice. End of support and end of service affect running operations and need the longer period. Announce all the dates together so customers can plan once.
What if a customer misses the export window?
Decide in advance whether you will offer late assisted export, on what terms, and say so in the announcement. After the deletion date, data may be unrecoverable, so send reminders beforehand and record which customers exported.
Do we have to give customers the source code?
Only if an escrow agreement or the contract requires it. Check the release conditions, because discontinuation of the product is a common release trigger in escrow agreements. If release applies, coordinate it with the end-of-service date.
Should we tell customers why the product is being retired?
A short, honest reason helps customers plan and reduces speculation, for example a move to a cloud successor or a narrowing product focus. Avoid detail that invites negotiation over the decision itself. Keep the message on dates, export options and what support continues until end of service.
Sources
- Under the Salesforce Main Services Agreement, if the customer asks within 30 days after termination or expiration, SFDC makes Customer Data available for export or download. After that 30-day period SFDC has no obligation to maintain or provide Customer Data and will delete or destroy all copies unless legally prohibited. Source
- Atlassian announced that the Bitbucket Cloud issue tracker and wiki would be removed on August 20, 2026, with issues exportable as a zip file or migratable to Jira and wikis exportable by cloning their separate repository. Source
- Autodesk says BIM 360 Team and A360 Team files were moved to read-only access, with the options to copy data to Autodesk Docs or download it locally. The products were fully retired at the end of 2023, after which access to the files was removed. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.