Sunsetting or Migrating a Legacy Product: Technical and Customer-Communication Mechanics

This is a genuinely new topic for this series — no prior guide covers a product's end of life. Two connections are worth naming. Our guide on production-grade software and technical debt covers what accumulates inside a codebase over time; unmanaged technical debt is frequently the actual reason a product eventually becomes a sunset or migration candidate in the first place, rather than a decision made for purely strategic reasons. Our guide on incident response and on-call covers the discipline of honest, structured communication during a production incident; a well-run product sunset borrows the same instinct — clear, timely, honest communication beats a slow, evasive one — even though nothing has technically broken. This guide covers the part neither of those touches: how companies have actually decided to sunset or migrate a product, the real technical mechanics of doing it safely, and the real, documented record of what happens to customer trust when it goes well and when it doesn't.

Deciding to Sunset or Migrate

Google's own well-documented history of shutting down products — tracked in detail by the real, community-maintained project killedbygoogle.com, created by Cody Ogden (whom Google reportedly approached about a job in 2020, per 9to5Google, April 14, 2020) — is worth knowing not because every shutdown it tracks is instructive, but because it illustrates a real, measurable reputational cost that accrues from a pattern of shutdowns, not just from any single one. A company that sunsets one product occasionally is making a normal business decision; a company that becomes known for a long, running list of abandoned products faces a specific, documented trust cost on every future product it launches, since potential adopters reasonably discount the odds that this one will still exist in three years. This is worth naming upfront because it changes the actual calculus of the decision: the cost of a sunset isn't contained to the customers of that one product, it extends to how skeptically every future product gets adopted.

