Legacy transformation alternatives revisited

3. November 2008 11:41 by enassar in General  //  Tags: ,   //   Comments (0)

Today Eric Nelson covered the quasi-legendary legacy transformation options graph on his blog. Taking into account the 4 basic alternatives for legacy renovation, that is, Replace, Rewrite, Reuse or Migrate, this diagram shows the combination of 2 main factors that might lead to these options: Application Quality and Business Value. As Declan Good mentioned in his “Legacy Transformation” white paper, Application Quality refers to “the suitability of the legacy application in business and technical terms”, based on parameters like effectiveness, functionality, stability of the embedded business rules, stage in the development life cycle, etc. On the other hand, Business Value is related to the level of customization, that is, if it’s a unique, non-standard system or if there are suitable replacement packages available.




This diagram represents the basic decision criteria, but there are other issues that must be considered, specifically when evaluating VB to .NET upgrades. For example, as Eric mentions in his blog post, a lot of manual rewrite projects face so many problems that end up being abandoned. One of ArtinSoft’s recent customers, HSI, went for the automated migration approach after analyzing the implications of a rewrite from scratch. They just couldn’t afford the time, cost and disruption involved. As Ryan Grady, owner of the company in charge of this VB to .NET migration project for HSI puts it, “very quickly we realized that upgrading the application gave us the ability to have something already and then just improve each part of it as we moved forward. Without question, we would still be working on it if we’d done it ourselves, saving us up to 12 months of development time easily”. Those 12 months translated into a US$160,000 saving for HSI! (You can read the complete case study at ArtinSoft’s website.)


On the other hand, for some companies reusing (i.e. wrapping) their VB6 applications to run on the .NET platform is simply not an option, no matter where it falls in the aforementioned chart. For example, there are strict regulations in the Financial and Insurance verticals that deem keeping critical applications in an environment that’s no longer officially supported simply unacceptable. Besides, sometimes there’s another drawback to this alternative: it adds more elements to be maintained, two sets of data to be kept synchronized and requires for the programmers to switch constantly between 2 different development environments.


Therefore, an assessment of a software portfolio before deciding on a legacy transformation method must take into account several factors that are particular to each case, like available resources, budget, time to market, compliance with regulations, and of course, the specific goals you want to achieve through this application modernization project.