How to deprecate software features without bothering users
There's more to software deprecation than it seems. Organizations must consider the method of deprecation, how to inform users and what alternatives they should offer.
As a software product evolves, development teams shift their attention to new features and functionality. However, deprecation also plays an important role in software lifecycles, as certain features, capabilities or integrations must be systematically marginalized or removed entirely to optimize the product.
Software products frequently exist in a complex ecosystem of interrelated users and services. This complexity means that feature deprecation and application sunsetting can have profoundly negative effects on the users who rely on those capabilities. Consequently, when organizations deprecate software features, developers face special challenges, and they must plan with care and support for the user base. Even if the scope of the deprecation is limited to just one feature or function, it matters to the users.
Why deprecation is important
Organizations typically choose to deprecate software features or functions for three reasons.
The organization could have a new and better way to perform the same task. Imagine how a developer could integrate a third-party database rather than continue development and maintenance of a custom database. The benefits of this approach include faster development cycles and more flexibility for developers and users. Feature deprecation also can provide improved reliability and performance that benefits the customer through, for example, the removal of cumbersome or poorly supported integrations. Deprecation can give the developer a competitive advantage, as it can reduce the effort and costs put into software support and maintenance.
But organizations must qualify each deprecation choice, as they are not all the same. One way to deprecate software, called end-of-service life (EoSL), basically leaves the feature or function in place; developers simply halt work on it. EoSL deprecation is often easier on users in the near term than abruptly removing the feature, as developers can use EoSL to wean them off the feature and onto its replacement.
An alternative deprecation method -- the more dramatically named end-of-life (EOL) decision -- essentially disables or removes the feature or function altogether. In most cases, deprecation starts with EoSL, which can last for several release cycles, before it reaches EoL.
Roadmaps matter here. Developers should plan and outline the deprecation process and clarify that plan to the user base. Such notice provides customers ample time to address the eventual deprecation, offer feedback to the developers and consider alternative features or functions to minimize disruptions.
Offer clear alternatives
More than anything else, software deprecation leads customers and users to wonder what can or will replace features or functions -- or even a sunsetted program. A developer that offers a meaningful and productive answer will minimize user disruptions and improve customer satisfaction and retention. A deprecation plan should include one or more alternative paths for users -- if alternatives exist. There are generally three ways this plays out.
Software deprecation is all about continuity. You must ensure that developers don't alienate the customer base and instead help them through impending product changes.
If the deprecated feature will continue to operate, support staff should know the product roadmap and understand exactly how long the feature is set to work. This insight enables customers to evaluate and implement alternatives.
If the feature will be replaced by a more capable one, present guidance and instruction that enables the user to adapt to and embrace the new capabilities. If an API is being updated, developers should offer detailed how-to guidance on updated API calls, syntax and code.
In a situation where the deprecated feature or function will be removed entirely and not replaced, developers should offer suggestions for software layers or tools that can provide a worthwhile alternative, as well as guidance and instruction to help users adopt them. For example, if a custom database is replaced by a third-party database, such as SQL, support staff should ideally help users connect the database to the software and migrate it to the third-party platform.
Software deprecation is all about continuity. You must ensure that developers don't alienate the customer base and instead help them through impending product changes to minimalize disruptions for their businesses. Providing continued service requires training for the help desk and support team, as well as helpful documentation in the form of notices, guides and knowledge base entries.
Value communication and time
Customers use your software to help run their businesses, so you must communicate changes about your product -- especially when you deprecate software features -- well in advance. Customers deserve ample time to try new features, as well as evaluate, acquire and implement replacement software.
There is no rule for notification timing. A business might choose to notify customers up to a year in advance of a high-impact feature deprecation, but it might take just six or nine months for a low-impact deprecation. The time frame can vary depending on the degree of deprecation and the importance of the feature or function. Ultimately, the amount of notice time is not quite as important as the notice itself.
Use every reasonable means to notify customers when you deprecate software features. These methods can include roadmap and deprecation notices on the developer's public media outlets, email messages or letters to customers, notifications in regular developers' newsletters, and in-app messages. In rare cases, developers might seek acknowledgement of the notification, such as via a pop-up dialog in the app that requires customers to click a button to confirm they read the notice.
