Mobile ALM Tip: Decommissioning and moving mobile apps out of production

Java application deployment

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

By Lukas Stewart

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

06 Jun 2013

Related Content

Related Resources

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.