I agree it is very difficult to write a VB6 converter; after all a "real converter" must at minimum be a VB6/COM compiler and VB6/COM is a pretty hefty platform.

I can only speak to my personal experience, and the one we used started out very crappy indeed, but we did not start trying to finish and deploy any bigger translations until we got the crap out. We worked with the vendor to custom tune the tool to our requirements so it produced correct codes and it did most of the re-engineering as well (i.e. replacing third-party COM components with .NET) . The best part was the business logic was complete and correct.

Only the most technical\messy parts of the code, that were always highly localized, needed to be rewritten by hand. Also most of the common architecture components were replaced with hand written frameworks/components that were already in production for new .NET systems we had been building. We configured the tool to make the apps use the new in-house frameworks/components as well.

We migrated dozens of VBPs and almost a million lines of code in about 18 months. The migration was done along with all the usual maintenance and projects and we saved several million USD (at least 60%) compared to what a rewrite would have cost us -- and that was just the IT cost. I have no idea what the total cost if we would have been if tried to rewrite from scratch, but I know we would have had alot more meetings with the business to gather requirements and probably spent a whole lot more cycles in test.

The main one is why are you changing language if you arent going to be making use of its features.

You hit the nail on the head! What can be improved? That is the question! What is wrong with the current application, what *specifically* is wrong with this translation? What are the new opportunities that we *must* take advantage of in adopting .NET to get mre ROI out of this investment.

Most of the time the initial design has flaws. However I have seen a number of commercial systems (even ASP!!) that are pretty damn clean and have a sound application architecture. Software companies tend to pay attention to code qualtity. Those folks will mostly be replacing system architecture components.

Of course even hand built systems have design flaws. Refactoring rules. And that brings up another point: getting the app up and running in .NET opens the door to using the next generation refactoring, analysis, and review tools sooner. IMO, this alone makes a compelling for case conversion. Having both the old and new codes open and laid out to you in the new visual studio is much a more powerful way of wworking than having VB6 on the left and C# on the right.

Why would you keep VB6 on the left? As a backup you would never use anymore after conversion?

I think it was meant in terms of rather converting it by hand line by line - which of course you wouldnt, you'd convert class by class assuming the vb code even was remotely OO based in the first place.

What I meant was you would refer to the original VB6 during the manual rewrite -- not after.

You can only get so much detail about what the app is supposed to do from your requirements gathering sessions -- we all know this to be true. So you will be frequently going back to find and figure the details by tracing legacy code -- remember it is the only spec for the legacy system that is accurate and complete. My assertion is that it is easier to analyze and interpret the legacy code and ultimately rewrite it (aka convert by hand) if you can also load/process/analyze it in VS2KX rather than just in VB6. Even better if you can actually build/run/debug it in C# side by side with the new C# code.

If you do the conversion right you will have no need whatsoever to open VB6 again -- old code gets stale fast anyway. But on the other hand, many IT shops opt for manual rewrite approach. They end up riding the VB6/COM-.NET fence for a long time, troubleshooting interop, developing with VB6 and VS200X side-by-side and constantly negotiating when/if to migrate each piece of their legacy codebase. Another thing folks run into with manual re-writes, assuming they do not have solid testing processes, is they find out they left out some lesser-known/used requirements after deploying the .NET and they end up going back to the VB6 in crisis mode to figure out how the missing stuff is supposed to work.

We knew this fence-riding thing was not for us and that is why we invested in 1) figuring out where we wanted to be in .NET and 2) developing a process get us there with quickly and reliably. We wanted to get the migration quickly over and standardize all teams on our new .NET based architectures and processes.

Most VB6 codes I see make extensive use of objects and many larger systems involve multiple inter-related VBPs communicating through COM.

With the tool-assisted rewrite approach the real work of migration is done in terms of re-engineering design tasks -- cross-cutting concerns really. How will we re-engineer data access, error handling, logging, configuration, security? What will our standard forms/pages look like -- how will we replace third-party COM components with .NET ones? We research these design problems and implement an approach that leveages the tools but also uses new code (built, bought, or borrowed from open source) as appropriate. The translations are typically run over and over again, each time comparing new runs with old runs and verifying that the transformations are becoming more correct and more conformant to our emerging standards. Often small test codes are created to isolate common legacy coding patterns so we can more easily perfect the translation process. We begin targetted functional testing as early as possible to find systematic functional defects in the translations. What we resist doing is trying to finish very large translations by hand untill they are "good enough".

Once the tool's configruation and any replacement components are verified "good enough", we recommend converting the entire application stack -- not line by line or class by class -- but all inter-related VBPs in one step. The tool is designed for this and makes sure the changes are done in a consistent manner and it propagates reengineering changes across all interfaces. The conversion process itself is very fast -- thousands of lines per second. So you can convert a big multi-VBP application (say 300kLOC) in about 5 minutes.

vb6 wasnt an OO language, it just had some hacks which made it oo-like

Exactly, so converting to a language that should be treated as OO for it is (althoguh you can semi butcher it and ignore it mostly) it would be pointless to change to c# if you werent going to be making the most of what it offered

LizR,
I am not arguing about where we are going, just trying to share my opinion on different ways to get there.

I agree whole heartedly that it would be pointless to move bad VB6 code directly to .NET and just stop -- worse -- it would backfire . Systems that get too krufty and kludgey become a liability; it does not matter what platform they are on. Although I would also assert that krufty, kludgey and left to rot on a dying platform is even worse -- thats the death of hope and ultimately that is a system that no one will care to work on. You stay on VB6 too long and your good people are probably going to leave. So ultimately this becomes not a question of "if" but of "when" and most importantly "how???".

We as individiuals and teams should learn and use new the features of .NET framework, languages and tools; the new OO/Aspect/SOA/next-big-thing design pattern or framework; TDD, refactoring, agile, continuous integration and all that is good in SD. But moving forward does not mean we have to leave our legacy applications behind, we have an obligatoin to bring them with us. Nor does it mean we have to scrap them, start over from scratch, and rewrite every single line of code by hand. We captured a whole lot of hard work in that VB6 code, we should use it. Doing so will free up more time to master the new technologies and use them to get the job done.