Explain a Product Retirement Before Asking Customers to Migrate

By pitch.dogFoundation14 min read20 September 2026

Business

The deck is nearly finished. Eleven slides on the replacement: faster setup, a cleaner interface, the roadmap through next year. On slide twelve, in italics along the bottom, is the sentence that matters most to the reader: Scheduler will be retired later this year.

That italic line is the announcement. Everything above it is a pitch that arrived before the news, and readers sort the two instantly. The pitch is what the sender wants. The italic line is what the reader is about to lose. When a message leads with the first and buries the second, the reader spends the rest of the deck waiting for the other shoe and discounting everything they're told in the meantime.

The rest of this article works through one invented example. Halden Software, a company that does not exist, is retiring Halden Scheduler, a shift-scheduling tool used by operations managers, and offering Halden Plan in its place. The dates are left as a marked gap on purpose. No customer account, migration test, support entitlement, or agreement is claimed anywhere in what follows.

The order that works is unglamorous: say what ends and when, say what it does to the reader's work, say what their options are and how those options differ, say who to ask. Then make the case for the replacement. GOV.UK's service manual guidance on retiring a service, in an observation recorded as checked on 8 September 2026, asks teams to consider what users still need and to explain the change, the alternatives, and what users should do next. That is UK public-service guidance — not a US notice rule, not a legal requirement, and no evidence that any particular replacement suits any particular customer. What it supports is the sequence: change, alternatives, action.

State the ending in terms the customer can act on

"Halden is retiring Halden Scheduler" does more work than "We're evolving our scheduling portfolio," and it does that work in the first sentence instead of the twelfth. The reader's first question is not what's better? It's what am I losing? Answer it before anything else.

A retirement is rarely one thing. Four different endings get collapsed into the word discontinued, and they mean different things to the person planning next quarter:

New sales end. Nobody else can buy it. Existing customers may notice nothing.
Development ends. No new features. Bug fixes may or may not continue.
Support ends. The product runs, but nobody answers questions about it.
Access ends. It stops working.

If you write only "discontinued," every reader guesses, and some guess the worst version. Say the one that's true. In the Halden case the decision is a full retirement — Scheduler stops running — so the announcement states that plainly and skips the other three rather than listing all four for the appearance of thoroughness.

Then the date. You don't get to approximate it. If the person who owns the end date hasn't confirmed it, the announcement waits or carries a visibly marked place for it. "Later this year" tells a customer nothing they can plan against, and it turns an operational fact into a vague threat that they will discuss with their own leadership before you've given them anything to work with. Don't invent a notice period either. Whatever notice the reader is entitled to comes from their agreement or the law, not from the deck. If someone on your team says "we'll give ninety days," check that they can before it reaches a customer.

Finally, what remains. In the Halden example, everything remains: accounts work as they do today, right up to the end date. Saying so matters, because retired sounds like already.

Translate the change into the customer's existing workflow

The unit of concern is the customer's Tuesday: the rotation patterns someone built up over three years, the payroll run that depends on approved shifts landing in another system, the manager who prints the schedule because the yard office has bad wifi.

Three items from the Halden example, each landing on a different person:

Settings and permissions don't carry over. Halden Plan is a separate product, and the custom rotation patterns and user permissions in Scheduler have to be rebuilt in it. Nobody outside the customer's operation knows how much work that is. The person who built those patterns does.

Plan runs in the cloud only. Scheduler kept a copy of the schedule on the site's own network. If some sites work from that local copy, whether the routine still works is a question for the customer's IT team, not for yours — but the announcement is where they find out they need to ask.

The Timekeep sync is unconfirmed. Some customers push approved shifts from Scheduler into Timekeep, a timekeeping system. Whether Halden Plan can do the same thing has not been established. That is not a gap you cover with "seamless."

That last one deserves its own sentence, because "we don't know yet" is a legitimate thing to write in a retirement notice, provided a name follows it. Whether Plan can sync with Timekeep is still being assessed. Devrim Aksoy's engineering team owns that answer, and has not committed to a date for it. What is not legitimate is "we're working to ensure a smooth transition," which sounds like an answer, behaves like a delay, and teaches the reader to distrust the next sentence that sounds like an answer too.

