Migrating Visual Basic 6.0 Applications to .NET

Migrating Applications from Visual Basic 6

Introduction

The first thing that you need to ask is, "Do I need to move my application to .NET?" If the answer is "Yes," you have a lot of though choices to make, such as:

  1. Should I go for an application re-design?
  2. Should I just use the VB to VB.NET migration tool just so my code compiles and runs as managed code?

    If you choose the latter, you have think on the lines of whether to write an automated tool to make this happen or to do a manual migration. I call it porting; it is not exactly migration.

  3. Should I convert the VB code to .NET first and then go for a re-design?

The Problem

You have decided to migrate Visual Basic applications to .NET and need to define a strategy for migrating Visual Basic applications to Microsoft C#.NET or VB.NET.

The Strategy

The strategy changes in each case based on the following scenarios.

Scenario 1: Application Redesign

  1. Remodel the application design from your existing VB 6.0 design.
  2. Analyze the existing design and identify areas for improvement based on the features provided by the .NET framework.
  3. Re-design component functionality based on Step 2.
  4. Perform a Proof Of Concept/Prototype build.
  5. Identify resources and prepare estimates.
  6. Further down with Construction, Testing, Parallel, runs, and so forth.

Scenario 2: Apples to Apples.NET Migration

  1. Evaluate the existing application.
  2. Perform a Proof Of Concept/Prototype build.
  3. Identify resources and prepare estimates.
  4. Use the standard VB to VB.NET migration tool.
  5. Make further code changes/modifications based on your customized requirements, ones that the migration tool cannot handle.
  6. Proceed with testing, parallel runs, and so on.

This scenario works well when you just have one application to migrate. If you have more than one application to migrate, you should start thinking about automating Steps 2 and 3 or, at the least, Step 3.

Instead of having your developers do all the changes manually, it might be worthwhile to write an automated migration tool that will take care of the following:

  1. Running the VB to VB.NET migration tool on your existing applications.
  2. Customizing the converted VB.NET code based on your requirements.
  3. Compiling and building the converted code.
  4. If your preferred language is C#, use the VB.NET to C# conversion tool and then recompile and build the new code.

Basically, automate code generation, modification, and compilation.

Scenario 3: Combo.NET

I have seen some companies that want to follow this approach:

  1. Execute Scenario 2.
  2. Stabilize .NET application in production.
  3. Execute Scenario 1.

If you really want to make your existing VB applications powerful and your enterprise is moving towards service orientation, you might want to take a phased approach and then move to .NET. In this case, you will find this scenario more cost effective and the resulting applications will be more scalable and reusable.

Conclusion

There are a lot of strategies people talk about and all are pretty much based on the above-mentioned scenarios except the one that says "copy and paste your code into VS.NET IDE, iteratively compile and fix it until it works;" no, I wouldn't recommend that route.

It all depends on feasibility, so weigh your options, formulate, and finalize a strategy for your migration efforts.



About the Author

Yogi Abhyankar

Yogi Abhyankar


Yogi Abhyankar is a Microsoft Certified Solutions Developer for .NET and is working with the Microsoft.NET platform for several years. He has a Bachelor's and Master's degree in Computer Science. Contact information Email: emailyogi@gmail.com

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • This ESG study by Mark Peters evaluated a common industry-standard disk VTl deduplication system (with 15:1 reduction ratio) versus a tape library with LTO-5, drives with full nightly backups, over a five-year period.  The scenarios included replicated systems and offsite tape vaults.  In all circumstances, the TCO for VTL with deduplication ranged from about 2 to 4 times more expensive than the LTO-5 tape library TCO. The paper shares recent ESG research and lots more. 

  • Java developers know that testing code changes can be a huge pain, and waiting for an application to redeploy after a code fix can take an eternity. Wouldn't it be great if you could see your code changes immediately, fine-tune, debug, explore and deploy code without waiting for ages? In this white paper, find out how that's possible with a Java plugin that drastically changes the way you develop, test and run Java applications. Discover the advantages of this plugin, and the changes you can expect to see …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds