Product management · Product Development

Best practices for discontinuing a product?

Porfirio Partida Developer at Nearsoft

June 24th, 2015

After releasing a better version of a product, a company might decide to discontinue the older version. To get the new version, people must upgrade (for free). Once the old version is discontinued, those that have not upgraded will be unable to do so for free. What are some best practices for the discontinuation of a product/version?

Valerie Lanard Senior Software Engineering Manager at Salesforce

June 24th, 2015

Having been on the receiving end of such changes numerous times, the best policy is to communicate heavily.

Start with blanket communication to all old product users that
-announces the change, citing the clear benefits of upgrading
-details the upgrade path with actionable links (to download) and migration docs if necessary
-sets a clear time limit to complete the upgrade, well in advance, 2-3 months minimum, more if migration is truly complex
-details the consequences of not upgrading before the deadline (e.g. no more support but you may use the old product forever, will have to pay for upgrade after X date).

Then, in good faith, send 1 or 2 further communications before the deadline reminding people to upgrade, e.g. at the 30 day mark, touting again the benefits of upgrade and steps to do so.

Transparency, clear action path & benefits, sufficient time to complete migration, these things are best practices. Cheers!

Eleanor Carman Incoming BLP Sales Associate at LinkedIn

June 24th, 2015

The best piece of advice I heard regarding product discontinuation was to focus all your communication efforts on your customers. They are ultimately the ones that matter the most when it comes to phasing out the old and bringing in the new. Focus on the new features that your customers will be able to use, and how they're better than the old features. Essentially, get them excited about the new product so they are less likely to be upset when the old is discontinued. 

Steve Everhard All Things Startup

June 24th, 2015

I agree with Valerie but I would add that you need to be carful with user data. If the upgrade involves a non-reversible format change to the user data that needs to be communicated clearly. There are large companies who are guilty of not explaining this issues and if a user intends to maintain an old copy of the software - perhaps on another device - or communicate with others who haven't upgraded (Adobe, Microsoft I'm looking at you) then they need to understand the data migration issue. You should also be careful of turning off access to user data after the migration cut-off date. This is particularly an issue for SaaS software models.

Migration is much easier if you use OS mechanisms for automatically informing users that updates are available, which should mean that you aren't reliant so much on social media or informational websites (including your own) to get the message out.

K.Lakshmi Davey Senior Business Executive at Zoho Corporation

June 25th, 2015

If it is an on-premise software that was installed in a low cost hardware, they could continue using/keeping the old version for data and report generation in the future. They can do a fresh installation of the new version and start using it. [Well, the customer must agree to this idea and it also depends on how important it is for the old data to be in the new version for correlation etc.]. This way data migration risks, schema changes risks can be avoided. If you release newer version every 6 months or so and want to EOL versions older than 2 years continuously then it is best to have a upgrade plan and data migration plan as stated above by Valeri.