Keep the confirmed and the unconfirmed in separate rooms. A product name change is a naming statement; it establishes nothing about how anything works. "Halden Plan replaces Scheduler" tells the reader which logo to look for. It does not tell them that the Friday payroll run will be fine, and readers who have been through a migration before will assume it won't be.

There are two decisions inside one announcement, made by two different parties. Yours: the product is ending. Theirs: what to do about it. Most of the trouble in retirement messaging comes from blurring which one is which, and the blurring usually shows up in the tense.

You'll be moving to Halden Plan. Future tense, delivered as if the reader already agreed. Compare: Halden Plan is available if you want to keep scheduling with Halden. The second one tells the reader they still have a decision, because they do.

An honest options list for the Halden case has three items, and each costs the customer something:

Move to Halden Plan. Covers scheduling and shift swaps; settings, patterns, and permissions have to be rebuilt; the Timekeep question is open; whether their existing agreement applies is a question for Priya Raghavan's transition team, not something to assume.
Export the schedules and run scheduling somewhere else. The export works until the end date. This is a real option and naming it costs you nothing except the pretense that there's only one path.
Stop scheduling with Halden. Genuine for accounts that only ever used Scheduler for one site or one team.

If your list has one item, it isn't a choice and it shouldn't be laid out like one. And if you present the alternatives, present the differences rather than a benefits column. A benefits column with no corresponding account of what changes is a brochure, and readers treat brochures as advertising, which means they stop reading the parts that were true.

Say plainly what does not move on its own: data, settings, user permissions, integrations, agreement terms. Every one of those defaults to "no" unless a specific person has confirmed otherwise, and "we haven't said it won't" is not confirmation. If your announcement mentions billing, contracts, retention, or data handling, the sentences belong to whoever can actually state them. Silence in those areas implies continuity, so if the answer isn't settled, name it as unsettled and name its owner rather than leaving the reader to assume nothing changes.

One more thing worth separating: the ending is decided, the next step is not. "Halden has decided to retire Scheduler" and "you have options for what comes next" can sit in the same message without contradicting each other. They only sound contradictory to a writer trying to make the first sentence pleasant.

Specify the next supported step

Name the owner of each open question, name the assistance that actually exists, and name the action. Devrim Aksoy's team owns the Timekeep assessment. Priya Raghavan's transition team owns account-specific questions and hosts transition conversations. Neither of those is a promise that a particular outcome will arrive.

Keep the promised help inside the confirmed scope. If the transition team is two people offering a thirty-minute call, don't write "dedicated migration support." The customer will discover the difference at the worst possible moment, and the discovery will reframe everything else you told them.

Watch the verbs around that call. A request to book a transition conversation is not evidence that the customer has agreed to migrate, and customers read "book your migration" buttons as commitments. Say what the call is: a conversation about what your options look like in your account, not a decision to move. That sentence is short and it removes most of the reason a customer delays replying.

And keep the contact real. "Contact your account manager" fails for the large share of customers who don't have one or don't know their name. If there's one transition inbox, give its address, because an instruction the reader can't carry out is not an instruction.

Here is the draft as it stands, with the end date still marked, because the person who owns it hasn't filled it in yet:

Halden Scheduler is ending

Halden has decided to retire Halden Scheduler. The last day Scheduler runs is [end date — to be confirmed by Rosa Delgado, product owner for Halden Scheduler, before this is sent]. Until that date, your account works as it does today, including the export.

What this changes for you

Scheduler stops running on the end date.
Halden Plan is a separate product. Scheduler settings, custom rotation patterns, and user permissions do not carry over; they have to be rebuilt in Plan.
Halden Plan runs in the cloud only. Scheduler kept a copy of the schedule on your own network. If your sites work from that local copy, ask your IT team whether that routine still works for you.

What we don't know yet

Whether Halden Plan can sync with Timekeep. Devrim Aksoy's engineering team is assessing it and has not committed to a date. Don't plan on the assumption that it will.
Whether your existing Scheduler agreement applies to Halden Plan. Priya Raghavan's transition team will confirm that for your account. Nothing transfers on its own.

Your options

Move to Halden Plan.
Export your schedules and run scheduling elsewhere. The export works until the end date.
Stop scheduling with Halden.

Next step Email the transition inbox at [email protected] to book a conversation with Priya Raghavan's team. Booking is not a decision to migrate — it's a call about what your options look like in your account.

