Retiring a SaaS feature? Check who still depends on it
Account managers rarely open the old report builder, but clients still use its weekly files. Follow that dependency before deciding what can retire.
A link created years ago can still get someone to the document they need today. In July 2024, Google announced that existing goo.gl links would stop working in August 2025. On August 1, 2025, it changed the plan to preserve active links, recognizing their use in documents, videos, and posts.
For a SaaS team considering feature retirement, the useful question is what still depends on the old capability. Answering it can free development time, simplify the product, and spare customers from rebuilding a routine that already works.
Look for the work happening outside the interface
Consider a fictional operations platform used by a service provider with clients in several countries. Account managers rarely open its legacy report builder. A newer dashboard offers better filters and clearer charts, and the product team wants to retire the old reporting interface.
Every week, though, saved schedules still produce CSV reports for those clients. An operations analyst imports the files into the workbook used for Monday planning. Account managers only revisit the builder when a client changes its reporting needs. The automation continues doing useful work between those visits.
Counting report-builder sessions would miss much of that activity. Looking at completed jobs and delivered files gives the team a better starting point. Some schedules may also be obsolete, sending reports nobody uses. Separating those cases helps the team remove unnecessary work while protecting the reports that still support a decision.
Follow the output to the people who need it
One account manager can configure reports for many client teams. That person's occasional activity represents a larger group of people who use the output without opening the reporting interface. A retirement decision needs to account for those downstream users.
In this example, the weekly file contains the previous week's open requests, assigned teams, and service categories. The client uses that information to plan staffing. A missed report would send an analyst back into individual records to rebuild it. That recovery work belongs in the assessment alongside the cost of maintaining the old feature.
The observation period should also cover the job's natural rhythm. Weekly reports leave regular evidence. A quarterly export may require looking further back or asking about the next planned run. A quiet month alone cannot establish that a quarterly task has disappeared.
Execution records help identify the right people to ask. A conversation explains why the output matters: “Your weekly reports still come from the old builder. What happens to those files after they arrive?” The answer can expose a dependency that never appears in the interface's engagement numbers.
Try the replacement against the complete job
The new dashboard in this fictional platform lets clients explore their data online. It does not yet produce the scheduled CSV used in their planning workbook. Moving everyone to the dashboard would leave the analyst rebuilding that file each week. Better charts would not recover the time lost to that extra work.
The product team can make the gap concrete by generating a sample report from the new system and asking the analyst to use it for the existing planning task. The analyst can check whether the file preserves the service categories and reporting period the workbook expects, while the team verifies that delivery no longer requires manual preparation.
This may uncover a small addition that makes retirement practical. It may also reveal a workflow the team no longer intends to support. Either finding is more useful before a shutdown date is announced.
There is a useful historical example in Canny's account of its 2.0 rollout, published in 2021. The company introduced its new admin interface gradually, allowed a return to the previous version during testing stages, and made changes based on feedback. A replacement can improve through use before the older experience disappears.
Choose which parts can actually retire
The legacy builder and the service executing saved reports may have different retirement paths. The team could stop creating new reports in the old interface while keeping existing schedules running for a defined transition. That limits the creation of new dependencies while work continues on the replacement.
Product lifecycle states can also be distinct. The current documentation for Featurebase's All-In-One Widget says the deprecated widget remains usable, will receive no future updates, and should be replaced with Messenger. A change in development status does not, by itself, specify an immediate shutdown.
For the reporting platform, keeping the execution service alive remains an engineering commitment. Someone must monitor failures, maintain its dependencies, and protect access to client data. Removing the menu entry does not remove those responsibilities. The team needs to price that work into its plan and give it an owner.
Where the old interface and its execution service cannot be separated safely, the plan has to account for that limitation too. A temporary compatibility layer is only an option if the team can operate it reliably.
Make the end condition part of the decision
A useful plan for this team might be to add scheduled CSV delivery to the new reporting system, test it with representative client workbooks, and observe a complete weekly reporting cycle. The person owning retirement can then compare the outcome with the requirement that justified keeping the old service.
If the reports arrive but the analyst must repair their structure every Monday, the dependency is unresolved. If clients can complete their planning work with the new files and the team has accounted for the remaining affected workflows, there is concrete evidence for retiring the old execution path.
The team may instead decide that the capability deserves ongoing support. That is a reasonable outcome when its customer value warrants the maintenance cost. Keeping a feature indefinitely while describing it as a temporary exception makes that cost harder to see and manage.
Some constraints force a faster decision. An unsupported dependency may create a security risk the team cannot adequately contain. The retirement timeline then needs to reflect that risk, while giving customers a clear account of the capability they will lose and the work or expense required by the available alternative.
Use the next real outcome to settle the question
For this platform, the practical target is a weekly report that reaches the right client and works in its planning process without extra preparation. The team can rehearse the output without sending live client reports, then verify the scheduled run after the change without producing duplicate deliveries.
That result gives the retirement decision a specific basis. The team can complete the replacement, preserve a narrowly defined capability, or explicitly accept the impact of ending support. Each choice comes with work that someone can own.
Before you retire a SaaS feature, follow one affected customer's next expected result. Find out what produces it, who relies on it, and whether the replacement can carry that work forward. You can then simplify the product around a workflow you understand.
