How to migrate ugly and undocumented VB6 Code to .

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

Compared to some of the stuff I've worked on it sounds quite small. Nevertheless there is another approach which which will work in conjunction with that shown by PeanutPower above.

The answer is to build a framework that will allow you to cut out sections of the program at a time and convert them one by one.

e.g. Insert a database adapter 'layer' that handles all calls to the database, then one by one, remove each but of SQL and replace it with a call to the db layer. Old calls will still go direct while new calls go through the layer. Eventually all calls will go through the layer and you can change the backend DB.

You can do the same with any other section of the code by expanding the framework 'layer' to cover that functionality.

The key to shifting it from VB6 to VB.NET (for example) is to use the Interop library - here's one article: http://support.microsoft.com/kb/817248

Another, much later thought: Get MZ-Tools and use their analysis tool to find redundant code and get rid of it. I managed to eliminate something like five to ten percent of code in an old legacy product at my company.

Answer 2

Does the code absolutely have to be migrated? If it doesn't, still serves it's purpose, and is halfway maintainable, just leave it alone and move on.

Your motivation to move the code to a newer language will soon fade after countless hours, weeks, and months of code migration -- especially on the scale that you mentioned.

The idea of code migration is a fantastic idea, conceptually. In all probability, it is a terrible mess and you will hate life doing it.

Think about it, do you hate your life now while fixing a defect? Escallate that by 100x for the migration project.

Most businesses could really care less about what's under the hood as long as it works. Remember, they aren't developers, don't care about how much of a pain it is to fix it (as they aren't the ones doing it) and motivating a the business to spend tens-of-thousands of dollars to bring code up to date, simply doesn't make any business sense.

Answer 3

From your description of this project, it sounds like it might be possible for you to refactor and migrate at the same time. You're clearly going to be taking the large amount of redundant code and consolidating it; it's likely that as part of the consolidation, you can also rewrite it (the redundant code, that is) in .NET.

This won't work for UI stuff. But it will for database and business-logic stuff. For instance, I haven't seen your code, but I'll bet folding money that most combo boxes in your application that get populated by methods in their form (probably copied and pasted into Form_Load) that create ADO recordsets and loop through them. That's something that can be refactored into a .NET data-access class and integrated into existing forms with ease. It will also probably allow you to introduce the magical world of caching into this application, which will be nice because that will probably result in visible performance improvements.

And visible improvements are important. Unless your management completely buys into the necessity of doing this, this is a very high-risk endeavor. It's very bad if you find yourself telling your management that a given CR is going to take longer to implement than they expect because of issues in your refactoring. Even if you have complete support, you don't want this situation to arise, but it's a lot worse if your support is partial. Visible improvements will do a lot to mitigate this.

Also, there's a growing body of literature on the problem of refactoring legacy code. You need to be on top of it. The more you know before you dive into this, the better your experience will be. I haven't read Michael Feathers's book myself, but if I were in your shoes it's the first thing I'd do.