Considerations on re-engineering legacy applications to newer technology platforms

Software applications has lifetime. Every Software product passes through the lifecycle and at the end of the cycle there is a need to rewrite/migration. Typically this is done to
1. Reduce Maintenance Cost (Technology keeps changing every year and it’s very hard to find resources who are working on a very old technology. Even if you find one, the cost might be very high).
a. Support for the existing technology is coming to an end
b. No developers available in the existing technology
c. Noone understands the existing code. Changes to the existing code base are becoming a real problem.
2. Target a larger customer base, new geography with additional functionalities.
3. Flexible Product Offerings (Support Multiple Verticals, Customizations at Vertical/Customer level).
4. Bring freshness to the product.
5. Address the pain points of the existing application.
6. Introduce Integration capabilities (to and from).


If your existing product is a desktop product, moving to web is the last option one should consider. Yeah… you can say maintaining multiple versions are always a problem in the desktop world, but IMHO a desktop user will never accept a browser based solution (irrespective of the # of features, flexibility, blah, blah, blahs…). It’s a strict NO.

How do we start?
Step 0: Define your goals for the newer technology migration
Step 0: Decide your budget
Step 0: Do your math (ROI, IRR and NPV calculations)
You should do your math on when will you get your returns and what will be your returns after the migration. In my opinion, most of the companies fail to do this math at the initial stages and then the realization happens after making quite a bit of investment (though people pretend that this math has been done). This math has to be realistic and conservative.
Step 0: Decide the plans to migrate your existing customers and bring in new customers
Step 1: Choose a Technology Platform for the Migration/Reengineering effort.
Step 2: Decide Architecture (whether to move to a newer architecture/or live with the existing one)
Step 3: Go ahead with the Migration
1. Rewrite to a newer technology platform
a. Migrate using a Tool
b. Hand code
c. Use MDD to generate code instead of hand coding
d. Develop a framework and build application on top
2. Partial Rewrite (and eventually rewrite the whole application)
3. Live with your legacy application

Typical challenges involved in any platform reengineering efforts:
1. If your existing clients are used to doing work certain way, it’s next to impossible to change them. When designing the new application, it’s very important to keep the position of the old UI Elements and shortcuts intact.
2. Assume that the new reengineering effort is scheduled for next 1 year. In the meantime, your existing code base will go through changes (.Releases, patches) as no one will be in a position to stop the business for the new product. Now by the time the new product (technology) is ready you have some more effort is pending as there are new releases after you have taken the effort.
It’s very easy to say, we will communicate/coordinate this between the teams in such a way that the changes are always communicated and the teams will take care (blah, blah, blah), but in reality it will never happen. Either the newer additions will be never added or you will never complete you’re the newer version (Think about this in case of offshoring).
If we do not have the updated features (snapshot of last 1 year or so), then you will release a product which will have lesser features than your current product and will be considered as a subset. Very difficult to sell this in that case.
3. Performance of the newer version should at least match your existing products performance. Working with smaller customers (using ISAM databases) will provide you real challenges. Performance of a .NET application versus a native win32 application will also be a challenge.
4. People tend to become more aggressive with the newer product features (in terms of flexibility, re-usability etc…). Performance cannot be compromised for the flexibility and extensibility as your users are never bothered about what goes behind the scenes.
5. It’s not always just performance, but also with other aspects of the product (features, usability) etc. if the product is not par, people are not going to buy it for sure.
6. Technology changes very fast. If you choose something in Alpha or Beta Stage for your product development (Bleeding edge technologies), obviously you are going to bleed. If you choose a technology which is in the market, a newer version will be there in the market by the time you release a product. It’s a very tricky situation. Read this interesting post from Sendhil.

In my experience, it’s a very tricky situation and unless it’s planned carefully you will have all reasons to fail. I personally feel, going the route of adding features inside the existing product as a better option than an upfront rewrite (as you will have better control). Of course it depends on your existing technology and it has to support this model. Products are evolved over a period of time. Rewriting it in a shorter period time may not possibly work as it’s very difficult to track all the features, bugs etc. etc with your existing application.

Happy Migrations!!!


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s