पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 29 · Scale
Sunsetting a feature or a product without losing trust
Products have to be retired for a company to stay focused. Done with a real notice period, a migration path and steady communication, it costs few customers and builds trust.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
Every product that lives long enough accumulates features that a few customers love and nobody else uses, and versions the company would never build today. Retiring them is part of the job. The difference between a retirement customers forgive and one they remember is almost entirely in how it is done.
This lesson covers when to retire a feature or product, how long the notice should be, with a figure that shows the trade-off, how to make migration the real work of the deprecation, and the sequence of messages that keeps customers through it.
Why products have to die
Everything in production has an upkeep: hosting, security patches, support tickets, the engineer who still understands it, and the test suite every release must pass. The [feature requests lesson](/library/feature-requests-discipline-of-saying-no) calls this the upkeep tax, and it never stops. Old features also slow every new one, because each change must be checked against them. A company that never retires anything gets slower every year.
The reasons large companies give are instructive. When Google announced the end of Google Reader on 13 March 2013, it said the product had a loyal following but usage had declined, and that the company was focusing on fewer products. When Heroku ended its free plans, announced on 25 August 2022, it cited the effort spent managing fraud and abuse of the free tier. Focus and cost are the two honest reasons. Both are better said plainly than dressed up.
Decide with the numbers
Before announcing anything, build one page. Usage: how many customers used the feature in the last ninety days, and how often. Revenue attached: what those customers pay, and how many of them use little else. Upkeep: hosting, support hours and engineering time spent on it in the last two quarters, in rupees. Replacement: what customers should use instead, whether it already exists and whether it does the job. A feature used by 2 per cent of customers who also use everything else is easy to retire. One used by 2 per cent who pay for nothing else is a product decision about those customers, and may need a different answer: a price, a partner or a spin-out.
Retirement is not the only exit. A product with a small loyal base can sometimes be handed to a partner who serves that segment, sold to a team that wants it, or kept on a frozen version with a higher price that covers its upkeep and an honest note that nothing new will ship. Each of these keeps customers whole and the company focused. Consider them before the announcement, because after it customers will assume the decision was final.
A notice period sized to the work of leaving
Notice periods in practice vary widely. Google gave Reader users from 13 March to 1 July 2013, under four months. Heroku gave about three months, from 25 August to 28 November 2022. Google Cloud’s service terms commit to notify customers at least 12 months before discontinuing a service or making backwards-incompatible changes to a customer-facing API, unless a materially similar replacement exists. Stripe has gone further: in its post on API versioning it says it has maintained compatibility with every version of its API since 2011.
The right length depends on the work customers must do to leave. A consumer feature that disappears from a menu needs weeks. A product that holds a business’s records needs months, because the customer must export data, retrain staff and perhaps change a process. An API that other software calls needs a year or a version that never breaks, because the customer’s engineers must find time on their own roadmap. The figure below shows the trade-off: short notice strands customers, long notice pays for two products.
At the defaults, 800 customers paying ₹6,000 a month, migrating at 8 per cent a week after notice, and an old system that costs ₹1.5 lakh a week to keep running, twelve weeks of notice leaves about 294 customers stranded and a year’s revenue at risk of about ₹85 lakh. The lowest total cost sits near 31 weeks. Raise the migration rate to 14 per cent, the effect of a good migration tool, and the best notice shortens to about 21 weeks while the total cost falls by a third. The lesson in the curve is that the notice period matters less than the migration rate. Spend the notice making it easy to leave.
The notice period buys time. The migration path decides how many customers use it.
The migration is the product
Treat the migration as a product with an owner, a metric and a weekly review. The metric is the share of affected customers who have moved. Four things raise it. A data export that works in one step and produces a format the replacement or a competitor can read; Google pointed Reader users to Takeout for their subscriptions. A named replacement, inside the company or outside it, with a guide for moving. Hands-on help for the accounts that matter: a call, a migration done by the company’s team, a price held for a year. A deadline that does not move. Customers learn quickly whether a date is real, and a date that slipped once will be ignored the second time.
The communication sequence
One clear announcement says what is ending, the date, why, what to use instead and how to get help. It goes by email, in the product where the feature lives, and through account managers to the largest customers before the public note. Reminders follow on a fixed schedule, for example at half the notice period, at four weeks, at one week and on the day, each with the share of the work the customer still has left if the product can show it. After shutdown, a final note confirms what happened to the data.
That last note has a legal side. Under Section 8(7) of the Digital Personal Data Protection Act, 2023, a data fiduciary must erase personal data once it is reasonable to assume the specified purpose is no longer being served, unless a law requires it to be kept, and must make its processors erase it too. A retired product with a database nobody looks at is personal data kept past its purpose. Plan the deletion, with retention only for what tax or other law requires, as part of the shutdown; the [DPDP lesson](/library/dpdp-act-what-it-requires-of-your-product) covers the rest.
Prepare the company before the customers. Sales must stop selling the retiring product the day the decision is made, and every open proposal that mentions it must be revised. Support needs a script, a migration guide and a route for the hard cases. Account managers need the list of their customers on the product and what each will be offered. A customer who hears about the retirement from a support agent who did not know is far more likely to leave than one who hears it first from her account manager.
A worked example: clinic software in Hyderabad
A Hyderabad company sells practice-management software to clinics. Its old Windows desktop version still runs in 800 clinics paying ₹6,000 a month, while the cloud version serves everyone else. Keeping the desktop build alive costs about ₹1.5 lakh a week in support and two engineers. The first plan was twelve weeks of notice. The figure showed that at the expected migration rate nearly 300 clinics would still be on the desktop at shutdown, and that losing two in five of them would cost far more than the support bill.
The team built a one-click tool that moves patient records and appointment history to the cloud, offered a free onboarding call to every clinic, and held the desktop price for a year on the cloud version. In a pilot with forty clinics the weekly migration rate rose to about 14 per cent. The company announced a six-month deadline. At that rate fewer than twenty clinics should be left on the last day, and the account team calls each of them personally in the final month. Patient data on the retired servers is deleted on a published date after the shutdown, except what the law requires the clinics to retain.
The weekly deprecation check
From announcement to shutdown, the migration owner reviews one sheet every week. The share of affected customers migrated, against the curve needed to meet the date. The list of the largest unmigrated accounts and who is talking to each. Support tickets about the migration and the top three problems in them. Reminders sent and due. The data deletion plan and its date. If migration falls behind the curve for two weeks running, the answer is more help or a better tool, not a later date.
The figure is a simplified model and the Hyderabad company is illustrative. Company dates and terms are as published, checked 11 October 2026. Nothing here is legal advice.
Sources
- Google, A second spring of cleaning, 13 March 2013 — Google Reader retired on 1 July 2013; data export through Takeout.
- Heroku blog, the end of free product plans, 25 August 2022 — Free plans ended 28 November 2022; reason given as fraud and abuse.
- Google Cloud Platform Terms of Service, section 1.4(e) Discontinuation of Services (checked 11 October 2026) — At least 12 months’ notice before discontinuing a service or breaking a customer-facing API.
- Brandur Leach, post on API versioning, Stripe blog, 5 August 2017 — Compatibility maintained with every API version since 2011.
- Digital Personal Data Protection Act, 2023, Section 8(7) — Erasure when the specified purpose is no longer served, and by processors.