If you are familiar with VB to .NET migration projects, you
certainly know by now that this is not a trivial task. And with the state of
the economy today, saving up on scarce, valuable resources is a must. That’s
when an automated software migration solution proves to be the most viable
approach, constituting the most cost-effective, non-disruptive method of application
renewal.
I recently read an excellent article in ASP.NET PRO magazine, where Alvin Bruney offered some
insight on the challenges of migrating VB6 applications, providing some
estimation on the overall effort. For starters, he accurately notes how a large
part of the cost in these projects is related to the QA process, something
we’ve definitely seen in large, complex enterprise application upgrades, as it
usually represents around 50% of the total time.
He then provides some numbers regarding the cost for VB to
.NET migration projects: $1/LOC for simple applications, $3-$7/LOC for large
enterprise systems, and $10-$15/LOC for the more complex ones. However, this
varies a lot from one project to another, depending not only on the complexity
of the application and target requirements, but also on the quality of the tools
and the skills available for the migration. For example, due to a proven
methodology, consultants with broad experience in VB to .NET migration projects
and powerful conversion tools, a turn-key solution delivered by ArtinSoft,
taking care of the complete migration up to functional equivalence in the
target language, is generally between $1-$2 per line of source code. This includes the Supplier Testing activities,
though not the User Acceptance Testing, where the customer finally certifies functional
equivalence through predefined test cases. And of course there are other
post-migration costs involved, like those related to the new application’s deployment
and enhancement, but I think it is safe to say that the cost per line of code
for the migration itself, on a turn-key basis, is rarely higher than $3.
Moreover, when
time to market is a critical factor, this automated migration solution just
can’t be beat. For example, a recent customer estimated that rewriting from
scratch his highly complex, business critical, 100,000+ LOC VB6 application
would take him up to 2.5 years, while using ArtinSoft’s comprehensive solution
allowed him to release the C# version in less than 6 months. And using only
about 1/17th of the resources required for a rewrite. Expect the
case study soon, but trust me: we’re not talking n00bies here ;-) And another
example I mentioned on my last post
described how a recent customer
cut down the project time in 1 year, representing savings of about $160,000.
On the other hand, calculating how much it will cost for someone who licenses
our Visual Basic Upgrade Companion to perform the migration in-house is more complicated,
since it depends greatly on his dexterity. But just to provide another example
of how much our solution reduces the effort, another customer with a 550,000
LOC application recently told us he managed to save 14 man/months by using ArtinSoft’s tool
internally, instead of the Upgrade Wizard that ships with Microsoft’s Visual
Studio.
In any case, as Bruney wrote on the aforementioned article “automation
is the key to containing cost”. But watch out for conversion tools that will
only cause you to waste your time and money. Some of our customers have tried
some of these options in parallel before choosing our tool, but a few were
lured instantly by the deceivingly low prices. Most of the latter have come to
us in the end, frustrated with the poor results.
By the way, the article says that “the migration tool takes
you to VB.NET only”. I assume the author is talking about the Upgrade Wizard,
since even a couple of the tools I referred to above convert to C#, but the Visual Basic Upgrade Companion is
the only one that allows migrating effectively to both VB.NET AND C#. Finally,
if you have settled for C# as the target language, I should warn you again
about the infamous double-jump approach, that is, converting from VB6 to VB.NET
and then to C# (the author mentions this option, though he doesn’t exactly
recommends it). We’ve seen a couple of customers who tried that and found it
really problematic, to say the least. In fact, they finally decided it was a
whole lot easier starting all over from VB6 and using our tool to move to C#
directly.