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.