Sunsets and shutdowns: announcing the end of a product or feature

Every other entry in your changelog is about something getting better. The sunset entry is the one where you take something away for good — and it is the entry people will remember. Users who never once read your release notes will read this one, because it arrives as an email with a date in it and a knot in their stomach. Prospects evaluating your other products will find it years later and read it as evidence: this is how this company behaves when the news is bad.

That is the frame to write in. A shutdown announcement is not damage control and it is not a farewell blog post. It is the highest-stakes operational document you will ever publish: the reader has data inside your product, workflows built on it, and a deadline you just invented for them. This guide covers announcing the end of a feature, a product, or the whole company — what readers need in what order, the date ladder that structures everything, and the obligations that separate a respectful sunset from an unannounced breaking change with a eulogy attached.

The four questions, in the reader’s order

Sunset readers ask the same four questions every time, in the same order. Answer them in that order, because the reader stops trusting the document the moment it dodges one:

1. Is my data safe, and how do I get it out? This outranks everything, including the shutdown date. If the announcement’s first screen doesn’t link to a working export, readers assume the worst and start screenshotting. Name the formats, link the tool, state the retention window after lights-out.

2. What exactly stops working, and when? Scope and dates, precisely. “The Reports feature” is not a scope — name the API endpoints, the integrations, the mobile screens, the scheduled jobs. A reader should be able to audit their own usage against your list and know their blast radius.

3. What should I use instead? A named alternative — yours if you have one, a competitor’s if you don’t, and the honest sentence “no direct equivalent exists” when that’s the truth. More on this below, because it’s where most announcements lie.

4. How much work is the migration? An honest effort estimate, the same courtesy you’d give in any migration note: “export + re-import, about an hour” or “there is no automated path; budget a day per project.” Underselling this costs you the credibility the rest of the document needs.

Three scopes, ascending stakes

Feature sunset. The product lives; a piece of it goes away. This is close to a large deprecation — your deprecation policy should already govern the window and the channels, and the entry should say explicitly that it does. The trap: features have quiet dependents. The usage graph says twelve users; the support queue after removal says one of them was your biggest customer’s nightly export. Announce loudly even when the numbers say you don’t need to.

Product sunset. The company lives; a whole product dies. Everything above, plus the reader’s unspoken fifth question: is the product I’m still paying you for next? Say something true about the products that remain — their roadmap, their support commitment — because silence reads as “they’re next.” If accounts, billing, or identity are shared between the dead product and the living ones, spell out what happens to them.

Company shutdown. Everything dies, usually on a shorter clock than anyone wants. The obligations sharpen: data export becomes the entire announcement, retention promises need a named custodian (who is holding the data during the wind-down, and until when), and the norm worth copying from the best shutdowns is open-sourcing or escrowing what customers depend on. You will not be around to answer follow-up questions — so the announcement has to.

The date ladder

A sunset is not one date; it’s a ladder, and the announcement should print every rung:

  • Announcement day — today. The entry itself, dated, at a permanent URL.
  • No-new-users day — signups and new-project creation close. Existing use continues untouched.
  • Read-only day — writes stop; the product becomes a museum of itself. Optional, but the kindest rung: nothing breaks silently mid-workflow after it.
  • Lights-out day — the product stops answering.
  • Deletion day — exports close and data is destroyed. State it even though it’s after the end, because “how long do I have?” is question one wearing a trench coat.

Two rules govern the ladder. First: dates only move later, never earlier — the same iron rule as any breaking change. An extended deadline is a gift; an accelerated one is a betrayal that people post about. Second: the gaps must be survivable. The window between announcement and lights-out should scale with migration effort, not with your hosting bill’s renewal date. Six months is the credible floor for a product people build on; thirty days reads as contempt, and procurement teams remember it when your other products come up.

Export tooling ships before the announcement

The single most common sunset failure: announcing the end, then spending three weeks building the export tool while users refresh a broken settings page. The announcement’s credibility rests on the reader being able to act on it immediately — panic plus a working export equals relief; panic plus “export coming soon” equals rage plus a support ticket plus a screenshot thread.

Before the entry goes live: export exists, it’s linked from the entry, it emits formats something else can import (open formats beat proprietary dumps; a CSV nobody can re-import is theater), and it’s load-tested — announcement day is your export endpoint’s all-time traffic peak, guaranteed. If a competitor has an importer for your format, link it. Yes, really: the goodwill outlives the product, and those users were leaving anyway.

Name a real alternative (or admit there isn’t one)

The migration section is where sunset announcements traditionally lie, and readers know it. “Our new platform offers even more powerful workflows” — when the new platform lacks the one feature these users depended on — is the sentence that turns a sad-but-respectful shutdown into a betrayal narrative. The reader will discover the gap within an hour of migrating; the only question is whether your announcement warned them.

