Why convert VB6 to Java using Jump 2 Java

Getting some facts straight

Let’s start with getting some facts straight! There are no silver bullets, and a poorly designed domain in a visual basic application will not magically become a well-designed application just because it is converted to another language!

Saving money and valuable time is the main driver behind any automatic conversion of software. The money and time could be better spent on developing new business functions and innovative applications for your target market. The great thing with Jump 2 Java is that the automatic conversion also opens up for all the possibilities that a web-enabled application provides and releases the headache of Visual Basic end-of-life issues as well as the constraints of finding talented developers of an outdated technology.

The options

Typically, you have four options when it comes to handling your legacy software (of any kind): replace, rewrite, reuse or migrate/convert. The best option for your needs depends on a variety of aspects, however, the two main factors are the business value, in terms of how custom or generic the application is (in your context), and its domain-level design quality, i.e., how well the software reflects the domain it supports.

The strategy to replace means that you try to find a Commercial Off-The-Shelf (COTS) system and replace your legacy system with this COTS system. This strategy is usually good if the business value delivered is generic and the existing legacy system has a poor (domain-level) design. As an example, let’s consider a general ledger platform in a finance business. Accounting is of course central to any finance business but it is very generic functionality with few, or any, business-unique features. If the legacy general ledger is poorly designed then you should probably start looking for a COTS system that can do the job for you. However, keep in mind that even if you buy a COTS package, data migration will become an issue for you and you should never underestimate such a task. Depending on the conceptual differences in the legacy systems view of the domain, and the COTS package view of the domain, such a data migration activity could be a very large undertaking.

The strategy to rewrite encompasses the development of a completely new system from scratch. The strategy is probably suitable if the business value is custom (so that no or very few COTS system are available or viable) and the legacy system shows a poor quality when it comes to its adherence to current demands in the problem domain. The rewrite strategy is basically a normal system development project but the data migration task could, similar to above, be very time consuming. The data migration task could probably be somewhat easier due to the fact that the team could design the new software to make it easier to migrate the old data into. It is also possible to ensure the new domain shows similarities with the legacy systems domain model due to the sheer fact that they both have sprung from the same development organization. Despite this, rewrite projects are arguably the most costly, since you are basically starting off from a blank sheet of paper.

The strategy to reuse basically means that you encapsulate the services of the legacy system and develop new user interfaces and a new business domain model ‘on top’ of the legacy system. Then, functionality could gradually be moved over to the new architecture of choice. This strategy is suitable in cases where the business value is somewhat generic (and hence limiting the number of changes needed to the legacy functionality due to business development needs) and design and technical quality is sufficient for purpose. In many businesses, generic mainframe applications are following this path and are gradually moved over to new architectures, and in the meantime, encapsulated in services. One should notice though that there is a risk that the business get “stuck” in insufficient domain models, built 20-30 years ago that do not reflect the current market demands. Also, mapping between multiple domain models (if new ones are developed on top of the old ones) could lead to complex “anti-corruption layers” between new and legacy software in the architecture.

Finally, the strategy to migrate/convert (i.e., source code migration/conversion as opposed to data migration) means that the actual source code of the legacy system is converted to a new technical infrastructure. This strategy is best suited when the legacy system has a custom business value and the existing design/domain fit is good. Examples of such cases are, for example COTS vendors, with a large customer base of existing installations, but where the application’s current technology needs to be transformed. Of course, such examples also exist in non-vendor cases as well, for example in the case of core banking systems. The benefits of this strategy are that it is by far the least costly alternative, much less development is needed and no data migration is required. Moreover, from a risk mitigation point of view, such a project is much more likely to get it right, reducing the risks significantly. With this type of strategy, the project separates solving the ‘out dated’ technology issues from any new development and enrichment of the domain. Performed wisely, an existing client base could start using the new application directly on their existing business data using exactly the same, well known, “use cases”.

Jump 2 Java – when you go the for migration route

So, if time and money is important for you and the application to transform has a reasonably good business fit, then go the conversion route! This alternative is right for you if you think that it is a good trade-off to get up to 99% of the application source code converted in a fraction of a second, and instead use this time for developing new business value for your organization. And if this seems to be in line with current strategy, then Jump 2 Java is the best technology available for your needs.

Will the case get better than this?

Just to give you a rough idea of what a bargin Jump 2 Java really is, consider the following example. You have 500,000 lines of code (LoC) in an application that you either should rewrite from scratch or convert using Jump 2 Java.

For the simplicity of the example, let’s say that you have no dependencies to external code at all, so that all code could successfully be converted. Let’s also assume that the rewritten application will be equal in the amount of LoC as the original application.

An experienced coder will produce roughly 1,000 LoC per day and let’s set a typical consultancy rate for a developer to 400 Euros per day. The developer cost would in the rewrite case add up to 200,000 Euros.

On the contrary, converting this 500,000 LoC application using Jump 2 Java, would cost you 5,000 Euros.

We are not talking about half the price in reduction here; the Jump 2 Java option cost a stunning 97.5% less in developer costs than the manual rewrite option. It is done in a fraction of a second and with all your invested time and money in getting the implementation correct preserved. And, if this wasn’t enough, you make the transition from dektop to the web at the same time!

Even if though this example is hypothetical, ie., you seldom have zero dependencies to external code, we still think that you see our point.

Read more about the simple process of converting your visual basic source code (you can be one hour from having a full blow version of source in Java) and also our best practices for running a migration project.