What are your options to survive in the next decade?

clock May 29, 2008 07:51

Well, I really mean "what are the options to have your VB6 application survive in the next decade?". After nearly 30 years in the field - I started my Computer Science studies in 1979, go figure! - many of which spent consulting for companies in Europe and United States, I have seen many tecnology revolutions, including the advent of IBM PC and of Windows 1.0. Each one thaught me a little piece of experience.

Let's quickly see the alternatives. 

If the application is at the end of its life cycle, for example because it doesn't fullfil a widespread need any longer, you might decide to have it die of a natural death. There is no reason to invest in a dying creature, therefore you might stay with VB6 and just fix some major bugs when your users complain aloud. Don't add any new feature or extend it in any way, because it would be too expensive too.

In this case you leave the main application in VB6 but extend it by invoking .NET components using COM Interop, or display .NET forms using Microsoft's Forms Interop Toolkit. Version 2.0 of this add-on is a major improvement, as it even supports hosting of .NET controls inside VB6 forms. Best of all, the toolkit is fully supported by Microsoft and comes with full source code. [Thanks to Rob Windsor for remainding me of this option, see comments]

While the toolkit is free, adopting it has some obvious and hidden defects and costs, though. First and foremost, this approach isn't really a solution to the problem, is more of a technique to soften the migration path and lessen its impact on your organization. If you need to migrate because your app doesn't work well under Windows Vista, or because it's slow, or because you don't want to rely on a language that Microsoft doesn't support any longer, using COM Interop and the Forms Interop Toolkit is just a way to postpone the time when you truly need to find a reliable solution. Second, the communication between the VB6 and VB.NET portions of the application is often awkward and leads you to inefficiencies (due to COM Interop) and complex roundtrips that don't make your code easily maintanable.

The bottom line: you should use the Forms Interop Toolkit only in the bigger picture of a phased migration (as Rob suggests in this comment). That is, while a group of developers is working on the porting from VB6, another group is already extending the application using VB.NET. Before taking this approach, you should compare it with the effort required by migrating it to VB.NET in one step using a *good* migration tool (ours, that is :-) )

Why not giving it a try? it's free! While your hard disk spins for hours trying to convert your real-world business app, you can have enough time to google for less-then-gentle comments about this tool from the VB community. Let's skip to next option.

Using our conversion tool to migrate to VB.NET makes sense in many cases. First, when the original application works well and is thoroughly tested, but needs to be extended with new features and implementing these extensions with VB6 would be too difficult or expensive. Second, when the application is so large that rewriting it from scratch would require a very intensive test phase. Third, if time-to-market is essential to beat your competition and make your existing users happy. In these cases you can leverage VB Migration Partner higher speed and precision (as noted by our beta testers)

There are other VB6-to-VB.NET migration tools on the market. Choosing a conversion tool is a critical decision, so you might want to ask our competitors for a trial version and compare it with our VB Migration Partner. Please do it! Please compare its feature, precision, and speed with VB Migration Partner and then let us know. If you don't have time to waste, however, ask yourself the following questions before considering another conversion tool:

a) how many VB Migration Partner's feature does this tool support? for example, does it fully support all 60+ VB6 controls, drag-and-drop, graphic methods, arrays with any LBound, Gosubs, As New semantics, IDisposable objects, As Any parameters and callbacks in Declares, etc. 
b) are there any significant features that this tool support and that VB Migration Partner doesn't?
c) why they don't make their entire documentation available online before you buy?
d) why don't they dare to publish real-world VB6 apps and the VB.NET code that their tool generates?

As far as we know, Code Architects is the only vendor who has uploaded dozens of VB6 code samples and the corresponding, converted VB.NET project, to let potential customers see and test the VB.NET applications we produce. We don't upload artificially-conceived tiny VB6 projects that highlights the tool's strengths and hide its weakness. Instead, our code sample section gathers open-source VB6 projects taken from the Internet, and we guarantee that we edited neither the original VB6 code (which is in fact downloadable from its original URL) nor the converted VB.NET.

Now ask yourself: why no other vendor took this obvious step to show the world how powerful their tool is?

In some cases, manually re-writing the application to VB.NET is a viable solution. Well, let me be absolutely honest on this point: in (very) few cases, this is the solution we recommend to our customers. If the application is a huge amount of contorted spaghetti code, has a orrible architecture and a ugly user interface....well, in this case you don't want to spend more time and money on automatic porting, because you would also port these issues to VB.NET. 

When weighing a complete re-writing from scratch against automatic porting, you should take several factors into account, including:

a) rewriting often takes from 50% to 90% of the time and money that was necessary to write the original application. (Sorry, no official statistics on this, just our field experience...)
b) you need a team of developer who are experienced in both VB6 and VB.NET, and they also need to be familiar with issues related to the specific application, therefore you can't simply hire them from outside your company
c) how do you cope with continuous edits/improvements to the original VB6 code during the months required by the rewrite? In other words, can you count on something similar to our convert-test-fix methodology?
d) can really you afford the extra time required by a complete re-write? what will your competitor do in the meantime?