Honest patterns, in descending order of luck: a successor product with a real migration path (say exactly what carries over — and what doesn’t); a competitor that covers the use case (name them; the confidence reads as class); a partial answer (“X covers reporting; nothing we know of covers the automation piece”); and the hard truth (“no direct equivalent exists — here is your data in open formats”). Every one of these beats fake equivalence, because the reader’s migration plan is only as good as your candor.

Channels: the one announcement where email is mandatory

Everywhere else on this site we tell you the changelog is the canonical record and email is a channel you spend sparingly. A sunset is the case email exists for: the people who most need the news are precisely the ones not reading your changelog — dormant users with data inside. Email everyone with an account, not everyone on the newsletter. The changelog entry remains the canonical URL every other channel points at: the email links it, the in-product banner links it, the status page links it during the final hours.

Then repeat on a schedule, because one announcement is not an announcement — it’s a lottery ticket on attention. The working cadence: the announcement; a reminder at each ladder rung (no-new-users day, read-only day); a final-week email whose subject line is a date; and a last-call email to accounts that still haven’t exported, listing what they’re about to lose. That final email is the one users thank you for by name.

Tone: informative grief, not marketing

Two failure registers. The first is euphemism: “evolving our platform strategy,” “sunsetting to serve you better,” a headline that hides the verb. If the reader can’t tell from the first sentence that the product is ending and when, the announcement has failed at its only job. The second is the “incredible journey” register — three paragraphs about what the team learned, gratitude to investors, and somewhere below the fold, the date. Readers parse that structure instantly: the writer’s feelings outranked the reader’s data.

The working register is the one from bad-news changelog writing generally: plain verbs, the reason stated once and honestly (“usage never covered its costs” is respectable; adults know products cost money), one apology where it belongs, and every remaining sentence in service of the reader’s four questions. Thank your users at the end. They gave you their data and their workflows; the least the last entry can do is say so.

The entry, assembled

## Acme Reports is shutting down — export by March 1, 2027

Acme Reports will shut down on January 15, 2027. Your data is safe
and exportable today: Settings > Export gives you CSV and JSON of
every report, schedule, and dashboard. Exports stay open until
March 1, 2027, after which all Reports data is permanently deleted.

The dates:
- Today — new signups closed. Nothing changes for existing users.
- Nov 15, 2026 — read-only: reports stop running on schedules.
- Jan 15, 2027 — Acme Reports goes offline.
- Mar 1, 2027 — exports close; data deleted.

What to use instead: scheduled reports are covered by Acme Analytics
(importer for your exports: link). The custom SQL feature has no
equivalent in our products; Metabase covers most of it.
Migration effort: export + re-import, about an hour per workspace.

Why: Reports never reached sustainable usage, and keeping it running
was costing the attention Analytics needs. That's the whole reason.

This page stays up permanently. Questions: reports-eol@acme.com.

Thank you for building with it.

The changelog outlives the product

The strangest obligation and the most forgotten one: the announcement must survive the shutdown. The default failure is the whole domain going dark on lights-out day, taking the sunset entry with it — so the permalink in ten thousand emails, forum answers, and support macros now points at a parked domain, and users who missed the window can’t even find out what happened. Leave a tombstone: a permanent page with the announcement, the dates, the export-deadline outcome, and a contact route. It costs nothing to host and it is the difference between “they shut it down properly” and “they vanished.” If the product had a public changelog, keep the whole thing readable — an unbroken history that ends with an honest sunset entry is the best possible closing argument for every product you ship next.

Anti-patterns

  • The buried lede. Shutdown news in paragraph four of a monthly newsletter. A sunset gets its own entry, its own email, its own subject line with the product name and the verb in it.
  • Announce first, build export later. Every day between the announcement and a working export is a day of maximum-anxiety users staring at their trapped data.
  • The incredible-journey structure. Team feelings above the fold, reader facts below it. Invert it.
  • Fake equivalence. Pointing migrating users at a successor that lacks what they used. The gap will be discovered; only your candor is optional.
  • Dates that move earlier. Extending a deadline builds trust; accelerating one incinerates it, retroactively, for every promise you ever made.
  • The vanishing act. Domain dark on day one, permalinks dead, no tombstone. The cheapest page you will ever host is the one that says what happened.

Doing this with Wakelog

Wakelog is built around the properties a sunset needs: the entry lives at a permanent URL you can put in every email and banner; the announcement tag keeps it loud and filterable; scheduled publishing lets you write the whole reminder ladder the week you decide — announce now, rung reminders staged with publish_at — instead of trusting future-you to remember mid-crisis; and RSS/JSON feeds plus Discord/Slack webhooks carry each rung to subscribers automatically. And because your history exports as a portable changelog.md anytime, the record survives even if the infrastructure around it winds down — data portability is the promise we make you, so it’s one you can make your users. Honest caveats: Wakelog doesn’t send email, and a sunset is the one announcement where email is mandatory — pair the entry with your email tool. And your tombstone page should live somewhere you control for the long haul.

Give your announcements a permanent home   Next: writing a deprecation policy →

Related guides

Last updated 2026-07-28 · All guides