Factors of Estimating Legacy Application Conversion to Modern Technology

How would you come up with an estimate to convert a fairly large legacy application to modern technology? As empirical studies show us, there are different ways of estimating software application development efforts. But the real question is how we should use those techniques to estimate projects of above nature. What I know is you should be prepared with additional information and use different estimation techniques in combination or in isolation to come up with an estimation. This blog discusses the blogger’s view of this process. It is highly open for criticism.

The very first preparation of the estimation team is to analyse the possibility of automating the conversion. The answer for the analysis could be both yes or no depending on the technology used by the legacy application and other factors discussed in the next three paragraphs to come.

There are vendors specialised in legacy application conversions. They normally come to market with conversion tools prepared. These tools can give you a fairly high time to market than you convert your application manually. Nevertheless, these tools are fairly expensive. Sometimes you might have to spend more money than you spend to build your legacy application initially. These vendors have priced their products in a manner such that you will spend a little bit more when you do it manually rather than you convert the software with the tool.

So the conclusion for the use of the automated tool is to convert your legacy application on three factors,

1. if there is an automated conversion tool available

2. you have quick money to spend. I mean quite a lot of quick money

3. you need to go to market with the new application as quickly as possible.

For a third-party tool based conversions, you have to get the help of the tool vendor to estimate the conversion simply because you do not precisely know what is going to convert or not by the tool. At the same time, you might want to keep provision to make any changes to the way the new application feel to the end-user other than the difference of the technology.

If you have time but no quick money then the only solution available is to do the conversion manually. Building a new conversion tool internally for conversion could be another solution. Still, it needs to be considered after estimating your manual conversion effort, your co-competence in both technologies and your future expectations on reselling the conversion tool. Also, make sure to find the conversion tooling project as a separate project denying any complexities to creep into real conversion project. You can select a proper estimation technique for a typical R&D project because conversion tooling projects are of R&D by nature.

Now let’s see how we can estimate a manual conversion project. This is the second preparation of the estimation team. Below are a few essential factors that you should be aware of before the estimate.

1. Can the new application and the legacy application co-exist? If possible, enabling the two applications to co-exists is a good way to be in the market quickly in a manual conversion project. This will allow you to know the acceptance of the new application by the end users fairly early than waiting until the end of the project. Which, in turn, gives you excellent input for the final solution. Making applications co-exist is an additional effort and would be of less use after the project. Most of the time, this effort could be hidden at the initial estimation. You can decide on adopting co-existence of the two applications by comparing the additional energy and the values derived from the advantages of the co-existence.
2. What are the skills of your current resource pool? You might already have legacy application designers and developers. They might not be familiar with modern technology or new software programming paradigms. Therefore, you can not use them to design or develop the new application directly. Consequently, you have to use them for requirement specification and verification stages of the manual conversion project. You can utilise new teams conversant on new technologies to start the new development. In the meantime, you can train your legacy application team on the latest technologies to keep them motivated for the future. When the time comes, they can start working on the new technologies at a later stage of development or maintenance of the application.
3. Is your legacy application is a dead application? No feature changes any more!!! Depending on the answer to this question, you must select your product development life cycle; hence it will change the way you estimate. If you are converting a dead application, you could go for a conventional SDLC like a waterfall. You could have several advantages using a traditional SDLC here over an agile lifecycle. For example, most of the dead application requirements are frozen hence big fat design at the beginning is possible. The big design will eliminate application re-factoring effort and will save time and money. But if you convert an active application, you must use an agile technique for the development. Any change that comes into the legacy application has to be incorporated into the new application depending on the priority along with existing requirements. Otherwise, you would have lots of catching to do at the end of the initial project.
4. Do you want to change the way the converted application feel to the end-user other than the difference of the technology? Yes means you are exposed to new requirements. No means you are still frozen with old requirements.

So finally, how to estimate? For a considerable software conversion project, you should have a reasonably big-time allocated for the estimate. Given the answer for 4 factors above, you can decide on an estimation technique for you.