Software products do not usually die suddenly. They fade. Releases slow down, the roadmap fills with vague language, the best salespeople move to the newer product, and one day the customer receives an end-of-life notice with eighteen months to migrate. For a buyer, the worst time to discover that a product is in sunset is six months after signing a three-year contract. The signals are almost always visible earlier, to anyone who knows where to look. This guide lays out the warning signs and the questions that turn a suspicion into an answer.
Why vendors sell products they plan to retire
Vendors rarely set out to deceive buyers about a product's future. More often, the decision to retire a product is made gradually and communicated internally long before it is announced. Sales teams keep selling because they have quotas and because the product still works. Acquisitions are a common trigger: a larger vendor buys a competitor, keeps both products for a while, and eventually consolidates onto one. Platform rewrites are another: a vendor builds a next-generation product and lets the legacy one coast while it matures. In each case, the legacy product is still on the price list, still supported, and still quietly headed for the exit.
None of this makes the legacy product a bad purchase in every case. Sometimes it is cheaper, more mature, and good enough for a defined period. The problem is buying it without knowing, and planning as if it will be there for a decade.
Signals in the release history
Release history is the most objective evidence available, and most vendors publish release notes somewhere. Look for these patterns:
- Slowing cadence. A product that shipped quarterly feature releases two years ago and now ships two maintenance releases a year is being maintained, not developed.
- Maintenance-only content. Release notes that list only bug fixes, security patches, and compliance updates, with no new capabilities, for several consecutive releases.
- Compliance-driven features only. New features that exist solely because a regulation required them, with nothing that a customer asked for.
- Version numbering that stopped incrementing. A product stuck at the same major version for years while a sibling product moves quickly.
- Deprecation notices accumulating. Features being removed or marked deprecated faster than new ones appear.
Compare the release history to that of the vendor's other products. If the vendor's newer platform gets monthly releases with substantial features while the product you are evaluating gets patches, the vendor has told you where its investment is going.
Signals in roadmap and marketing language
Vendors choose words carefully when a product is winding down, and the words are informative. Roadmap presentations that speak of "continued support," "ongoing investment in stability," or "meeting our commitments to existing customers" are describing maintenance. Roadmaps that describe specific features with target quarters are describing development. A roadmap that keeps pointing to a "migration path" or "bridge" to another product is telling you the destination.
On the marketing side, watch for the product disappearing from the vendor's homepage and main navigation while remaining reachable through a direct link. Check whether the vendor's recent press releases, conference sessions, and case studies feature the product or only its successor. Look at the vendor's job postings: if every engineering role mentions the new platform's technology stack and none mention the old one, the engineering organization has moved on.
Language to notice: "mature," "stable," "trusted by thousands," and "fully supported" are compliments that, in combination and in the absence of any forward-looking feature commitments, often describe a product in its final years.
Signals in people and pricing
People signals require a little more digging but are highly reliable. Ask who the product manager is and how long they have been in the role; a product with no dedicated product manager, or a product manager who also owns three other products, is not a priority. Ask how large the dedicated engineering team is compared to two years ago. Look at the tenure of the sales representative and the sales engineer assigned to you; vendors often staff legacy products with newer or less senior teams.
Pricing tells its own story. Steep discounts on a product that was previously firm on price can indicate a push to lock in revenue before an announcement. Alternatively, sharp price increases at renewal for existing customers, combined with attractive migration offers to the successor product, indicate the vendor is herding customers off the platform. Either extreme is worth a direct question. Contract terms can also shift: shorter maximum terms, refusal to offer multi-year pricing, or new language about the vendor's right to substitute a "functionally equivalent" product are all signs.
Questions that force a straight answer
Suspicion is not proof, and a vendor deserves the chance to answer directly. Ask these questions in writing, so the answers are on the record.
- What is the published end-of-life or end-of-support policy for this product, and how much notice do customers receive?
- Is this product currently under active feature development? Please share the release notes for the last eight releases and the dated roadmap for the next four quarters.
- How many engineers are dedicated to this product today compared to two years ago?
- Has the company announced, or is it planning, any product consolidation, replacement platform, or migration program that involves this product?
- If this product is retired during our contract term, what are our rights: refund, free migration to the successor, price protection, or termination without penalty?
- May we speak with two customers who have been on this product for more than three years about the vendor's investment trajectory?
A vendor with a healthy product answers these easily. A vendor with a sunsetting product will either answer honestly, which is valuable, or hedge, which is also valuable. Silence or a refusal to put anything in writing is the clearest answer of all.
Protecting yourself if you buy anyway
There are legitimate reasons to buy a product in its later years: it may be the best fit today, the price may be right, and the migration may be years away. If you proceed, negotiate for the sunset scenario explicitly. Ask for a minimum support commitment, stated in years, with a notice period for end-of-life of at least eighteen to twenty-four months. Ask for a termination right without penalty if end-of-life is announced during the term. Ask for a commitment that migration to any successor product will be provided at no charge, with price protection for a defined period. And ask for a data export clause that specifies format and cost, so that if the successor is not right for you, leaving is straightforward.
Finally, keep the file. Save the roadmap slides, the release notes, and the written answers. If the vendor announces end-of-life eight months after promising active development, that record is what turns a frustrating conversation into a productive negotiation.
Common questions
What is the single most reliable sign that a product is being sunset?
A release history that has shifted to maintenance-only content, with no new customer-requested features across several consecutive releases, especially when the vendor's other products are receiving frequent feature releases.
Is it ever reasonable to buy a product that is likely to be retired?
Yes, when it fits your needs today, the price reflects its stage, and the contract protects you with a minimum support commitment, an end-of-life termination right, and free migration to any successor.
How much end-of-life notice should a contract require?
Eighteen to twenty-four months is a common ask. The right period depends on how complex the migration would be; systems of record such as an EHR or billing platform warrant the longer end.
Should I ask about sunset risk in writing?
Yes. Written answers create a record you can rely on in later negotiations, and a vendor's willingness or unwillingness to put commitments in writing is itself informative.