A product sunset is the planned, announced retirement of a software product, plan or feature, in which a provider stops selling it, gradually ends support and development, helps customers move elsewhere and finally shuts it down. In SaaS operations, a sunset is a managed process with fixed dates, contractual obligations and data handling duties, not simply switching off a server.
Because subscribers depend on the service for daily work and store their data in it, a sunset affects revenue, customer trust and legal compliance at the same time. A well-run sunset keeps those risks low through early notice, a clear migration path and complete data export.
Why SaaS companies sunset products
Products are retired when the cost of keeping them alive exceeds their strategic value. Every live product needs hosting, security patching, compliance audits, support staff and engineering attention that could serve a larger offering instead.
- Low adoption or revenue that does not cover running costs.
- Consolidation after an acquisition, when two products overlap.
- Technical debt in an old platform that cannot meet current security or compliance standards.
- Replacement by a newer product that covers the same use cases better.
- Strategic refocus on a different market segment or business model.
The decision usually rests on product usage data, customer health scores, revenue concentration and the engineering effort that a migration would require. Retiring a feature used by a handful of large accounts can be harder than retiring a whole product used by many small ones.
The phases of a product sunset
A sunset proceeds through distinct phases, each with its own customer impact. The durations below are common in business software, though contracts and the size of the customer base change them considerably.
| Phase | What happens | Typical duration |
|---|---|---|
| Decision and planning | Internal analysis, legal review, migration design | 1 to 3 months |
| Announcement | Customers, partners and staff informed of dates | Single event |
| End of sale | No new customers or upgrades accepted | Starts at or soon after announcement |
| Maintenance only | Security fixes and critical bugs, no new features | 6 to 18 months |
| End of support | No fixes, limited help desk | Final weeks before shutdown |
| Shutdown and data deletion | Service off, data deleted after a grace period | 30 to 90 days of retention |
The longest phase, maintenance only, gives customers time to evaluate alternatives, run a migration project and align it with their own budget cycles. Notice periods shorter than about six months for business-critical software tend to cause escalations and churn beyond the retired product.
Contractual, legal and data obligations
A SaaS sunset must respect existing contracts and data protection law. Subscription terms often specify minimum notice for discontinuation, and multi-year agreements may require service until the end of the term, a pro-rated refund or a contractually equivalent replacement.
| Area | Requirement | Practical measure |
|---|---|---|
| Contract terms | Honor notice periods and committed terms | Review every active agreement and renewal date |
| Data portability | Return customer data in a usable format | Self-service export in CSV, JSON or via API |
| Data deletion | Delete personal data once no longer needed | Documented deletion with confirmation on request |
| Service level agreements | Uptime commitments remain until the end | Keep monitoring and the status page active |
| Subprocessors | Third parties also stop processing | Terminate and confirm deletion with each vendor |
Under privacy regulations such as the GDPR, the provider remains a data processor until all customer data is returned or deleted. Retaining backups longer than stated in the data processing agreement is a common compliance gap during shutdowns.
Product sunset compared with related events
A sunset is often confused with neighboring lifecycle events. The comparison clarifies what customers can expect in each case.
| Event | What ends | Customer action needed |
|---|---|---|
| Product sunset | The whole product | Migrate to an alternative |
| Feature deprecation | One capability, product continues | Adjust workflows |
| API version retirement | An interface version | Update integrations |
| Plan grandfathering end | A legacy price or package | Move to a current plan |
| Contract non-renewal | Service for one customer | Depends on the reason |
Deprecation is frequently the first step toward a sunset, but it does not by itself mean the product is ending. Clear wording in announcements prevents customers from reading a deprecation notice as a full shutdown, or the reverse.
Running a sunset well
The core principle is no surprises for the customer. Practitioners combine communication, tooling and support to keep both churn and support load under control.
- Announce once, then remind on a schedule, for example at 6 months, 3 months, 1 month and 1 week before shutdown, through email, in-app banners and the admin console.
- Offer a migration path to a successor product, ideally with automated data transfer and a discount or extended trial.
- Provide complete data export before any functionality is removed, and test it with real customer data volumes.
- Brief support and account teams with a shared FAQ and escalation rules for strategic accounts.
- Stop billing correctly, including usage metering, dunning and renewal invoices, so no customer is charged after the end date.
- Keep security patching active until the final day, because a neglected product is an easy target.
Typical mistakes include announcing a date and then moving it repeatedly, leaving the product listed on the pricing page, and deleting data before the grace period ends. Each of these damages trust in the provider’s remaining products.
Put simply
A product sunset is how a software company closes one of its online services in an orderly way. It is a bit like a shop announcing that it will close at the end of the year: it stops ordering new stock, tells regular customers when the last day is, and suggests where they can shop instead.
For a cloud service, that also means giving customers their data back and then deleting it safely. Customers get months of warning, tools to move their work, and often a discount on a replacement. Done well, people are inconvenienced but not stranded.
In practice
A company that sells project management software also runs an older time tracking product with about 1,200 paying customers. After moving time tracking into its main platform, it decides to retire the old service. It announces an end of sale immediately and sets the shutdown date nine months later, aligned with the end of most annual contracts.
Customers receive email and in-app notices, a one-click import into the main platform and a 30 percent discount for the first year. Annual contracts that extend beyond the shutdown date receive pro-rated refunds. A full JSON and CSV export remains available until the final day, and data is deleted 60 days after shutdown. About two thirds of customers move to the main platform, support tickets peak in the final month and then fall to zero, and the engineering team reclaims the time it spent maintaining a separate code base.