I heard that a few ISVs are taking this path. In my opinion this is an irrational decision, often motivated by the anti-VB (or even anti-Microsoft) feeling that is so fashionable today. Let me explain why you shouldn't even think of jumping from VB6 to any .NET language other than VB.NET.

Rewriting a complex VB6 application into a different language has all the drawbacks of rewriting it to VB.NET (see point 6), plus the many problems that you have when switching from VB.NET to C# or Java. How do you implement On Error Resume Next in C#? How do you render a DTPicker control in Java without carefuly mapping each and every property, method, and event? But the decisive argument is: do you have enough developers who are equally familiar with VB6 and C# or Java and the application being migrated?

Briefly stated: taking this route is a technological suicide similar to point 1), except it takes longer, costs more, and is more agonizing. You can only hope that your competitors are in love enough with C# or Java to invest their energies in this option. If you hear that they are doing it, relax and be happy: you don't have anything to worry about for a long time :-)

Come on! To get an idea of how tough this "solution" (so to speak) is, take all the issues listed at point 5) and multiply them by all the problems mentioned at point 7). Then double the result to have a more reasonable estimate of the actual cost and effort.

More seriously, just think of this: there are a few commercial tools on the market that can automatically migrate VB.NET to C#, for example Instant C# or C-Sharpener for VB. I have actually used a couple of these tools, they do a great job. However, they still require a few manual edits after the conversion, to adjust minor differences between VB.NET and C#. The main reason is that the resulting C# code doesn't look like native C# and requires some fixes to be more readable and easily maintainable.

Before your consider this approach, ask yourself two questions:

a) if you believe that automatic conversion between two .NET languages (VB.NET and C#) is difficult, how can you expect that a tool be able to automatically convert from VB6 to C# in one single step?
b) on the other hand, if you think that conversion from VB.NET to C# can be fully automated, why not going from VB6 to VB.NET using our VB Migration Partner (or another tool, if you prefer) first and then using Instant-C, C-Sharpener for VB, or another similar tool for doing the final move to C#?

If you really want a C# app as the final deliverable of your conversion efforts, keep in mind that jumping from VB6 directly to C# doesn't give you more than switching from VB6 to VB.NET first and then from VB.NET to C#. Well, it actually does give you something more.... many more headaches, for precision's sake :-)

A great .NET Logging tool

clock May 29, 2008 03:01

Dennis Gurock is the main developer of SmartInspect, a .NET, java, and Delphi logging tool. I heard about this software some time ago and was impressed by its features, especially the ability to filter messages and find subtle bugs. Had I discovered it before, I would have surely used it during the test phase of VB Migration Partner, and I would have save a lot of time and many headaches. Maybe in the next coding project...

I was pleased to see that Dennis heard about our tool too, and blogged about it. I already already left a comment to thank him, but I was especially intrigued by the question at the end of his post: are there better alternatives than migrating VB6 to VB.NET than an automatic migration tool, such as migrating to Delphi?

First, my hat off to Delphi. It has been the very first "pure" object-oriented programming language that became mainstream, when C++ was just used like a "better C". Many of the best features in .NET have their roots in Delphi, therefore I highly respect this language and those who write great apps with it. It's a pity that Borland made a few faux pas and isn't the great company it used to be 20 years ago.

That said, I don't see why VB6-ers should move to Delphi instead of VB.NET. For a more articulated answer, read my next post.

Amazing feedback from a beta tester

clock May 25, 2008 02:42

Yesterday we received this comment from one of our early beta testers. I must share it with you:

After 15 years of developing our application in VB3, VB4-16 bit and VB6, I was disappointed to discover that we could not move to VB.Net. Our application was too large to rewrite into the new syntax. In spite of edits made to follow the new rules, such as omitting the lower bound on Dim statements, the migration tool available ran for 5 hours and gave 1947 errors to fix; and that was just on our main application program. Using VB Migration Partner, we converted that same code to .Net in 9 minutes and had 3 compilation errors to fix, all having to do with a third-party OCX. After commenting out those lines, the application started up and ran just fine, displaying dialogs that invoke our VB6 COM servers to perform calculations and print reports. Amazing! We need to keep developing our code in VB6 for our current clients, but the batch processing and code-test-fix methodology will allow us to convert a changing code base without making the same changes twice, once in VB6 and again in VB.Net.

ASC has been providing this application to businesses for over 25 years and we have successfully migrated from the mini-computer platform in the past. A rewrite would be impossible with an application such as ours that has evolved over so many years. Our client base has grown steadily during that time, and now includes 100’s of small to midsized firms with networks of 5 to 30 concurrent users of our application, and 20 of the top financial institutions in the nation, two of which have over 100 concurrent users of our application. With this tool, we will be able to support our existing platform and roll out a VB.Net version with minimal disruption to our clients.

Brian Olson
Actuarial Systems Corporation, USA

We knew our tool was more accurate than other tools on the market, but Brian’s experience is simply amazing: With just a few pragmas, they had a running .NET application in less than one hour!

