Every now and again, I get a question that I’ve seen many times before. I saw this one recently and thought I’d record the answer, so I can refer to this in the future.
Question: Our company develops and markets a client/server application which is
written in VB6 as a rich Win32 Client/Server application. For a variety of
technological reasons we are looking to migrate toward the .NET environment. How can we best migrate our VB6 app to the .Net. We are planning to add a new feature. Can we plug in the new feature into existing code and maintain a seamless U/I.
When it is time to add a new module, this may not be the best time to move
to .net. I guess it depends on how independent the new module is. If you need a new module, see step 4.
- Step 1: Spend a few days getting used to your code again. Like an old
friend that you’ve lost touch with, code tends to deviate from the design
during development and maintenance. Take a fresh look. Consider this
If I was to write an altogether new interface, could I use the same objects
I currently have? Would I?
- Step 2: refactor the existing code, in the existing language. Clean up any
of the partitioning problems you saw in step 1. Some things will still
creep up in the development later, but taking a little time now to clean up
the objects can really make a difference in your ability to deliver on a
- Step 3: Create an ENTIRELY NEW USER INTERFACE. This is not for the faint of
heart. However, VB6 has a few advantages that your ordinary application
doesn’t have. For one thing, all of it’s objects comply with the COM
interface. Therefore, you can create an entirely new interface in .NET
without actually removing the old one. You can pop back and forth, validate
functionality, and even refactor the old code while writing the new
interface. Here is where the work done in Step 2 really pays off. If your
business object layer was actually designed to be independent of the U/I
layer, you will appreciate it today. If not, you will need to make it
independent. There is no way around it.
- Step 4: retire the old user interface and release the code to business users
or beta testers. It takes time to create the new interface. Someone always
adds an “innovation” or two. Start collecting feedback now. Depending on
your business, it is perfectly acceptable to actually release the code at
this stage. If there are new features to add, do it using the OLD code base
and the OLD language, called from the new interface. In other words, keep
the layers intact.
- Step 5: Create a parallel data access layer. This will be used by the .NET
business objects that you write. You will continue to use the VB6 Data
access layer while you still have VB6 components in play. You will use the
.NET data layer for .NET objects. Don’t plan on mixing these two… it
isn’t worth it. (take that from experience and pain… trying to use the
VB6 data layer from .Net, or vice versa, is a doorway to undue delay and
gnashing of teeth.)
- Step 6: Pick a relatively self-contained set of business objects. Something
achievable. Don’t go to the biggest, but don’t pick the smallest either.
Give yourself a chance to succeed and still learn. Recode those business
objects to .Net. Have your GUI call them instead of calling the VB6
objects. Have the .Net objects call the parallel data access layer. Learn
from the experience.
- Step 7: refactor everything. Literally, take an entire dev-test cycle to
just fix the stuff you need to fix. This could be a month or several
months, depending on the size and complexity of your app. Be specific.
Plan your refactoring. Do this only to improve structure. Apply lessons
learned to the new code, as well as fixes to the interface into the old
- Step 8: Release.
- Step 9: Recode another set of business objects.
- Step 10: Repeat steps 8 and 9 until all business objects are recoded in
.NET. Retire the old VB6 data layer. Release.
- Step 11: buy champagne. Give everyone a week of skiing or windsurfing.