The reasons a product actually reaches this decision point are varied but recurring across the real cases in this guide: declining usage relative to maintenance cost (Google's own stated reason for retiring Reader), a strategic shift toward consolidating overlapping products (Google folding Podcasts into YouTube Music), a platform-wide technology shift making the product obsolete (Adobe Flash, superseded by open web standards), or, less visibly but just as commonly, the accumulated technical debt our production-grade software guide covers making continued investment in a specific codebase genuinely more expensive than migrating its users to something newer. None of these reasons are illegitimate on their own — the mistake this guide focuses on isn't deciding to sunset a product, it's executing that decision badly once it's made.

Telling your own team before telling customers

A detail that's easy to overlook in the rush to plan the external announcement: the internal communication sequence matters nearly as much as the external one, and getting it wrong creates its own real, avoidable risk. Support and customer-success teams need to know a sunset or migration is coming, and understand the actual reasoning behind it, well before the public announcement goes out — not because they need advance warning as a courtesy, but because they are the people who will field the first wave of customer questions and complaints the moment the announcement lands, and a support team caught off guard by its own company's decision cannot answer those questions credibly. Engineers building the actual migration path need enough lead time to build and test it properly, following the expand/contract discipline covered later in this guide, rather than being handed a customer-facing deadline before the technical plan for hitting it safely actually exists. A sunset plan that nails the external messaging but surprises its own support team on announcement day tends to produce exactly the kind of inconsistent, contradictory answers to customer questions that erode trust faster than the underlying decision itself ever would.

A founder-specific version of this same mistake

At a small company specifically, this internal-sequencing failure tends to take a slightly different shape than it does at a company the size of Google or Microsoft: rather than a support team being blindsided, it's often a founder announcing a decision publicly — in a blog post, a tweet, an all-hands — before the actual technical and support groundwork behind it has been thought through in any detail. A founder excited to finally make a hard call, or eager to get ahead of a decision before it leaks, can announce a firm shutdown date before anyone has confirmed a real data-export mechanism exists, before support has any documentation to work from, and before engineering has estimated how long a safe expand/contract migration would actually take. This produces a worse version of exactly the same problem covered above: a public commitment the team then has to scramble to actually deliver on, under real time pressure it created for itself. The fix is the same at any company size — confirm the technical and support plan is real and achievable before the date attached to it becomes public, not after.

Real Deprecation Windows

Each of these is a real, independently verifiable, dated case worth knowing specifically. Google announced Reader's retirement on March 13, 2013 and shut it down July 1, 2013 — about 3.5 months (TechCrunch, March 17, 2013). Google Stadia followed a similar window: announced September 29, 2022, with servers shut down January 18, 2023, paired with a concrete mitigation — Google began automatically refunding game, hardware, and add-on purchases starting November 9, 2022, rather than leaving customers to request refunds individually (9to5Google, January 19, 2023). Microsoft's Wunderlist shutdown, announced December 2019 and completed May 6, 2020, gave roughly eight months (TechCrunch, December 9, 2019) — and Wunderlist's own original creator, Christian Reber, publicly expressed regret over the shutdown and offered to buy the app back, a real, on-record reaction from the product's own founder. Adobe announced Flash's end of life in July 2017 for a December 31, 2020 shutdown — over three years of notice, coordinated jointly with Apple, Google, Microsoft, Mozilla, and Facebook all committing to disable Flash by the same date (Qualys Blog, December 21, 2020).

It's worth being direct about a gap in the available research: this guide could not locate a single, credible, named expert or peer-reviewed source establishing a specific, evidence-based recommendation for how long a B2B SaaS deprecation window “should” be. Generic claims that “6–12 months is industry standard” circulate widely across marketing and SEO content, but none trace to a verifiable original authority, so this guide does not repeat that framing as an established rule. What is verifiable and worth anchoring to instead are real, specific company policies: Twilio's own published deprecation lifecycle states a 12-month window from when something is marked deprecated to its end-of-life date, after which “continued operation is not guaranteed” ( Twilio, Versioning and Support Lifecycle), and Stripe's own SDK versioning policy states an extended support window of one to two years after an underlying language runtime itself reaches end of life, pre-announced across the documentation page, each SDK's README, and each language's changelog (Stripe, SDK Versioning Policy).

What actually should influence how long a window needs to be

In the absence of a single, authoritative recommended number, the real cases in this guide still point toward a few concrete, checkable factors worth weighing directly, rather than picking a window length arbitrarily. How deeply integrated the product is into a customer's own workflow matters enormously — Adobe's multi-year Flash window reflects just how deeply embedded Flash content was across the entire web, requiring coordination not just with end users but with every website still running Flash content and every browser vendor that had to ship a corresponding change, a fundamentally different situation from a single consumer app like Google Reader with no comparable dependency chain. Whether a real, working migration path already exists at announcement time is a second concrete factor: Wunderlist's eight-month window reflects the reality that Microsoft needed real time to build out feature parity in Microsoft To Do before asking users to move, whereas a shorter window is more defensible when a genuinely equivalent destination already exists and is already stable at the moment of announcement. And the customer base's own switching cost is a third factor worth weighing honestly: an individual consumer switching RSS readers, as with Google Reader, faces a meaningfully lower cost than a business customer whose own operations or downstream integrations depend on a specific API behavior, which is precisely why Twilio's and Stripe's own B2B-facing policies default to windows measured in a year or more rather than a few months.

The Technical Mechanics of a Safe Migration

The expand/contract pattern runs in three phases, as documented in Ambler and Sadalage's book (Addison-Wesley) and on Martin Fowler's own site under the name “Parallel Change”: expand (add the new schema or system alongside the old one, without removing anything yet), migrate (transition code and data over to the new system while both remain available), and contract (remove the old schema or system only once the migration is fully verified and nothing still depends on it). The value of this structure is that it never requires a single, risky, all-at-once cutover moment — every step is independently reversible, and a problem discovered partway through the migration doesn't require a full rollback of work already completed.

Stripe's own engineering blog post, “Online migrations at scale,” published February 2017, documents a real, concrete application of this pattern at real scale: migrating more than 100 million subscription records to a new data store with zero downtime (Stripe Engineering, “Online migrations at scale,” February 2017). Stripe's approach read from both the old and new data stores simultaneously in what the post describes as a shadow-read approach, comparing the two results in real time and only routing production traffic fully to the new store once mismatches had been found and resolved. A closely related, independently documented tool for the same underlying idea is GitHub's open-source Scientist library, built specifically to let engineers refactor a critical code path — GitHub's own example is the system controlling repository, team, and organization permissions — by running the old (“control”) and new (“candidate”) logic in parallel against real production traffic, always serving users the control path's result while logging any place the two disagreed (GitHub Blog, “Scientist: Measure Twice, Cut Once”).

The common thread across all three real, independently documented approaches is worth naming explicitly: none of them treats verification as a step that happens after the cutover. Each one builds the comparison between old and new behavior into the migration itself, so that a mismatch is caught while the old system is still safely serving real traffic, rather than discovered only after customers are already depending on a new system that might be silently wrong. For a small team without Stripe's or GitHub's scale, the transferable lesson is the principle, not the specific tooling: whatever the migration, build in a way to compare old and new behavior before the old system is actually removed, rather than trusting that testing before the cutover was sufficient.

Data Portability and Export

GDPR Article 20's exact text is worth quoting directly rather than paraphrasing, since the specific language sets a real, checkable bar: “The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance” (Regulation (EU) 2016/679, Article 20). Google Podcasts' own 2023 shutdown announcement gives a concrete, real illustration of this principle applied in practice, even for a product without a strict GDPR obligation attached to podcast subscriptions specifically: alongside its built-in transfer tool to YouTube Music, Google also offered an OPML export — a standard, portable format usable with any third-party podcast app, not just Google's own replacement product (TechCrunch, September 26, 2023). This is the concrete, practical takeaway worth borrowing regardless of whether GDPR technically applies: offering an export in a real, standard, portable format — not a proprietary one only readable by the company's own replacement product — is both the more customer-respecting choice and, per Article 20, the actual legal standard for at least the EU users a growing product will eventually have.

Real Deprecation Communication Policies

Twilio's public changelog is a genuinely useful reference to study directly, since it shows the policy applied repeatedly across many real, dated, individually announced deprecations rather than as a one-time abstract statement — examples include the Notify API end-of-life notice (dated for December 31, 2025), a reminder notice for the end of life of Twilio's 2008 API (effective December 15, 2023), and the end of life of a specific Sync API endpoint (effective March 10, 2025) (Twilio Changelog). Twilio's own documented lifecycle moves from a Deprecated phase to End of Life roughly 12 months later, after which the company states “continued operation is not guaranteed” — language that is honest about the real risk of continuing to depend on a deprecated system past its stated window, rather than implying an indefinite, unstated grace period. Stripe's policy takes a related but distinct approach centered on API versioning: each account is pinned to a specific API version at creation, so a backward-incompatible change ships as a new dated version rather than breaking every existing integration silently, while a backward-compatible change can roll out as a safe upgrade without requiring any customer action at all (Stripe, API Versioning).

What makes both of these genuinely useful models, beyond their specific notice periods, is that they treat deprecation communication as a standing, repeatable process rather than a one-off announcement written fresh each time something needs to be retired. A team building its first version of this kind of policy doesn't need Twilio's changelog infrastructure or Stripe's versioning system on day one, but the underlying discipline transfers directly at any scale: publish deprecation notices in one consistent, predictable place, state an explicit end-of-life date rather than a vague future timeframe, and be direct about what actually happens — and what stops working — once that date passes.

Supporting Customers During the Transition Window

It's worth being concrete about what this dual-support period actually involves, since it's frequently treated as an afterthought during planning. Support staff need real, accurate documentation for both the legacy product and the new destination simultaneously, and need to be able to tell, quickly, which system a given customer is currently on before troubleshooting anything — a nontrivial operational requirement if the two systems don't share a common account or support-ticket system. Engineering capacity gets split between finishing the migration tooling, fixing any remaining bugs in the legacy system customers are still actively depending on, and building out the new destination's remaining gaps, which is exactly the kind of resource competition that causes migration timelines to slip in practice even when the original notice period looked generous on paper. And critically, the legacy system cannot simply be deprioritized to a skeleton-maintenance level the moment the announcement goes out, precisely because a meaningful share of the customer base is still depending on it in full for the entire duration of the notice window — a lesson the GitLab incident covered in our incident response and on-call guide illustrates from a different angle: a system still in active use needs a real operational safety net for as long as it remains in active use, deprecation notice or not.

The practical planning implication is that the length of the notice window and the operational cost of the dual-support period aren't independent variables to optimize separately — a longer window reduces the pressure and risk of a rushed cutover, but extends how long the team has to carry the cost of running two systems at once. This is exactly why a genuinely working destination at announcement time, rather than one still being built during the notice period, matters as much as the length of the window itself: it's what actually lets customers migrate early and voluntarily throughout the window instead of all waiting until the deadline, which is what determines whether the dual-support burden shrinks steadily over the notice period or stays at full intensity until the very last week.

When Backlash Happens: Two Real Cases

The Google Reader petition, started by Daniel Lewis on Change.org, passed 30,000 signatures within a single day of the announcement (TechCrunch, March 14, 2013) and ultimately passed 100,000 signatures (The Next Web). Google did not reverse its decision, responding only by restating its original blog post's reasoning about declining usage. Nine years later, Google's attempt to force legacy free G Suite users — some of whom had used the free tier since 2006, described in coverage as “16 years at no cost” — onto paid Google Workspace starting July 1, 2022 produced a comparable public backlash (The Register, January 20, 2022). This time, Google reversed course: non-commercial legacy users were allowed to opt out of the paid migration entirely, keeping their custom domain, Gmail, and free access to Drive and Meet (TechCrunch, January 28, 2022).

“Google will no longer penalize free G Suite legacy users.”

— TechRadar, covering Google's reversal of its forced 2022 Workspace migration for legacy free-tier users

The honest, useful distinction between these two real cases isn't that one petition was “bigger” than the other — both reached comparable scale. The more instructive difference is what was actually being asked of users in each case. Google Reader's shutdown removed a free product entirely, with no path to keep using it at any price; the backlash, however large, was against a decision with no available compromise short of not shutting it down at all. The G Suite Legacy situation was different in kind: Google was asking existing, long-standing free users to either start paying or lose access, which left an obvious middle path available — letting them keep what they already had, at no cost, rather than forcing a binary choice. When a middle path genuinely exists, real backlash has historically had more leverage to produce a reversal than when the available choice is a strict binary between an old product continuing to exist and it not existing at all.

The Legacy-Support Alternative

37signals' own post is worth reading directly for how explicitly it commits to this approach as a standing philosophy rather than a temporary accommodation (Signal v. Noise, “A Love for Legacy”): the company states plainly that Basecamp Classic would keep running indefinitely, with a dedicated internal team responsible for its ongoing security and performance, rather than being shut down once Basecamp 2 and Basecamp 3 existed. 37signals' own public help documentation independently confirms this is a real, still-standing, dated policy rather than a one-time statement, describing exactly how customers can keep their older paid Basecamp tier for free (37signals Help, “Keeping Basecamp 2 or Classic for Free”). This is a genuinely different strategic choice from every other case in this guide: rather than treating the older product as a cost to eliminate once a newer version exists, 37signals treats honoring its existing customers' continued use of what they originally chose as worth the ongoing maintenance cost.

It's worth being honest about when this approach is realistic and when it isn't. Maintaining a legacy version indefinitely only works when the ongoing maintenance cost is genuinely bounded and predictable — a stable, mature codebase without active new development needs, and importantly, one that doesn't depend on infrastructure or third-party services that will themselves eventually be deprecated out from under it. A legacy product built on infrastructure the company doesn't control — a deprecated third-party API, an end-of-life operating system, or the kind of AI-vendor dependency our AI feature integration guide covers — can't realistically be kept running “forever” the way 37signals describes, because its continued existence depends on decisions outside the company's own control. For a founder considering this path, the honest question is whether the legacy product can actually be frozen and left alone safely, or whether it will require the same ongoing engineering investment as an actively developed product just to keep functioning — in which case the legacy-support approach isn't actually cheaper than a well-executed migration, it's just a slower, less disciplined version of the same cost.

Communicating a Sunset Well

Bringing the real cases above together into concrete, actionable communication guidance, rather than abstract principles:

1. 1

   State a specific end-of-life date, not a vague future window

   Twilio's and Stripe's own published policies both name specific dates rather than a fuzzy "sometime next year" — customers can plan around a date; they cannot plan around ambiguity.

2. 2

   Provide a real export in a standard, portable format

   Per GDPR Article 20's own language and Google Podcasts' real OPML export, a genuinely portable export — not a proprietary format only usable inside the company's own replacement — is both the more respectful and the more legally sound choice.

3. 3

   Look honestly for a middle path before assuming a binary shutdown

   The G Suite Legacy reversal succeeded specifically because a middle path (free legacy access) existed and Google eventually offered it. Before announcing a hard cutoff, check whether a reduced, low-cost, or read-only continuation is genuinely feasible.

4. 4

   Explain the real reason, plainly, the way Google did for Reader

   Even when a decision isn't reversed, stating the actual reason (declining usage, consolidation, cost) directly — rather than vague corporate language — is what separates an announcement customers can accept, even unhappily, from one that reads as evasive.

One further point worth naming directly, since it recurs across every real case in this guide: the quality of the technical migration and the quality of the communication are not independent of each other. A technically excellent migration announced badly still produces real backlash, and a well-communicated migration built on a rushed, unverified technical cutover still produces real customer harm regardless of how well the announcement was worded. The expand/contract pattern and the shadow-read verification approach covered earlier in this guide aren't just engineering best practices in isolation — they are what actually lets a company make the honest, specific communication promises above (a firm date, a real export, no silent data loss) and actually keep them.

A Practical Framework

Bringing the research above together into an actual sequence for a team facing its first product sunset or migration:

None of this guarantees a sunset or migration goes over well — Google Reader's 100,000-signature petition happened despite Google giving a real reason and a real, if short, notice window. What the real cases in this guide do show is that the technical and communication choices covered here are the difference between a company that can point to a coherent, defensible process when backlash arrives (as Google did for Reader, even without reversing course) and one that has no real answer for why a specific date, a specific export, or a specific communication choice was made the way it was. A sunset handled this way doesn't guarantee customers stay happy. It does mean the company can stand behind exactly what it did, which is the more durable asset once the immediate backlash, if any, has passed.

Frequently Asked Questions

Every real case in this guide involves a company that eventually had to end or change something customers depended on — there is no version of this process that avoids that fact entirely. What separates Google's handling of Reader from Adobe's handling of Flash, or Google's initial G Suite Legacy misstep from its own eventual reversal, isn't whether customers were disappointed. It's whether the company gave itself, and its customers, a real technical foundation and a real, honest timeline to work with — the two things every credible case in this guide has in common, and the two things a company facing this decision for the first time has full control over, regardless of how the announcement is ultimately received.