Running a VB6 to Java conversion project

Get it over with quickly!

So you need to convert some visual basic 6 software? We have done this many times and here we share our tricks of the trade for succeeding in such an endeavor. The trick is to convert everything to the new platform as fast as possible and then, once it executes, new development can be continued again. Hence, it is wise not to add new development functionality to a conversion project, since this makes the task much more complicated and involves a lot of additional activities, decisions, and resources, such as new requirements analysis, lengthy change request processes, etc. Hence, our general advice is to get the migration over with quickly and then continue the development on the platform in a preferably time-boxed agile fashion.

The most important activities of Visual Basic 6 to Jump conversion project, split in four phases, are shown and described below. Of course a project contains more activities then these, but these activities are the most important to focus on when performing a Jump 2 Java conversion project.

Setting the scope

Early in the project (the inception phase according to the Unified Process) the Analysis feature of the Jump 2 Java IDE (which is free of charge) is used to automatically generate a high-level picture of the project and to assist in providing an estimation of the conversion effort. The tool automatically collects core metrics critical for an accurate estimation directly from the source code of the Visual Basic application to be migrated. Examples of these metrics are lines of code, migration precision and unsupported situations such as usage of third-party software components or usage of low-level Application Programming Interfaces (“API”) not supported in Java.

It also highlights which parts of the source code that the software architect must look into that potentially could have a high impact on the conversion effort, such as usage of third party libraries or mechanisms not available in a web environment. The software architect uses the result to evaluate which issues that are potentially most risky, and based thereon, ranks and plans the solution of these issues in the next phase. The Jump 2 Java IDE enables these activities to be performed instantly and with a high degree of accuracy.

In a matter of hours, by using the Jump 2 Java IDE, a high-level picture of the complete conversion to be executed and the potential issues involved can be presented and used as a basis for a cost estimate and project planning. In comparison, a manual pre-study with the same objective could take weeks and produce a less reliable result.

Depending on the level of existing system documentation, you might also want to ‘reverse engineer’ the use cases (or user stories) in the existing application, to be used as a basis for project planning, testing cases and user manuals.

Establishing the architecture

Now, when a project budget and high-level plan is established and accepted by stakeholders, the next phase begins (sometimes called the elaboration phase). The objectives of this phase in a conversion project is to secure the establishment of the target architecture.

Doing some test-migrations of part or whole of the application to find out if any preparation of the Visual Basic application should be performed prior to the conversion to improve the end result is an optional step in this phase, but our experience tells us that it can dramatically improve the quality of the converted system compared to manually adjusting the end result post conversion. The Jump 2 Java IDE can easliy be used for this purpose by creating a ‘sample’ project of some of the crucial VB classes in the complete application and do some quick conversions on this architectural ‘skeleton’.

In parallel to this activity, the unsupported APIs, components or GUI controls needs to be designed for. The compiler creates proxies (or stubs) for these components and API calls but they need to be implemented in Java. This design and implementation of such situations is a separate workstream to the conversion part of the project and should be started with as soon as possible, since this workstream include a complete normal software development cycle.

Putting it together

During the next phase (sometimes called the ‘construction phase’) you convert the visual basic source code using the Jump 2 Java IDE. The conversion could be done in one step or step-wise in increments depending on the size and structure of the source application. The converted source code is fixed and merged with any manually written code that solves conversion issues found in the earlier phases to produce the final result. Jump 2 Java carries out the conversion with a very high degree of precision and speed compared to manual migration. Moreover, and equally important, for automatic conversion, the marginal effort to convert one additional line of code is dramatically lower than in the case for a manual conversion which is essentially linear.

Testing the automatically converted application in general involves fewer resources than testing a manually coded application. This is due to fact that the functions in the automatically migrated applications are identical to those of the original application. Conversely, in a manually converted application there is significant risk of human misunderstanding and misinterpretation of the functional requirements.

In addition to converting the source code in the Visual Basic application, the Jump 2 Java Compiler also creates and formats documentation of the code according to the standard of Javadoc for Java. This feature gives the documentation activity of the system a boost and creates standardized code documentation for the new application which enhances modifiability.

Getting it live again

Once the new converted source code is fully integrated to any newly developed parts, the user acceptance test and deployment can start. If the use cases have been reengineered (or if they exist) they form a great source to test all the scenarios of the system. Since the user interface is more or less identical with the structure of the visual basic based interface, the user acceptance test is a type of normal ‘regression test’ and is typically a much easier activity to perform then acceptance testing a new-development effort.

Also, production environment needs to be set up for the new web application and then you are ready to go live.

Time gains in doing it the Jump 2 Java way

Using automatic conversion in a conversion project changes the productivity characteristics of the whole project. The illustration below demonstrates these improvements in graphical form. The vertical axis shows the percentage of the system that is developed. The horizontal axis shows the time units (of any form, not defined here).

The inception phase for manual projects is typically longer than for a project using Jump 2 Java. Manual conversion projects tend to lead not only to conversion of existing functionality but also enhancement and additions of new features. The reason for this is that normally, manual migration is very time-consuming and important business development that cannot be frozen for a long time. Hence, the inception phase, where the requirements are elicited, collected and prioritized need to be longer, since parallel development usually needs to be considered. In addition, in a manual conversion project, the software developers need to attain a higher degree of knowledge of the application domain (business functions and concepts) in order to rewrite the application correctly. This also impacts on time frame for the inception phase.

Regardless if a project is using manual or automatic conversion, technical mechanisms and system architecture must be handled and verified early in the project, which is done during the elaboration phase. During this phase the number of function points produced is less than in the later construction phase because the platform that is needed to be able to execute the functions of the system is created.

However, when the technical mechanisms needed for the system’s functionality are in place the two types of projects, i.e., manual vs. automatic migration, start to differ dramatically. When the manual project at best could count with a slight productivity increase during the construction phase as a result of the learning curve and reuse of functionality previously written during the project, the productivity increase in the automatic conversion case is many times higher. To convert 200,000 lines of code at a completion rate of 95% does not take more time than it would to convert 150,000 lines of code.

In essence, as seen, using Jump 2 Java gives a significant competitive advantage relating to the productivity of the tool. This is especially true for the construction phase which normally is the most costly phase of a migration project. During the transition phase, the productivity is essentially the same for both types of conversion approaches.

Scaling it up

Discussed above is how to typically run one instance of a Jump 2 Java conversion project. If your task is much larger, and you have multiple applications to migrate, you probably need to add a program level on top on the conversion projects to run. The program should own and establish the high level budgets and plans for each of the ingoing projects. Equally important, it should also contain an architecture task force, responsible for doing the Jump 2 Java application analysis for all ingoing projects. The reasons for this is to create consistency cross all the projects and to only design the same solution for unsupported objects and API once. Typically a workstream for implementing these issues is formed on the program level and the implementations are supplied to the ongoing migrations. In this way the migration projects can be performed even more efficiently, avoiding any duplications of implementations.

Of course, adding a program level also adds complexity to the conversion task and hence an analysis needs to be done on how likely it is that the applications to be converted have common sets of issues.


That was our high-level tricks of the trade. There is much more to say than this about running a conversion project, but our experience tells us that it is important to get the main blocks of the project right from the very beginning. We hope that these short ideas help you out!

Read more about how to use the IDE and how to perform your first ‘hello world’ migration here.