Looking over a portfolio of legacy applications, it might be relatively easy to identify the ones that clearly need to be modernized, but figuring out to what can be slightly more challenging.
It's not a decision to be taken in isolation. One critical component to the answer is the total cost of modernization. Getting a line of business app off Windows XP to an equivalent desktop version on .NET/C# might seem to be all that's possible with the current budget. Even though there would be great benefits and long-term economies in moving to a Web-mobile version, is it financially feasible? And with users embracing BYOD and all it represents, a pure .NET version leaves a lot of use cases out in the cold.
What's a CIO to do? Going from "really old" to "cutting edge" looks like a major rewrite, with all the costs, time, and risk that implies. Does the CIO have to tell internal customers that a desktop version of the same old app is the best they will get?
A strategy for success
If you're facing this delimma, there is a strategy to get you current and meet customer requirements. You can simultaneously get off an antiquated platform and provide desktop, web, and mobile versions of your app. Make everyone happy. Get a gold star on your performance review.
Step 1: Use automation to convert your legacy app to .NET desktop. Congratulations! Now you're off your old platform. From here on, everything else is gravy.
Step 2: Use automation to slice the UI from your .NET app and create a new HTML5 version. Way to go! Now you've got a web version plus it's handily refactored to make it easy to put the business logic and database up in the cloud.
Step 3: Use PhoneGap (or similar framework) to build mobile versions from the HTML/JS code. What a superstar! Now your users are able to BYOD and use the app on whatever device they have.
The nice thing about this strategy is that it avoids the need to rewrite everything, it allows you to use tools to dramatically cut the cost of application modernization, and winds up with a nice cross-platform strategy.
Cut to the chase: why hybrid development?
Other issues include:
- Memory utilization: adding the JS layer on top of your app can increase the memory footprint, which might kill some background processes for other apps
- Device balkanization: Different devices support different stuff so you can count on everything being available. Users with older devices may not be able to upgrade to the lastest version of their OS. You'll need a way to gracefully handle those exceptions.
- Battery: mobile devices typically operate un-tethered, so battery consumption is potentially an issues. Be sure you understand how your app consumes power and where you can optimize for battery life.
- UX: A phone isn't a laptop, nor even a tablet. Moving an entire UI from a formerly-desktop application to a 5 inch screen is usually a bad idea. You may need to think about slicing the application into more modular pieces to handle only the most common use cases.
- Widgets: some frameworks give you a native look and feel, others don't. Is this important to your users? If so, factor that into your development strategy.
When to go native