How to migrate ugly and undocumented VB6 Code to .NET

Question

I know that there are already Questions about VB6 migration, but the code base of my project brings some new questions here.

I have to say the Code quality, structure and architecture is just a nightmare. There are 2 Big Projects: Nr.1 with 40 Forms, 40 Modules and a few class files, this EXE is kind of a "base system". Nr.2 with 80 Forms, 20 Modules and a few class files again, this EXE calls functions form the "base system". Then there are ~10 other Projects with GUI (1-3 Forms each) and another 90 non-GUI Projects, most of them EXE Files, some DLLs. The DLLs are written in C, C++ and VB6.

The Code has grown evolutionary since 10 years, and written mostly by 1 (bad) developer at a time.

• Functions with 500 Lines (and more) are very common.
• 90% of the GUI components are named text1, command2(1), …
• copy and paste is all over the place e. g. an EXE project (without GUI) with 5000 lines of code was copied and the only change in the copy was to send files per Mail instead of FTP (there are 2 further copies of the same project also).
• I once had a small form (15 fields), where I should solve a small problem(max. a half hour thing normally), every time I changed something, it either didn't work, or produced new errors in the form. After 2 days, I decided to rewrite the form completely and from ~20 SQL statements in the old form, only 2 survived in the new one.
• don't even ask about comments in the code …

I took over the project a few months ago and I'm the only maintainer. There is a constant, (but low) flow of Change Requests and errors and we get a maintenance budget from our customers to keep the software running and "up to date" in terms of legal requirements.

My Options

1) Rewrite from scratch - In that case I could write it in Java for portability. The problem here is that besides some (old) user help, there is no documentation, so the ugly code is the "documentation". There is one Person who has the high level know how what the software should do. Also it's hard to convince management about doing it, even if there are huge cost savings in the long term, there are political issues. I also can't do that one (vb) project at a time because the database structure is no better than the code i.e. has to done from scratch too. So I can only change the whole software at once.

2) Migrate the code to VB.NET / C# Migration of the main Projects first, I tested that already and got ~2000 upgrade comments from Project Nr.1, most of them things like Screen.MousePointer changed, functions with variant return values and so on. My Idea here is after the convert, create classes for DB abstraction, change the code to use these classes and do refactoring, migrate and change the other projects too and when all the code uses the DB classes, change the DB structure.

3) Refactor the code in VB6 whenever I have to change something there anyway (I'm already doing this partly) and at some point refactor also the rest. That way it's more easy to see the original functionality, because it's original code and when there are errors, it's obvious that they can't be results of the migration. When the code is refactored (I assume it will be 50-75% smaller then also) it's easier to migrate it to .NET. Then change DB structure (and then do another round of refactoring…).

There are some bigger changes to do in the future (make it compatible with Win7, and another big CR which affects big parts of the code), so there would be a good opportunity to do these changes, as I'll have to go through lot's of the code anyway.

My Question is who has experience / hints for migrating bad, ugly code? Which options would you suggest?

Answer 1

I had to go through the same thing (Massive VB6 app with no documentation and horrible code.). The only safe and reasonable route you can take is number 3. To improve something you must first understand it. If you take route 1 or 2 you are guaranteed to be left with a horrible mess.

Remember to always keep the idea in the back of your mind that your end goal is a full migration to .NET. As you are refactoring think about how VB6s awful OO support will look like in VB.NET or C#. If possible shift your code around to make the migration easier.

You may want to consider shifting a lot of your core functionality into a .NET DLL and exposing it to VB6 through COM. This will remove a ridiculous amount of code from your VB6 and will hopefully leave mostly business logic.

The most important thing you need to remember is don't be a cowboy.

1. Write tests for a module.
2. Refactor a module.
3. Test the module.
4. Release your app.
5. GOTO 1