Mobile ALM Tip: Four ways to effectively move apps out of production

A poorly planned and executed decommission job can leave a sour taste in user's mouths.

Lukas Stewart, Mobile Software Architect

There comes a time when the software development team has to make the decision to take their mobile applications out of production, be it to release a new version, or to simply to take an application that is under-performing and not living up to expectations off the market. Of course, this can be a tricky task, as there may be a number of users who are still using the product and will not be happy to see that their beloved little mobile app is no longer available for download. As such, it is important to ensure that any time an application is decommissioned that the process is done properly and in a way that mitigates damage to the brand as much as possible.

Planning the decommissioning

A poorly planned and executed decommission job can leave a sour taste in user's mouths. Plus, the decommissioning could actually create security risks or other unforeseen problems. To ensure that the decommissioning process goes as smoothly as possible, here are a few general guidelines that apply across a broad range of scenarios:

1. Use all the tools available to communicate with users about the planned decommissioning (the app itself, email, social media, the corporate website, etc). Even if you have the capability to remotely wipe or uninstall an app by fiat, you want users to know what’s going on.
2. If you deployed an application to customers through an app store, don’t just make your app disappear. Use the app’s download page to explain why it was pulled (no longer supported, too buggy, etc.) and to direct them to a replacement. This can be a valuable space to continue monitoring for feedback.
3. Ensure you are removing the app fully along with any associated APIs or data that may be proprietary to your enterprise. For customer-facing apps, make sure customers still have access to their co-owned data through another avenue. This is not the same process as just wiping the smartphone of an employee who quit.
4. If the old app actually served a useful purpose, preserve continuity of service with a new app developed internally or externally. When feasible, make sure the new app preserves much of the original UI experience to keep users from getting frustrated with having to learn a new system.

Effective mobile ALM means effective decommissioning

Obviously, the reason you are decommissioning the application will be a factor in determining how you go about it. However, it pays to gives some thought to this situation rather than just letting the chips fall where they may. Good software architects know that taking a software product off the market is just as important to the corporate reputation and customer goodwill as is providing and promoting an application when it first goes into production.

What are some of the lessons you have learned after taking a mobile application out of production? Let us know your experiences.

Recommended Titles
Head First Mobile Web by Lyza Danger Gardner
Professional Android 4 Application Development by Reto Meier
What's New in Java 7? by Madhusudhan Konda
The Well-Grounded Java Developer By Martijn Verburg