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
    predictable basis.
  • 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.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

Leave a Reply

Your email address will not be published. Required fields are marked *

fifteen + seventeen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.