Automated code migration eases the pain for VB users

Although Microsoft is making soothing sounds to a developer community up in arms about the discontinuation of support for Visual Basic (VB) from versions 1 to 6, the writing is on the wall. VB is on its way out and companies that use it have three years to make the move.

The developers are upset - and companies running VB applications have noted - because applications written in VB cannot be directly ported to the new Visual Basic .NET.

VB6, the last incarnation, was introduced in 1998 and has been widely adopted across organisations that used the development environment to tap into databases. In SA, that meant primarily financial services organisations, but the language also saw extensive use in other environments such as IT development businesses, retail, government, education and healthcare.

One of the problems those organisations face is that VB applications typically started small and did not enjoy the discipline that came with other legacy environments such as Cobol for mainframes. The unstructured and un-architected systems typically grew over the years and have become high value applications, because they are important to the organisations that run them, but high risk because of their design and now discontinued support by Microsoft.

Nobody wants to rewrite all of the code that went into the multitude of applications now in use. It is a long, expensive and risky process, not least because they have little or no idea of the internals of the applications.

Skills in the new languages to which those applications must be migrated are also not as ubiquitous as VB skills.

Organisations need to automatically migrate the code from their old VB applications, running it through a software mill to produce the same or improved applications at the other end in a language that is still current and supported.

There are software tools that will do this and people with the expertise to manage and assist the process where necessary.

Some organisations, those with well structured code and a clear picture of what they have, can do straightforward automatic conversions. One component of the tool analyses the existing code and another ports it to a new language.

Others, a large majority, will get away with automatically porting some components of their applications, with human assistance for the migration tool for some components.

Some will need to rewrite portions of their applications, but the automatic software migration tool will still speed up the process, if only through analysing existing code.

A few organisations will need to rewrite their entire application in a new language, but the ability to automatically analyse existing code and processes will greatly speed up the delivery of those new applications and minimise interruption.

The upshot is that most companies will see a combination of these approaches since they have a number of applications in their organisations, developed at different times, by different people and applying different policies.

When companies can do a straight port of their existing applications by running them through the software mill, they get exactly what they currently have - high business value applications - and they do not have to suffer the interruption that comes with rewriting and testing entirely rewritten applications. They also gain a big picture of the architecture inherent to the program that supports ongoing development.

Analysing the existing VB code also gives businesses the opportunity to improve the code and the processes it supports. Developing a clear snapshot gives them the foundation they need to make improvements. It is at that stage that companies will clearly be able to ascertain whether or not they need to entirely rewrite their applications, if they can do partly automated ports, or if they can do a straightforward and fully automated migration.

Analysing the applications will clearly demonstrate whether or not the developers created spaghetti code. Like Christmas tree lights unpacked for the umpteenth time, it is difficult to unwind poorly structured code automatically, or even with minimal assistance, and produce a working application automatically.

Getting away from entirely rewriting code will save organisations a great deal of time, money and risk and should be judiciously employed as they migrate away from discontinued VB6 to their chosen replacement.