Migrating VB6 to VB.NET

[Frinavale]

I have been researching the best approach to migrating a VB6 application into a VB.NET application. There is a lot of information out there but most of it recommends that you "train in the migration process before jumping into it". One site even recommends that this training process should take at least 2-3 weeks. I'm not sure how you can train for such a process...but maybe I'll find something while I'm researching.

I was wondering if anyone here has taken part in such a project?
Do you have an pointers on the process?

At first I was thinking that we should just redesign/rewrite each component in our existing application but the more I read about the migration tool the more I think it might be the better approach (so long as we adequately prep our VB6 code for the migration).

I have also been told that the migration tool is not a good idea from a trusted source. I am apprehensive about migration tools out there. Some of them "delete redundant code" and auto-magically modify things so that they are coded to the "best practice" standards...but these standards might not necessarily be the standards that we want to use.

Like I said, at this point I'm doing a lot of research and so I have a very opened mind.
I would love to hear from someone who's actually tackled such a project.

-Frinny

[mjuras]

VB6 Migration Process "Training& quot;

I have been focused on VB6/ASP/COM to ,NET migration pretty much exclusively since 2005 -- in fact I design, develop, and sell migration tools and deliver migration projects for a living. Our migration tools can delete redundant code and restructure code, but they do NOT work automagically -- they are software and they are developed by programmers. In our case the lead developer is a mathematician and linguist who has been writing compilers and translators since 1974). Our VB6/ASP/COM translator is actually a compiler hooked up to a state of the art decompiler with a high performance information management system in the middle. The information management system is screaming fast and implements many algorithms that analyze and transform the compiled VB6/ASP/COM to a form that is faithful to the original semantics of the source and also compatible with being re-authored as .NET. The decompiler (aka the Author) is programmable so the user can generate code that fits your standards.

The most important training that I see for a migration team is training themselves so they know what they are getting into, so they can make intelligent choices about how they want to code their app in .NET, and so they know how maintain and enhance their system after the migration. Tools cannot learn for you, this is something you have to do for yourself.

The standards point you brought up is also critical -- most organizations cannot even agree on standards internally so it is folly to expect the "standard" code produced by a tool right out of the box to be right for everyone. Different applications serve different needs and this drives different standards. These different standards need to be specified in a form the translator can use -- that is like "training the process" you mentioned above -- we actually call it tuning the translation process. Of course a translation tool has to be flexible and allow sophisticated user-defined migration rules to be "tunable".

When people tell me they just have to rewrite a huge legacy application, I like to present this analogy: lets say you had to do a massive data conversion: millions of records of data (some of it a little 'dirty' or maybe very 'dirty') in hundreds of tables being restructured and layed out into hundreds of different tables according to a new schema. What would you think if some consultant told you "just freeze the data for a few months and pay us to re-enter it." You would say no thanks. You would say use tools! But you would NOT just take the output of the first version of the conversion process and blow it into production right? You would test, tune, and refine, and test again until you were certain the process produced data that was complete and correct according to the new schema and business rules.

IMO, The sensible way to migrate very large VB6./COM apps to .NET is similar to the large data conversion. You need to test, tune and refine the conversion process before you "cut over" to the new code. With our tools, this "tuning" is done primarily by creating migration scripts and other refactoring rules rather than modifying the VB6/ASP code. We generate inspect, play with, rework, and learn from intermediate versions of the translations then put what we learn back into the tool configuration and retranslate it all again, and again, until we get .NET code that we like -- code we are confident we can finish to production and take forward after the migration. Clearly original redesign/rewriting work is part of this process even though you are using tools to help you reimplement your application.

There is more info relevant to this topic at http://www.greatmigrations.com

[Frinavale]

Thank you very much for your reply Mjuras.

Our translator... transform(s) the compiled VB6/ASP/COM to a form that is faithful to the original semantics of the source and also compatible with being re-authored as .NET.

This sounds very interesting but our VB6 cod is not a clean design. Many layers of the application are merged into forms which should be in Objects. We have Objects but over time their functionality has spread into forms. The overall cleanliness of the system has slowly been undone as parts were quickly added or work-arounds for strange bugs were implemented. We will want to keep the main Objects but at the same time expand upon them to properly encapsulate the code for each component. From what I understand, VB6's design practices are a lot different than .NET and even though I don't have a lot of experience with VB6, it's painfully obvious that the VB6 design (of our project) needs revisiting.

The most important training that I see for a migration team is training themselves so they know what they are getting into, so they can make intelligent choices about how they want to code their app in .NET, and so they know how maintain and enhance their system after the migration.

I'm still not sure how the team can train for this. Is it just a matter of analyzing the design of the existing VB6 system to see what changes will have to be made for the system to operate in .NET? Or is there more too it?

Clearly original redesign/rewriting work is part of this process even though you are using tools to help you reimplement your application.

I've checked out your product and will keep it in mind for when we finally get to a migration stage. At this point we are still just researching the best approach to getting this job done efficiently and correctly.

Thanks again for your reply,

-Frinny

[mjuras]

Migrating VB6 to VB.NET = Refactoring

IMO the best way to deal with improving code structure is to

1) develop a vision of what the better structure should be -- what do you want to change?

2) learn and use modern refactoring tools and methods to refactor the old code to the new design in a series of incremental steps using test-as-you-go techniques to be sure the system is changing in an orderly manner without breaking its functionality.

If you are moving from VB6 to .NET one of the fundamental aspects of your vision of a better structure will be a well-formed, correct codebase that builds and can be maintained on the .NET platform. Just a "straight port" from VB6 to .NET is actually a huge first step but it is often taken for granted and it is only a start. More interesting transformations ranging from cleanup, to API replacements, to moving things around the architecture layers, to a new object model, to something as radical as moving from desktop to web might be in order as well. Clearly code conversion tools are refactoring tools that can help you close the gap between where you are and where you want to be. The question becomes how to balance investing in making the tool do more during conversion or investing in making the team do more after conversion. The balance is based on weighing factors such as risk management, resources, and urgency.

As far as training for a migration to .NET, you have to build some systems in .NET. If you plan doing a lot of refactoring and on using tools to help you do it, you have to learn to use those tools.