Product Operations
How to Retire a SaaS Feature Customers Still Use
A practical feature-sunset plan for SaaS teams: find customer dependencies, choose a migration path, set clear dates and exceptions, then verify completion before shutdown.
Suppose a usage chart shows that six workspaces opened the legacy export last month. One of them may still depend on it to close the books. A SaaS team should retire a feature only after it identifies the customer tasks and accounts that still rely on it, prepares a workable replacement or exit path, gives affected customers a dated plan, and verifies migration before disabling access.
A feature sunset is the planned end of a product capability. Deprecation means the team has announced that end while the feature still works; retirement is the point when customers can no longer use it. A notice starts the transition; customers still need a workable path to finish the task.
Find customer dependence before you choose a sunset date
Start with a list of accounts that used the feature, the last time they used it, and the action they completed. Add plan, role, configuration, and any related customer report if the product records those details. A button click may show interest; it cannot show whether the account completed a monthly workflow or used the feature by accident.
Look for dependence in more than event counts. Review support conversations, onboarding notes, contract commitments, implementation records, and customer research. Ask high-impact customers what work the feature performs, how often they do it, and what happens if the feature disappears. If an administrator exports data once each quarter, a monthly active-user chart can understate the disruption.
Separate three groups: accounts that still use the feature, accounts that have stopped using it, and accounts that appear inactive but may have an unattended integration or scheduled job. A product manager should assign an owner to verify the last group before a shutdown. The team can use a small set of direct customer checks to resolve uncertain cases instead of treating silence as consent.
A feature-retirement decision is ready when the team can name the affected customer tasks, identify their active dependencies, offer a tested alternative or exit route, and assign an owner to confirm migration. Usage volume helps size the work; it does not replace a dependency check. The UK Government’s digital standard says service owners should engage affected stakeholders, prepare relevant data, plan transitions, and put necessary replacement arrangements in place before retirement. Although written for government services, its readiness questions also help SaaS teams (Government Functional Standard GovS 005, updated October 1, 2026).
Choose whether to keep, replace, freeze, or withdraw
A team has four practical paths:
| Path | Use it when | Customer consequence |
|---|---|---|
| Keep for now | Customers still depend on the feature and the team has no safe alternative | Maintain the current behavior while a product owner sets a review date and reduces avoidable upkeep. |
| Replace | The underlying task still matters and a supported workflow can handle it | Give customers the migration steps, permissions, data requirements, and a way to verify the result. |
| Freeze new use | The team wants to stop new adoption while current users complete a transition | Block new setup or promotion while existing accounts retain access through a stated transition period. |
| Withdraw | The team has checked active dependencies and has a safe exit path for remaining users | Disable the capability on the published date and follow the stated data and support policy. |
Choose the path from customer impact and operating cost, not feature age. If an old export remains essential for one customer and no alternative exists, low usage alone cannot justify immediate shutdown.
For features that store customer data, decide whether customers need an export, read-only access, a retention period, or a deletion date. The UK Government’s digital standard asks service owners to archive or move assets, support migration, consider dependencies, and engage affected stakeholders. Contractual and data-handling duties vary, so ask the appropriate legal or privacy lead to review them (GovS 005: service and technology retirement).
Map the replacement to the customer’s job
Describe the task the feature completes, not only the screen or setting being removed. “Legacy export” is a product label. “Send a month-end invoice file to an accounting system with these four columns” is a task the customer can check against a replacement.
For each affected task, record:
- The customer role and account that performs it
- The current steps and data the feature produces
- The replacement path or manual exit option
- Any permissions, configuration, or format changes required
- The customer-side person who can test completion
- The internal owner who will help if the test fails
A replacement can be another feature, an integration, an export format, or a manual transition. State any missing capability plainly. If the new report cannot preserve a field customers use for reconciliation, call that a migration gap and decide who will resolve it before setting a shutdown date.
For API or integration behavior, publish migration versions and cutoff dates in documentation and supported response headers. GitHub’s REST API uses Deprecation and Sunset headers to flag approaching removals and supports each API version for 24 months. That is GitHub’s policy, not a general SaaS feature rule, but machine-readable warnings can help integrators act before cutoff (GitHub REST API versioning).
Set dates around the work customers must complete
A useful sunset plan has distinct dates for the announcement, the last date for new adoption, the migration checkpoint, the end of normal support, and the actual disablement. Some teams will combine dates for a small change. Keep the customer action and final cutoff unambiguous.
Set the interval by task frequency, migration effort, contracts, and risk. Monthly work needs time for a full month-end test; daily work can reveal blockers faster, though customers still need time to change training and procedures. Provider timelines are examples, not templates: GitHub supports REST API versions for 24 months (GitHub REST API versioning); Atlassian says it makes a best effort to give advance notice before ending support for Bitbucket Cloud features (Atlassian’s Bitbucket Cloud end-of-support policy).
For API products specifically, GOV.UK’s API-management guidance proposes a sequence that includes using analytics, publishing reasons and alternatives, adding a dated documentation notice, contacting subscribers, and checking for remaining active users before retirement. That is a useful migration pattern for API providers, not a universal timetable for SaaS features (Defining an API management strategy).
A customer-facing sunset notice should identify the feature, affected users, last-use date, replacement or exit path, required customer action, treatment of stored data, support contact, and a named exception process. Atlassian’s notices identify affected users and details, and GitHub’s versioning guidance gives advance warnings before its defined API cutoff. The team should publish the notice where customers will encounter it and send direct messages to accounts whose use is known (Atlassian Bitbucket Cloud notices, GitHub REST API versioning).
Give exceptions a reviewer and an end date
Customers will raise cases that the feature team did not anticipate. One might need a replacement field that the new workflow does not support; another might have a scheduled process that runs once per year. Let support record these cases, but give a product owner authority to approve an exception against a written criterion.
An exception record should name the account, affected task, reason, requested end date, and person who will review it. Set the end date before granting the exception. If several accounts need the same accommodation, reconsider the migration path or delay that customer cohort rather than extending separate private promises.
A missing alternative for a high-impact customer is a decision signal. The product owner can delay withdrawal for that group, provide a temporary path with an owner, or explain why the risk requires an earlier change. Each option should have a date and a customer contact. Do not let an undocumented support reply quietly create an indefinite product commitment.
Measure migration completion, not announcement reach
Track identified active dependencies, verified migrations, unresolved blockers, approved exceptions, and support contacts about the change. Email delivery and page views show that a message reached a channel; they do not show that a customer completed the replacement task.
One useful measure is migration coverage: verified migrated customer tasks divided by the active customer tasks identified for retirement. Define “verified” before collecting the number. For a data export, the customer might confirm that the new file includes the required columns and imports into the destination. For a workflow change, a named customer user can complete the task in the replacement.
Run a final dependency check near the cutoff. Contact active accounts with no recorded migration, review exception dates, and inspect any new reports. If a customer remains blocked, the product owner should decide whether to move the cutoff for that cohort, keep a constrained path available, or accept and communicate the impact.
For small product teams collecting retirement questions and migration blockers through voice, a website widget, email, or a form, Mendaro, an AI issue tracker for product teams and their customers can keep the customer report and staff triage record together. Mendaro’s homepage describes those intake channels and staff-reviewed suggestions for issue type and priority. It fits teams that need one place to capture migration friction and follow it through product review; it does not report feature usage, schedule a deprecation, or migrate customer data.
Before you announce the sunset, confirm the feature owner, affected customer list, tested replacement or exit path, data treatment, dates, communication owner, exception reviewer, and post-cutoff support route. If the team cannot name an owner or a customer action, keep researching the dependency before choosing the cutoff.
