Every day we receive requests and queries from VB6 developers and companies who
are interested in migrating their code to .NET. Migration a complex application
to .NET is a serious matter, therefore it’s no surprise that virtually all
our prospects plan to compare our software with the similar tools from the competition.
We take migration seriously and we take competition even more seriously. As a matter
of fact, we stepped into this market niche only when we were sure we could offer
the best VB6 software that could be possibly written. And that’s why we continued
to improve our VB Migration Partner until it offered support for virtually all major
VB6 features, including outdated features such as “classic” drag-and-drop
and DDE. (You might be surprised to learn how many VB6 apps rely on these almost-forgotten
features.)
Our competitors may have a different perspective, of course. Instead of trying to
match all the VB Migration Partner’s features, they may prefer to cut prices
or introduce cheaper versions of their tools.
Which brings up an interesting point: what is the “correct” way to estimate
how expensive migration tools are? Shouldn’t be the total cost of migration
a better criterion for selecting the right conversion tool?
All the real-world migration experiences and case studies show that the largest
part of migration costs is related to the manual labor necessary before and after
the mere action of passing the VB6 code through the conversion software. In real-world
scenarios, the cost of the migration tool is a very small fraction of the total
costs, often in the range 5-10% if not lower. Therefore, when comparing migration
tools the most “correct” selection criterion should be based on the
manual labor that each tool saves you and your team.
We already published a very detailed white paper
that compares VB Migration Partner with other VB6 conversion tools. The document
clearly illustrates what VB Migration Partner’s strongest points are, yet
it doesn’t really emphasizes which supported features impact on the total
cost and duration of the migration process. Here we remedy with this short summary.
1. Preliminary revision of the original VB6 project
Prior to VB Migration Partner’s debug, no VB6 conversion tool on the market
– including the free Upgrade Wizard tool included in Visual Studio –
supported the entire set of VB6 keywords and features. For this reason, a number
of “preliminary changes” had to be applied to the original VB6 project,
to ensure that it could be converted correctly to VB.NET. In many cases these fixes
introduced minor issues in the VB6 project, which had to be fixed until the migration
could finally begin. Such preliminary step is seldom required when using VB Migration
Partner.
In fact, only VB Migration Partner supports all VB6 keywords and features. For example, if your VB6 app
uses GoSub, On Goto, or On Gosub statements, using a conversion tool other than
VB Migration Partner requires that you spend at least a few minutes for each of
these keywords. The problem can be more serious if your VB6 code relies on other,
less common features - such as Dynamic Data Exchange (DDE), ADO data sources or
data consumers - because you’d be forced to re-write large portions of your
code. Implementing a reliable communication infrastructure based on .NET remoting
or WCF may take one week or two if you aren’t a .NET guru, or it takes ten
seconds flat if you use VB Migration Partner.
Graphics is another field where VB Migration Partner excels, with its support for
Line and Circle methods, double-buffering (the AutoRedraw property), and user-defined
system coordinates (ScaleMode property). The Code Sample section on our web
site can prove that you can convert a graphic-intensive VB6 application in a matter
of seconds. Only VB Migration Partner supports these graphic features; other less
powerful tools require that you manually implement all graphic statements.
2. Functional equivalence
VB Migration Partner can handle even the most subtle differences between VB6 and
VB.NET, including true auto-instancing (As New) semantics, by-reference ParamArray
parameters, correct disposal of database connections and other COM objects, thread-safe
behavior for multithreaded components, 100%-compatible file I/O statements, and
the many methods that behave slightly differently in VB6 and VB.NET. These features
can dramatically cut the time required for testing the migrated application;
most of them aren’t supported by other migration tools.
3. Late binding, Variants, and Null values
VB Migration Partner comes with a library of .NET controls that expose the same
properties and methods as the original VB6 controls. This detail ensures that your
code works fine after the conversion to .NET, even if the control is accessed in
late-bound mode. If you use another conversion tool you might need to manually rewrite each
and every statement that uses late binding. If your VB6 code uses many Variant,
Object, and Control variables, this task alone can keep you busy for days.
VB Migration Partner can optionally translate Variants into the special VB6Variant
type, which behaves like the VB6 type. It even supports
Empty and Null values, which is a lifesaver if you are migrating a database-intensive
application that uses Null values in expressions and assignments. By comparison,
all other conversion tools simply convert Variant into the Object type, which in
practice means that you have carefully test each and every statement that might
be using a Null or Empty value. However, please notice that the VB6Variant
class isn’t supported by C# and should be used only for very small, specific portions of VB.NET,
because it severely affects performance. For these reasons, starting
with version 1.52 the VB6Variant class is deprecated and might not be supported
in future versions of VB Migration Partner.
4. Rich user interface
In theory all conversion tools support all VB6 user interface features. In practice,
however, tools from our competitors require that you manually fix each individual
form to account for minor differences between VB6 and .NET controls. An indirect
evidence of their limits is that none of our competitors offers examples
of real-world VB6 forms and the corresponding (migrated) .NET forms,
perhaps because they would be forced to mention all the manual fixes that are necessary
to have a working .NET application.
Also, none of our competitors matches VB Migration Partner’s support for advanced
UI features, such as drag-and-drop (both OLE and “classic” flavors),
popup menus, graphic statements, dynamically created controls (the Controls.Add
method), and 100%-compatible object models for complex controls such as TreeView,
ListView, Toolbar, and StatusBar.
5. Third-party ActiveX controls
VB Migration Partner correctly converts all the 60+ controls included in VB6 toolbox
and a simplified approach for handling 3rd-party controls. Such an approach
is based on wrapper classes that
inherit from a .NET control but expose the object model of the original ActiveX
control. The benefit of this approach is that the effort required to migrate a given
control is roughly proportional to the number of properties, methods, and events
that your app actually use: for example, if your app uses just 20 members of the
original control, you have to implement only 20 members of the wrapper class.
Other VB6 migration tools use a different approach, based on a mapping mechanism
that transforms references to a member of the original ActiveX control into the
closest member of a .NET control, either from Microsoft or another vendor. In general,
the number of members that can be migrated in such a way is relatively low (typically
20-30%), or even lower with complex controls such as grids and chart components;
therefore you should be prepared to manually fix the code that references those
controls. The effort required by these manual fixes is proportional to the number
of members you have used *AND* to the number of occurrences of the control. If you
have used the control many times in your forms, VB Migration Partner’s approach
can be far more convenient.
Finally, only VB Migration Partner’s approach based on wrapper classes ensure
that the migrated code works well even if the control is accessed in late-bound
mode.
6. ADODB to ADO.NET migration
As of this writing (November ’09), Code Architects is in the process of completing
and testing ADOLibrary,
a revolutionary approach to the conversion of ADODB code into ADO.NET. We expect
to release the definitive version 1.00 in early 2010.
Code Architects’ ADOLibrary hides all the differences between the ADODB and
ADO.NET object models, including subtle details such as parameterized queries and
calls to stored procedures. The first release will offer support to server-side
forwardonly-readonly cursors and client-side cursors with optimistic batch updates,
plus support for SQL Server’s keysets. Thanks to all the supported features,
the migration from ADODB is a breeze, and takes only a small fraction of the time
required by a manual conversion.
Other VB6 migration tools may offer partial support migration from ADODB by means
of code transformations. These tools don’t support all the features mentioned
above, and in the majority of cases don’t offer full functional equivalence
with the original code. In practice, in most cases you have to tweak the generated
code until you manually fix all the issues, a process that can keep you busy for
weeks and that requires in-depth knowledge of both ADODB and ADO.NET.
7. Staged migrations
When converting large N-tiered VB6 applications you usually want to start with the
data and business components, because these are the layers where .NET offers the
greatest advantages in terms of performance and scalability. Another good reason
for doing so is that you can reuse the existing (VB6) user interface layer to test
the behavior of the (converted) data and business objects. This approach is often
dubbed as staged or phased migration.
The prerequisite for a successful staged migration is that your conversion tool
is able to generate .NET DLLs that are binary-compatible with the original VB6 DLL,
so that all the clients of the original DLL can continue to work as before and you
don’t need to have two distinct versions of each VB6 app. This apparently
minor detail is essential to avoid versioning issues during the migration process.
VB Migration Partner is the only conversion software that generates .NET DLLs that
preserve
binary compatibility with legacy COM components, and therefore it is the
only product that fully supports staged migrations.
Such ability is important because it allows you to publish a “hybrid”
VB6/.NET solution even before the migration has been completed. If time-to-market
is essential for you, the choice should be obvious.
8. The convert-test-fix methodology
A real-world migration process may take weeks or months, and you might need to extend
or modify the original VB6 code before the migration is complete. All the tools
from our competitors work on a snapshot of the VB6 code; therefore once the migration
is complete you’ll have to manually modify the .NET code to be in synch with
the VB6 application. This process takes time, is error prone, and can be very expensive.
You don’t incur in this added cost if you adopt our
convert-test-fix methodology, which in turn is based on migration
pragmas (another VB Migration Partner’s unique feature). Our customers
can extend or maintain the VB6 code base while it is being migrated to .NET, without
having to worry about keeping the two versions in sync.
9. Code maintainability
Even if it doesn’t impact the immediate cost of migration, you should also
account for the long-term cost of maintaining the migrated code. The less readable
the generated code is, the more expensive it will turn to modify and extend it in
the future.
In another whitepaper
we demonstrate that VB Migration Partner can deliver more readable and maintainable
code than its competitors.
Of course, our competitors disagree with our conclusions and may claim that their
code generates better code. For this reason we prefer to provide actual code examples
of the code our VB Migration Partner produces, something that our competitor omit
from their literature.
10. Documentation, code samples, and support
A realistic estimation of total migration costs must include the time needed to
become familiar with the migration software and its idiosyncrasies, peculiarities,
and defects. In this respects, nothing beats VB Migration Partner’s online
manual and the vast knowledge base, which we update and improve almost
every day with tips, code examples, and workarounds. As of November 2009,
the documentation available on VB Migration Partner is four times larger
than the documentation available for its closest competitor.
The sheer amount of the available documentation isn’t the only way to measure how well documented a product is.
If the quality of documentation is important for you, please consider that the VB
Migration Partner’ Team includes three top-selling book authors who have written
one dozens of books (over 10,000 pages in total) for publishers such as Microsoft
Press and Wrox, and hundreds of technical articles for magazines such as Visual Studio
Magazine and MSDN Magazine.
11. Licensing
We believe so much in our software that we offer lifetime warranty on VB Migration
Partner’s support library: if you are a registered user of version 1.xx you
have the right to download future 1.xx versions of the library. (Please read our
EULA for more details.) Compare our approach with the time-limited license
that some of our competitors offer, and you’ll have a clearer idea of which
product can really save your time.
Some useful links:
VB Migration in 10 easy steps
Migration tools feature list
17 Reasons for Using a Support Library in Migration Scenarios
Feedback from VB Migration Partner’s customers