... in fact, a very common question we hear out there when people begin
considering upgrading from VB to .NET: “should I migrate my Visual Basic 6.0
applications to VB.NET or C#?”
Well, Google on the subject and this seems to be an endless
discussion, but let’s start by saying that Microsoft is entirely compromised
with the future of both languages, and they have done great efforts to ensure
that both VB.NET and C# provide the full-power of the .NET Framework. This was
clearly stated during the last TechEd, where I went to both the “Meet the VB
Team” and “Meet the C# Team” sessions. They talked about the future of both
languages, and made clear that there are no riffs between the teams. They even
have Tuesday dinner nights and work together when looking for common solutions.
In fact there are several people working on both teams. Of course, each team
has invested in different features, but this only result in advantages to
developers, providing a better opportunity to opt for the language that better
fits each particular job.
The truth is both VB.NET and C# are first-class citizens on the Common
Language Runtime (CLR) with equal access to the same framework features. So in
the end the decision should be based on your specific needs, that is, your
available resources and customer demands if we are talking about business
applications. For example, if most of your developers have been working with VB
6.0 they will probably feel more comfortable with VB.NET. On the other hand, if
you have a Java or C++ code base coexisting with your VB applications, it might
be better to migrate your VB6 systems to C#, a language that is more
comfortable for programmers exposed to some other object oriented languages due
to its syntax, constructions and usability. However, the real work on a VB6 to
.NET migration is dealing with the Framework and moving your mental model from
COM to .NET, so the transition is not just about syntax and semantics issues.
By the way, we’ve seen a few people suggesting a double path
approach for those who chose to migrate their VB6 applications to C#. This idea
mostly comes from those who offer a solution that only converts to VB.NET, and
they even say it’s irrational to think about jumping from VB6 to any .NET
language other than VB.NET. Well, the immense set of differences between VB6
and C# or VB.NET are accurately resolved by ArtinSoft’s Visual Basic Upgrade
Companion tool, and about half of our customers can tell those unbelievers better.
You’ll find detailed info about that here.
It’s well known that financial institutions are under a lot
of pressure to replace their core legacy systems, and here at ArtinSoft we’ve seen an increased interest
from this industry towards our migration services and products, specially our Visual Basic Upgrade
Companion tool and our VB to
.NET upgrade services. In fact,
during the last year or so we’ve helped lots of these institutions move their
business critical applications to newer platforms, accounting for millions of
lines of code successfully migrated at low risk, cost and time.
Margin pressures and shrinking IT budgets have always been a
considerable factor for this sector, with financial institutions constantly
looking for a way to produce more with less. Some studies show that most of
them allocate around 80% of their budgets maintaining their current IT
infrastructure, much of which comprised by legacy applications.
Competition has also acted as another driver for legacy
modernization, with organizations actively looking for a competitive advantage
in a globalized world. Legacy applications, like other intangible assets, are
hard to emulate by competitors, so they represent key differentiators and a source
of competitive advantage. Typically, significant investments in intellectual
capital have been implanted in the legacy systems over the years (information
about services, customers, operations, processes, etc.), constituting the
back-bone of many companies.
In the past, they approached modernization in an incremental
way, but recent compliance and security developments have drastically impacted
financial institutions. In order to comply with new regulations, they are
forced to quickly upgrade their valuable legacy
software assets. Industry analysts estimate that between 20-30% of a bank's
base budget is spent on compliance demands, so they are urgently seeking for
ways to reduce this cost so that they can invest in more strategic projects.
However, many institutions manually rewrite their legacy
applications, a disruptive method that consumes a lot of resources, and normally
causes loss of business knowledge embedded in these systems. Hence the pain and
mixed results that Bank Technology News’ Editor in Chief, Holly Sraeel,
describes on her article “From
Pain to Gain With Core Banking Swap Outs”. “Most players concede that such
a move (core banking replacement) is desirable and considered more strategic
today than in years past. So why don’t more banks take up the cause? It’s still
a painful—and expensive—process, with no guarantees”, she notes. “The
replacement of such a system (…) represents the most complex, risky and
expensive IT project an institution can undertake. Still, the payoff can far
exceed the risks associated with replacement projects, particularly if one
factors in the greater efficiency, access to information and ability to add
applications.”
That’s when the concept of a proven automated legacy
migration solution emerges as the most viable and cost-effective path towards
compliance, preserving the business knowledge present in these assets, enhancing
their functionality afterwards, and avoiding the technological obsolescence
dead-end trap. Even more when this is no longer optional due to today’s tighter
regulations. As Logica’s William Morgan clearly states on the interview
I mentioned on my previous post,
“compliance regimes in Financial Services can often dictate it an unacceptable
operational risk to run critical applications on unsupported software”.
“These applications are becoming a real risk and some are
increasingly costly to maintain. Regulators are uncomfortable about
unsupported critical applications. Migrating into the .NET platform, either to VB.NET
or C# contains the issue. Clients are keen to move to new technologies in the
simplest and most cost effective way so that their teams can quickly focus on
developments in newer technologies and build teams with up to date skills”, he
ads, referring specifically to VB6 to .NET migrations.
So, as I mentioned before, ArtinSoft has a lot of experience in large
scale critical migration projects, and in the last year we’ve provided
compliance relief for the financial sector. With advanced automated migration
tools you can license, or expert consulting services and a growing partner
network through which you can outsource the whole project on a fixed time and
cost basis, we can definitely help you move your core systems to the latest
platforms.
Today Eric Nelson posted on one of his blogs a short interview
with Roberto Leiton, ArtinSoft’s CEO.
Eric works for Microsoft UK,
mostly helping local ISV’s explore and adopt the latest technologies and tools.
In fact, that’s why he first contacted us over a year ago, while doing some research
on VB to .NET migration
options for a large ISV in the UK.
Since then, we’ve been in touch with Eric, helping some of his ISV’s move off
VB6, and he’s been providing very useful Visual
Basic to .NET upgrade resources through his blogs.
So click here
for the full interview, where Eric and Roberto talk about experiences and
findings around VB6 to .NET migrations, and make sure to browse through Eric’s
blog and find “regular postings on the
latest .NET technologies, interop and migration strategies and more”,
including another interview
with William Morgan of Logica, one of our partners in the UK.
I mentioned
a few days ago that ArtinSoft was about to release a new version of its VB to
.NET migration product. Well, today it is official: finally, the Visual Basic Upgrade Companion
v2.0 has been released! After an incredible amount of work
(kudos to everyone involved), the tool now includes a series of enhancements
basically aimed towards increasing the generated code quality and the overall
automation of the upgrade process, allowing to reduce even further the manual
effort required to convert and compile your VB6 code to VB.NET or C#.
These are just some of the new features and improvements
included in this version of ArtinSoft’s Visual Basic Upgrade Companion (VBUC):
-
Upgrade Manager: The VBUC v2.0 now sports a
dashing GUI and Command Line interface that improves the user experience. Incorporating
a screen to set up migration profiles, it allows selecting and applying only
those features you require for a specific conversion.
-
Support for conversion of multi-project
applications.
-
Migration of mixed ASP and VB6 code to ASP.NET
and VB.Net or C#.
-
Individual conversion patterns designed to
improve the migration of a large amount of diverse specific language patterns.
-
Conversion of unstructured to structured code, reducing
the presence of spaghetti code and improving code maintainability and
evolution. This includes the
transformation of frequently used patterns related to error handling. For
example, the VBUC recognizes “On Error Goto” and “On Error Resume Next”
constructs patterns and replace them with the .NET “Try-Catch” structure. It
also performs “Goto” removals.
-
Improved typing system, which provides
additional information to assign more accurate target types to existing VB6 variables,
functions, fields, parameters, etc.
-
Improved Array migration, such as conversion of
non-zero-based arrays and re-dimensioning of arrays.
-
C# specific generation enhancements:
declarations and typing, events declaration and invocation, error handling,
conversion of modules to classes, indexer properties, case sensitive
corrections, brackets generation for array access, variable initialization
generation, and much more.
-
Migration of ADO to ADO.NET using .NET Common Interfaces.
-
Support for converting many new 3rd-party
components such as SSDataWidgets SSDBGrid, TrueDBList80, Janus Grid, TX Text
Control, ActiveToolBars, ActiveTabs, ActiveBar 1 and 2, etc.
-
New helper classes that offer frequently used
VB6 functionality that is either unavailable in .NET and/or that is encapsulated
for the sake of readability.
-
Automatic stub generation of no-maps as a proven
strategy to manage overall remaining effort towards successful compilation of upgraded
code.
-
And much more!
For more info, you can visit ArtinSoft’s website, and let us know about your specific
migration requirements.
Well, not exactly. But official
support for Visual Basic 6.0 has certainly ended, as I’ve mentioned on
previous posts.
VB 6 has been used by millions of people all over the world to develop
applications ranging from thousands to millions of lines of code. It’s definitely time to move those significant organizational investments to .NET, and appropriately
ArtinSoft is about to launch a new
enhanced version of its VB to .NET migration product (Visual Basic Upgrade Companion).
Stay tuned for details…
Browsing through some of the good old VB to .NET migration
resources I’ve accumulated through all these years, I rediscovered a Dr.
Dobb’s interview by Scott
Swigart with Jay Roxe. Among
other things, they talked about the motivations for migrating from Visual Basic
6.0 to the .NET platform, either to VB.NET or C#, and some of the benefits of
the new environment.
Putting aside the VB6 support end concerns, he describes the
lifecycle of any application as one of the motivations for a .NET upgrade: “The application has reached a point where
the code has grown beyond its original scope, and it's time to rewrite the
application anyways, and it just makes sense to transition to the latest development
platform at the same time”. Other incentives relate directly to the .NET
Framework’s new functionality and development capabilities, and that’s where
the benefits come under the spotlight. For instance, he mentions that “We're also seeing, particularly for some of
our Web customers, that when they took a VB6/ASP application, and moved it to a
VB.NET/ASP.NET application, it was 300 percent more scalable, and they got 200
percent more throughput from the application”.
Roxe also explains how the ClickOnce technology solves the
DLL Hell issue by providing better deployment and management, checking the
prerequisites availability before installing the application itself, with the
option of setting up version checking and without impact to any other
applications on the machine. There’s also the possibility of deploying a COM
component with an application without having to register it, allowing multiple side-by-side
installations of that component without conflicts.
Finally, he responds to the questions around choosing the
programming language (VB.NET or C#) once you decide to move to the .NET platform,
adding some advice around VB to .NET migrations and pointing some of the
available resources. You can read the whole article here,
and if you have a VB to .NET migration project in your hands or want to share
any experience you’ve had with such upgrades, I’d definitely love to hear about
it.
There has been a lot of controversy around the end of Visual Basic 6.0, a
language that was generally available since January 1999. Opposition is
comprehensible when you take into account that there is a huge VB 6.0 code base
out there. But when you look at Microsoft's Product Family
Life-Cycle Guidelines for Visual Basic 6.0, it is ultimately a very large
orphaned code base.
On previous posts, I've mentioned the End Of Life of VB6, referring
specifically to the official support phase. Microsoft's Visual Basic 6.0
support policy has been in effect since the release of Visual Studio .NET. The Mainstream
Phase, where standard support offerings were available (professional
telephone and online incident support, free critical updates and free online
self-help tools), ended on March 31, 2005. The Extended Phase began in
April 2005 and will end on March 2008. During this period, that is,
at this moment and for the next couple of months, standard support offerings
are still available, including Premier Support, paid telephone and online
incident support, and free online self-help tools. Free telephone and online
incident support is no longer being provided, and critical updates are
available for a fee.
Starting on April 2008, Visual Basic 6.0 will enter the Non-Supported
Phase, where support will no longer be offered by Microsoft. The Visual
Basic 6.0 family of products includes the Standard, Professional, and Enterprise editions of
Visual Basic 6.0. It also includes users of Visual Basic 6.0 who obtained their
licenses via Visual Studio 6.0 Professional and Enterprise editions.
Of course, you may be able to find support elsewhere; with such
a large code base, the community is a viable source for support. There is a lot
of self-help tools and content out there: articles, how-to guides,
troubleshooting information, frequently asked question lists, webcasts, and
more. But this might not be enough for companies with business critical
applications and/or subject to regulations, or ISVs whose customers will demand
the latest technologies without doubt.
End of support doesn't imply that you can't continue using the product; it
doesn't mean that the IDE will stop working, but it signifies that any existing
or new defects are unlikely to ever be fixed. You will not find any new Service
Packs, which keeps your product up-to-date with the latest collection of fixes
for the core product and components, since Microsoft stopped delivering these
after the Mainstream Support Phase. Finally, in the Non-Supported Phase, no
security fixes will be provided at all.
In the end, all this is only natural. There have always been
advances in software development capabilities, and the history of Microsoft's
Visual Basic has been no different. For example, for VB4 Microsoft introduced
32-bit address spaces. But in going from VB6 to VB .NET Microsoft did far more
than that. It re-wrote the whole product: VB.NET is, in essence, a totally new
programming language. It bears some superficial resemblance to VB6, but
underneath it is entirely predicated on the .NET Common Language Runtime (CLR)
and its data types; and at compile time, you have to use the .NET framework.
Visual Basic .NET is clearly a better language, with its improved error
handling and a much better development tool in Visual Studio. It's also
multithreaded and a true object-oriented programming language, which limits
backward compatibility.
Software assets represent a competitive advantage, and keeping up to date
with the latest technologies is crucial in today's business environment.
Precisely, Microsoft disclosed those guidelines to provide the advanced notice
required by many to make accurate information-technology and product planning
decisions within their organizations. So this is the time to stop developing
legacy applications in VB6 and assess the remaining VB portfolio for
modernization options. It might not be a trivial task, but there are VB to .NET
migration products and services that can definitely
ease the process.
On my last
post I mentioned some of the motivations of one of
ArtinSoft’s largest customers to upgrade their critical Visual Basic 6.0 and ASP applications (around 5M total LOC and 9,000 total users!) to the .NET platform. They expect more than US$40M of accumulated benefits in 5 years as a result of this investment in software migration, and considering the Total Property Benefit (TPB) and the Total cost of Ownership (TCO), recuperation time is 4 years in the most probable scenario.
In this particular case, the following migration benefits would help to reduce current costs, increase the income, steer clear of new costs, and avoid losing market position:
1-
Reducing the number of incidents and the total cost associated with the fixes: Having around 3-4 incidents per year at US$3,500–US$4,000 per fix, it was estimated that a migration would reduce this number between 60–70%.
2-
Avoiding business disruption: When avoiding the increase in the number of incidents, business disruption is prevented. Migration averts a negative impact upon the company’s value chain caused by the degradation of a business process supported by the system.
3-
Providing a competitive advantage: Migration provides an advantage over competitors, allowing the quick development of new system functionalities demanded by the customers. Some of the .NET’s characteristics that facilitate this are distributed technologies support, Web Services, Remoting and Windows Communication Foundation. It is estimated that the effect of losing competitiveness ranges between 4-5% of the revenue per year.
4-
Reducing new development efforts: With about 300 new developments per year, a migration to the .NET platform would reduce the effort between 18% – 22%. Some of the .NET characteristics that allow this are the fact that registry configuration or DLL registration is not necessary, a better deployment (sharing of multiple DLL versions, XCOPY, incremental installations, One-Click) and increased productivity (Just-In-Time (JIT) compilation, Common Language Runtime (CLR), Common Type System (CTS), .NET Framework Class Library (FCL), Garbage collection, Integrated Development Environment, Task List).
5-
Increasing new developments reuse: Some of the .NET integration characteristics that allow this are the easy interaction with .NET components and legacy systems and COM interop allowing the use of components from the original application. Reuse of new developments would range between 16 – 20%.
6-
Improving system performance: the .NET platform provides several improvements in this area, such as a multithreading and ASP.NET.
This is just an example of the reasons and some of the expected benefits for a particular migration project, and this varies from case to case. However, let’s be honest: any upgrade is generally a complex task, but in most cases the alternative is to drop behind the competition and go out of business. So this might be a good time to assess your investment in business applications.
One of
ArtinSoft’s most recent customers performed a thorough analysis around upgrading all their critical Visual Basic 6.0 and ASP applications, accounting for about 5 millions of lines of code, to C# and ASP.NET 2.0.
End of Life for Visual Basic 6.0 and the
Sarbanes-Oxley Act (SOX) played a big role on their decision. The end of extended support for VB 6.0 in March 31, 2008 means that there will not be access to new technologies that allow to take full advantage of the company’s hardware investment, and that the business will find it hard to react to market changes. Plus their own corporate IT management policies state that all business areas should only use software and operative systems supported by an approved provider and have an appropriate patch/upgrade configuration mechanism.
A migration aligns with the corporate strategies in many ways. Business wise, they highly value any investment in initiatives that contribute to improve customer royalty, increase employee productivity and reduce costs, and it was estimated that improving system performance will increase user productivity between 0.04 – 0.05%. And regarding their systems, they look forward to minimizing the learning curve and required trainings, procuring an extensible and easy-maintainable code base, and maintain knowledge through the preservation of business rules, comments and cross references.
But why chose
ArtinSoft’s VB to .NET automated conversion solutions and Microsoft’s .NET as the target platform? Well, they listed several reasons.
I’m not going to evangelize on the benefits of .NET, but I would like to mention a couple of our customer’s motivations. The .NET platform is the base of a complete strategy that integrates all Microsoft’s products, from the OS to market applications. It is a response to a growing market of web-based business processes. On the long run, it seems that Microsoft intention is to replace API Win32 or Windows API with the .NET platform. This could be because their lack of detailed documentation, uniformity and cohesion between its components, causing issues when developing Windows-based applications. .NET addresses most of these issues by providing a single, easily extensible group of interconnected blocks that eases the development of robust applications. In general, the .NET framework has a lot of advantages for increasing productivity.
On the other hand, they chose
ArtinSoft’s solution basically because it proved to have a much lower risk and overall cost than other alternatives. They’ve been developing most of their applications since 1990, and an automated migration allows preserving all the business rules that exist in a core-business application.
On my next post I’m going to provide more details about the expected benefits for this specific migration project.
I’ve seen recently an increase in the number of people with business critical applications written in Visual Basic 6.0 that are looking more actively towards making the transition to the .NET platform. I think that this may have been triggered in part by the proximity of the end of Microsoft’s extended support for VB 6, in March 2008 (mainstream support ended 2 years ago). For
Independent Software Vendors specially, this is a source for considerable market pressure. According to some analysts, most people moved to .NET because of the demand from clients or for the need to keep up with the latest trends, aside from the platform’s own capabilities and features, of course.
In the past, there’s been a consistent lack of perceived need for .NET among VB 6 developers, but .NET usage continues to increase from year to year. And with more successful migration stories every day and a broad range of related resources and incentives available (take for example Microsoft’s
NXT initiative for ISVs), many are starting to consider the .NET upgrade as an unavoidable step to avoid the legacy quicksand.