Brian told me they are now working on details, such as inter-program communication – their VB6 app used DDE, which isn’t currently supported by VB Migration Partner – but most of the migration has been completed… in one fifth of the time it took the “other” migration tool just to parse the VB6 project Smile

Now, that means fast!

Comment from a Microsoft MVP

clock May 23, 2008 09:26

Now that VB Migration Partner is out, we can disclose a few comments from our beta testers. Here’s the one coming from Lorenzo Barbieri (LinkedIN profile). Lorenzo is arguably the most active Italian blogger, writes on several magazines (including Italian edition of MSDN), speaks at international conferences, and is a very active MVP. Yesterday he blogged on VB Migration Partner; his post is in Italian, but  I have translated it for you here:

VB Migration Partner 1.0 has been released

Today version 1.0 of the tool Francesco Balena has been working on together with Code Architects Team has been released.

In past months I have tried a few beta releases, however – because of the recent job change [In April Lorenzo joined Microsoft as a Developer Evangelist, F.B.] – I didn’t manage to test it thoroughly enough to provide useful feedback. Nevertheless, all the tests I run it through were successful and all the projects I submitted to it were converted at the first attempt.

If you still have VB6 projects and want to convert them to VB.NET, I warmly recommend to give this tool a try.

Alive and kicking: VB Migration Partner 1.0 has been released!

clock May 22, 2008 06:38

Seven months after the launch of the web site - and about two and a half years after we wrote a first prototype - we are excited to announce that VB Migration Partner 1.0 is finally available.

True, it took a bit longer than we expected. Our beta testers reported a few elusive bugs, that we promptly fixed, but above all they give us hints and suggestions on how to improve our tool. As a result, we added many new pragmas, support for batch migrations, optimized execution for n-tier applications, include files, advanced code analysis techniques, and much more. We now support Visual Studio 2008 and the integration with Microsoft Team System. We wanted to write the best conversion tool from VB6 and VB.NET, and we did it.

In these months VB Migration Partner has proven to be a very flexible tool, able to fit the most demanding migration needs. It is being used to migrate VB6 projects of all kinds and sizes, from graphical games to mission-critical bank and insurance software, from little utilities to "monsters" business apps that count over 10 million lines. One of our customers is using it convert an interpreter for a custom programming language.

Along the way we learned more ways to improve the quality of migrated code and expanded our knowledge base with dozens of articles, which explain how to achieve the most from this tool. The great thing about VB Migration Partner is its flexibility (provided by pragmas) and its open architecture, which allows you to be in control of how VB.NET code is generated, how to convert forms containing 3rd party controls, and more.

The "convert-test-fix" methodology has been welcome by all our customers, especially those who have large "legacy" applications to take care of, that can't simply be thrown away when the VB.NET version is ready. As a matter of fact, one of our customers is planning to keep both the VB6 and VB.NET versions in sync for at least one year, until they complete the conversion and all their users have switched to the .NET version. To ensure that the two versions are "functionally equivalent" at all times, they will use batch migration and custom-made plug-ins that leverage VB Migration Partner's extensibility model. Just another evidence of how flexible our tool is.


Many developers wrote us and asked about our licensing policy. Our goal was to make VB Migration Partner a viable solution for software companies of all sizes as well as individual developers and smaller software shops. As a result, we are offering VB Migration Partner in two editions:

  • VB Migration Partner Professional supports the vast majority of the features described on our Web site and can convert VB6 projects of up to 50,000 executable lines. (Empty lines and remarks aren't included in the count, but lines at the top of .frm files are.)
  • VB Migration Partner Enterprise is the full-featured version, can migrate larger VB6 projects, performs more sophisticated code analysis and refactoring, supports batch conversions and Microsoft Team System, and is the preferred choice for N-tiered applications. Users of the Enterprise Edition can purchase additional user licenses and the full source code of the support library.

UPDATE (October 8, 2010): Starting with version 1.32 we aren't offering the Professional edition any longer. The only available version is VB Migration Partner Enterprise, and therefore in most cases we are dropping the word "Enterprise" when describing our product.

Unfortunately, at this time we can't offer a demo version that is freely downloadable, but we plan to remedy in the future. If you need to test our tool against your VB6 code, let us know.

All VB Migration Partner users benefit from a 6-month subscription period, during which they are allowed to download all the releases that have produced in the meantime.

Finally, we are launching the Early Adopter Program (EAP): for a short period you can purchase VB Migration Partner and double your subscription period (one year for the Enterprise edition). Start converting your VB6 applications right now and protect your investment at the same time!

Find more information on our web site.

Follow Francesco Balena on VB6 migration’s group on


VB Migration Partner - Subscribe to our feed RSS  blog RSS
AddThis Feed Button

Home blog
AddThis Social Bookmark Button


Sign in



<<  May 2017  >>




Microsoft Regional Director
Microsoft is a registered trademark of Microsoft Corporation in the United States and other countries and is used under license from Microsoft

My programming tools

VB Migration Partner


My books

Programming Microsoft Visual Basic 6

Programming Microsoft Visual Basic 2005: The Language

Practical Guidelines and Best Practices for Microsoft Visual Basic .NET and Visual C# Developers