Every other page on your site is read by someone deciding whether to buy. A deprecation notice is read by someone who already bought, and is now being told that the thing they bought is going away.
That flips the job of a testimonial completely. On a pricing page, a quote answers "is this worth it?" On a sunset page, the only questions that matter are "how much work is this going to be for me?" and "is the replacement actually going to be worse?" A quote that praises your company answers neither, and reads as tone-deaf on a page whose entire purpose is to deliver bad news.
But the right quote is genuinely useful here, and most teams leave it out because they assume any testimonial on this page is in poor taste. That is half right. The distinction is narrow enough to state in one line.
The rule that governs this page
Every quote on a sunset page must come from someone who has already completed the migration you are asking the reader to start.
Not a happy customer. Not an enthusiastic review of the replacement product. Someone who was on the old thing, moved to the new thing, and can say what that was like — including the parts that were annoying.
That quote is evidence. Everything else is a company celebrating on a page where its customers are inconvenienced.
Slot 1: never above the notice itself
The top of the page belongs to four facts, in this order: what is being deprecated, the end-of-life date, what replaces it, and where the migration guide is. No quote, no logo wall, no "what our customers say" band goes above that block.
A reader who has to scroll past a testimonial to find their shutdown date will remember it, and not kindly. This is the single most common mistake on these pages, and it is entirely self-inflicted.
Slot 2: immediately after the migration path, as a difficulty estimate
Once you have told the reader what to do, the most valuable thing you can give them is a realistic sense of how long it takes. Your own documentation will say "most migrations take under an hour," and nobody believes it, because you are the one who created the work.
A customer saying it is a different claim:
"We had 340 webhooks on the legacy endpoint. The script in the migration guide handled about 300 of them; the rest were custom payloads we had to redo by hand. Total, it took one engineer a day and a half — not the two weeks we'd budgeted." — Platform lead, logistics SaaS
Why this works on a page where most quotes fail:
- It contains a number that is not flattering. Forty webhooks needed manual work. Admitting that is what makes the day-and-a-half credible.
- It is scoped by scale. A reader with 12 webhooks and a reader with 3,000 can both calibrate from it.
- It corrects an expectation in the reader's favor. They budgeted two weeks; it took a day and a half. That is the useful shape — not "it was easy," but "it was less than we feared, for these reasons."
One quote here. If you have customers at very different scales, two — a small one and a large one, clearly labeled by scale, so a reader can find themselves.
Slot 3: next to the replacement product, but only on capability
If the deprecated feature is being replaced, readers have a specific fear: that the new thing does less. Often they are right about one or two capabilities, and they will find out at the worst moment.
A quote here should speak to a capability, not to satisfaction:
"The old exporter gave us CSV only. The new one does incremental syncs, which killed a nightly job we'd been maintaining for three years. We didn't ask for that — it just came with the move." — Data engineering manager, healthcare analytics
Notice what it does not say: nothing about your support team, nothing about how much they love the product. It names a concrete thing the replacement does that the old one did not. That is the only argument that lands on a reader who did not want to migrate.
Do not put a quote here if the replacement is genuinely less capable. If you are consolidating and some customers lose a feature, say so in your own voice, in plain text, and link to the workaround. A testimonial in that position reads as a company using someone else's words to avoid its own admission — and the customers who lose the feature will be the loudest readers of the page.
Slot 4: inside the FAQ, attached to the questions people actually ask
Sunset pages accumulate an FAQ. The questions are predictable: Can I get an extension? What happens to my data on the shutdown date? Will pricing change? Is there migration support?
Most of those answers should be yours alone — an extension policy is a policy, not an experience. But two of them benefit from a customer voice:
"Was migration support actually useful, or is it a form?" A one-line quote naming what the support engagement involved ("a shared Slack channel for two weeks, and they wrote the mapping for our custom fields") answers this better than any description you can write.
"Did anything break after the cutover?" This is the question everyone has and nobody asks in writing. A quote that acknowledges a small problem and how long it lasted is worth more than five that report a flawless transition.
Keep these to one sentence each, inline, not in decorative quote cards. They are answers, not a showcase.
Slot 5: the extension or grandfathering section — usually no quote
If you offer extended support, a legacy tier, or a grandfathered price, resist putting a testimonial there. The customers who take that option are the ones least happy about the change. A quote in that slot almost always sounds like it is talking someone out of an entitlement they are still deciding whether to use.
State the terms. Link the form. Move on.
The placements that make things worse
- A logo wall. On a deprecation page it says "other companies are fine with this," which is an argument against the reader rather than for them.
- Quotes praising your support team in general. The reader is not evaluating your support. They are estimating a project.
- Anything with the word "excited." Nobody is excited about a forced migration, and a quote claiming otherwise reads as manufactured.
- Testimonials about the replacement from customers who never used the deprecated product. They have no standing on this page. They did not do the work you are asking the reader to do.
- A carousel or an auto-rotating band. A reader is trying to extract dates and steps. Anything that moves is an obstacle.
- Quotes older than the current migration tooling. If you shipped a better migration script last quarter, a quote from before it describes a harder job than the reader faces — and undersells your own work.
A layout that holds up
- The notice — what, when, what replaces it, link to the guide. Nothing else.
- Migration path — steps, tooling, prerequisites.
- One or two migration-experience quotes, labeled by scale.
- Replacement capability section — with one capability quote, only if the replacement is genuinely equal or better.
- FAQ — with at most two one-line quotes on support and on post-cutover issues.
- Extension / grandfathering terms — no quotes.
- Contact and escalation path.
Four quotes maximum. Three is better. Every one of them from a completed migration.
How to collect these
You cannot ask for them at the end of a satisfaction survey, because the people you need are not in a survey mood — they just finished unplanned work.
The window that works is the week after cutover, and the request has to acknowledge what happened: you moved because we made you, it would help the people still in the queue to know what it actually took. Ask for specifics — how many objects, how long, what the tooling handled, what you had to do by hand. That framing gets you the unflattering number, and the unflattering number is the entire reason the quote is worth publishing.
The same principle applies whenever you are asking about work rather than about feelings — how to ask for a testimonial after a successful product migration covers the request itself in more detail, and where to place testimonials on a changelog or release notes page handles the friendlier sibling of this page, where the news is good and the rules are looser.