VB6 Migration

Microsoft's Visual Basic was widely adopted during the 1990's, it's popularity driven by the familiar programming language and the graphical "drag'n'drop" IDE, which was far simpler than the alternatives of the day (here's looking at you, MFC!).

Everything changed in 2002 when the .Net platform shipped along with a new language, VB.Net. VB.Net is not compatible with older versions and so, with no clear upgrade path, there is still a significant amount of VB6 (or earlier) code running today.

Support for the IDE was dropped a long time ago ("standard" support finished in March 2005 and, even for those willing to pay, extended support was dropped in March 2009). This may not be too bad however - the IDE has been working for many years, so why worry about a lack of support for it?

The runtimes are different though. They currently are supported, but only up until the end of Windows 7. Now that may seem a long way off, but if you've got any sort of large solution running on VB6, you really want to be planning your migration with plenty of time to spare. Rushing it at the last minute is unlikely to turn out all that well.

But why care about support? After all, the runtimes (just like the IDE) work right now - it's not like they are just going to randomly start failing the instant that support is withdrawn. And although you've had support for the last decade or so, how many of you have actually needed to use it? Not many, I suspect.

The reason that you've rarely, if ever, had to call on support is largely down to the vast array of tests that Microsoft will run whenever releasing a new OS. Or a service pack. Or even a simple security patch. When support ends, so does that testing. The only way you can guarantee to keep your system as stable as it is today is to not change anything. No OS upgrades. No service packs. Heck, you didn't really want that latest security patch anyway, did you?

What are my options?

There are several options available to you:

• Leave well alone. Take the call that you really can live without touching the system again. Providing all the stakeholders agree, then this is an entirely reasonable approach.
• Re-write the system from the ground up. Take the opportunity to leap-frog a generation or so of software.
• Use an automatic translation tool to turn the VB6 code into VB.Net (or C#), and then continue ongoing maintenance and development on the new codebase.
• Use a blend of all three. Leave some bits alone, rewrite other bits and translate the remaining. Spend your budget where you get the biggest impact, be that risk reduction or ability to re-architect (and hence add additional future function more easily).

All of these are valid, and indeed we'd probably expect more large system to go down some form of hybrid approach. Picking the wrong route, or picking the right one and doing it badly, can unfortunately be very costly.

How can iMeta help?

We offer a range of services to assist with your migration project. These fall into three stages:

Discovery

Through a short assignment (probably 5 days or less, although as with everything it depends on the level of complexity of your system), we would look at your system at a high level and talk to the various stakeholders and users. From this, we will provide our recommendations on how to best proceed. We would also be able to provide a firm quote for the next stage of analysis, and a good ballpark estimate for the actual implementation.

Drill Down

Going into much more detail than the Discovery process, we would drill into your existing code base to understand aspects such as test coverage (be those automatic or manual), data quality and the relationships between the components.

We would also spend more time with the business to understand their view on the application and, importantly, how they'd like to see it evolve in the future to maintain the competitive advantage that it offers.

From this, we will provide a detailed architectural design showing the nature of the migrated solution, covering which areas could be left as they are, which would be translated and which would be re-writen. We would also provide a firm quote for the implementation.

In term of time it's much harder to say, since it's clearly largely dependent on the size of the codebase and the availability of developers that are familiar with it. As a ballpark (albeit a large ballpark!), we would expect something in the region of 4 to 10 weeks of effort.

Do

Once the necessary up-front analysis is complete, the final stage is the actual implementation. We can help in a number of ways here, from doing the whole project to mentoring your existing team.

Agile?

For those thinking that the above process sounds a lot like a very traditional Waterfall process with all of its associated issues, we can assure you that it's not. The work is done in an iterative manner to ensure regular feedback loops and to handle shifting priorities. However, the reality is that most businesses do need some idea of costs and timescales, and we find that going through these 3 distinct stages makes it easier to budget for.

Now What?

Simple. Contact us and we'll have a chat and take it from there.