When the time comes to modernize a software application, one of the first options companies look at is to simply rewrite the application. What could be easier? It keeps the job in-house, the developers who first created the app may still be around unless the legacy application is truly ancient…

We hear it often. Sometimes from companies exploring options when they first consider a modernization project, sometimes from companies who have spent many years trying to rewrite an application and failed miserably.

Unfortunately, our success stories for companies who have used Morphis’ technology platform to automatically transform their legacy application to a modern web-based equivalent tend not to focus on the years of failure trying to rewrite the application. Why would they? Who wants to focus on failure rather than the ultimate success of the project? But, it is an unstated reality.

So why is it so hard to rewrite an application?

Leaving aside the obvious for a 20-30 year old application where the original development team has left or retired, here are four major barriers to successfully rewriting an application:

1. Specification. How do you properly/accurately specify an application that is several years old?
2. Testing. Given the lack of an accurate specification, how can you possibly write a test suite to test the re-written application?
3. Lost knowledge. If you dump the existing code and start re-writing, then all of the years of knowledge and learning will be lost. All of that customer feedback. All of those bug fixes that took years of real world use to uncover in the first place…
4. Customer Satisfaction. No company has unlimited development resources. If you start on a rewrite of the original application, by definition, resources will be stretched. One of the obvious decisions to alleviate this latest scarcity of resource is to scale back on bug fixes and enhancement requests for the original/legacy application. Now you’re in a position whereby you’re going to disappoint your customer base. However much you tell them better days are around the corner, you’re not delivering to them in the short term. Then your rewrite project slips (and it will) and you have to communicate further delay and continue delivering poor quality product to your customers. What then if you end up having to abandon the rewrite (and many do)? What was initially a dubious decision may be taking you into the world of existential risk.

For these reasons, rewriting is the modernization approach with the highest risk, highest cost and longest delivery time. Our most conservative estimates show a factor of two difference in cost/delivery time when compared with the automated approach adopted by Morphis; with a strong likelihood that the true comparison is an order of magnitude difference. And that’s without factoring in the risk of failure associated with rewriting the application, something that can prove to be existential, particulalry for software companies needing to modernize their main product.

Together with “learning to fish”, the comparison of the automated transformation approach used by Morphis with the rewriting of applications will be a constant theme of this blog throughout 2017 so please keep checking back for more information. Or leave a comment below if you would like to drive the discussion.