News for hackers. Stuff that matters.
Re:A Methodology for Retiring Products by cheez on Friday April 22, 2016 @07:30PM (#11553275)
Here's my strategy, which seems to work. Build product A to the point where it can run on its own with a skeleton support team.

Build product B such as if it is a completely new product. Incentivize people to move from A to B. Don't bitch if they don't. They'll keep paying you and won't cost you much to support.

If the domain changes such that it requires drastic changes to product A, then you didn't do step 1 properly.

It's working so far for the product I have now. The biggest complaint is "Hey, I hate the way you did X, I want the other one back." "OK, here you go: <url>".

They keep paying.

I don't understand it. The new one is awesome. Ah well.

Re:A Methodology for Retiring Products by mud_dauber on Sunday April 24, 2016 @08:33AM (#11559474)
It helps if your industry has an accepted framework for EOLs. Semiconductors, for example, has a commonly used spec with recommended data, timeframes and communication styles.

It also helps if you risk-manage your supply chain. Most of the hardware EOLs that I've seen involve a 3rd party supplier suddenly shelving a factory or piece of equipment with little notice.

Re:A Methodology for Retiring Products by perflexive on Monday April 25, 2016 @11:46AM (#11564972)
>Recommendations for moving to another service.

I think the article understates the importance of this. As a customer, I won't be nearly as upset about a product being killed if you show me some good alternatives, so that's critical.