The date placeholder is not a hole in the writing. It's the difference between a draft and something that can be sent, and leaving it visible is how you find out that nobody has actually confirmed the date.

Check the message from the affected customer's position

Read the draft as someone whose operation depends on it. Four things need to be findable without decoding: what ends, what it does to their work, what their options are, and who to ask. If any of those requires assembly across three paragraphs, the message has not done its job, no matter how well it reads.

Then separate the supported benefit from the softening.

"Plan builds a schedule in half the time" is either a claim with a source or it's noise. If it has a source, it belongs after the consequence, addressed to a reader who now knows what they're choosing between. If it doesn't, cut it, because a number invented to balance bad news is the thing that gets quoted back at you by an angry customer in a way no one can defend.

Reassurance is not neutral either. "Nothing will change for you" is a claim, and if it isn't yours to make, writing it is a different error from writing nothing — the first one spends trust you'll need later. Where terms, obligations, or a particular customer's situation are uncertain, route the question to the responsible owner in the message itself. Writing around uncertainty with calm language shifts the work of guessing onto the person least equipped to do it.

Last, keep the announcement and the sales follow-up as two messages. They have different jobs and they arrive at different moments. The announcement makes the ending intelligible and the path visible, to everyone, including people who are going to leave. The pitch comes afterwards, to people who at that point know what they're saying yes or no to. Combining them looks efficient and costs you the only thing the first message had to establish: that you told them the truth before you asked them for anything.

What ends: Scheduler, on a date that belongs to Rosa Delgado, not to the marketing team's deadline. What remains: everything, until then, plus an export and three real options. Who owns the next step: Devrim Aksoy for the integration question, Priya Raghavan for everything account-specific, and the customer for the decision itself. That's the whole announcement. The replacement's advantages can follow it into the room, and they'll land better for having waited.

Frequently asked questions

What order works for a retirement announcement?

Say what ends and when, say what it does to the reader's work, say what their options are and how those options differ, and say who to ask. Then make the case for the replacement. The article cites GOV.UK service manual guidance on retiring a service, checked on 8 September 2026, which asks teams to consider what users still need and to explain the change, the alternatives, and what users should do next. The article states this is UK public-service guidance, not a US notice rule, not a legal requirement, and not evidence that a particular replacement suits any particular customer.

Why distinguish types of ending instead of saying the product is discontinued?

'Discontinued' collapses four different endings: new sales end, development ends, support ends, and access ends. Each means something different to a reader planning next quarter, and readers who only see 'discontinued' may guess the worst version. State the true one. The date must also be one the customer can act on. If the owner of the end date has not confirmed it, the announcement waits or carries a visibly marked place for it; 'later this year' gives nothing to plan against. Do not invent a notice period, because whatever notice the reader is entitled to comes from their agreement or the law.

How should the change be translated into the customer's workflow?

Use the customer's Tuesday as the unit of concern: rotation patterns built over years, a payroll run that depends on approved shifts landing in another system, a manager who prints the schedule because the yard office has bad wifi. In the Halden example, settings and permissions do not carry over and must be rebuilt; Plan runs in the cloud only while Scheduler kept a local copy, so the customer's IT team must assess whether the routine still works; and whether Plan can sync with Timekeep is still being assessed. The article says to keep confirmed and unconfirmed items in separate rooms, and name the owner of the unconfirmed answer rather than covering the gap with vague reassurance.

Separate the two decisions: yours is that the product is ending; the customer's is what to do about it. Avoid future-tense language such as 'you'll be moving to Halden Plan' and instead say Plan is available if they want to keep scheduling with Halden. An honest options list has three items: move to Plan, export schedules and run scheduling elsewhere, or stop scheduling with Halden. Present differences rather than a benefits column, and say plainly what does not move on its own: data, settings, user permissions, integrations, and agreement terms. If billing, contracts, retention, or data-handling answers are unsettled, name them as unsettled and name their owner.

What should the next supported step look like?

Name the owner of each open question, the assistance that actually exists, and the action. Keep promised help inside the confirmed scope: if the transition team is two people offering a thirty-minute call, do not call it dedicated migration support. A request to book a transition conversation is not evidence that the customer has agreed to migrate, so say the call is about options in their account, not a decision to move. Keep the contact real, such as one transition inbox, because 'contact your account manager' fails for customers who do not have one or do not know the name. The article also says to keep the announcement and the sales follow-up as two messages.