The myths about Visual Basic migration make it easy to play the “blame” game instead of trying to understand the issue. Often, in making the wrong assumptions, we “write off” some alternatives without even considering them. However, with training, support from automatic migration products and the use of a comprehensive migration methodology, the migration is not only possible using a fraction of the resources required for a rewrite, but it is also the right choice to reduce the Total Cost of Operation and prepare applications to maximize their future business value. We'll explore everything related to VB6 migration in this blog.
At some point in time companies decide they want to leave a certain platform. Let’s not focus on the reasons why they decide to move but on HOW to move instead. Companies reach the decision to move on their own timetable.
Once you have decided that you want to move away from VB6 then ArtinSoft comes into play. The purpose of my blog is to show that there is a way out that is good, fast and cost-effective. Compared to what? You might ask, let’s see.
Once you decide to move (let me be clear, you made the decision to move, then the rest of the discussion applies) you have to assess your applications and make a decision on HOW to move them one by one.
There are three axes along which we recommend our customers to make the analysis:
- How unique is the functionality to your business? For example, if you have a general ledger that does not have any particular features for your business, if you have a “me too” app that does not give you an advantage over your competitors, well, you should consider just buying a package and replace it.
- How good is the technical quality of your source code? Have you followed best practices in VB? Is your code maintainable by a third party? (Can they understand it?) If the answer is no then migrating it to a new language is not going to improve this situation. Consider a rewrite.
- How fast is the functionality changing to meet business goals? Is the business process it supports fixed? Do you anticipate that very minimal changes will happen before retirement? Then you should just leave it as is (one caveat here, in some industries because of regulatory issues you might still make sure you are on a fully supported platform even if the application does not change).
Now, if you have an application that provides you a business advantage, that is of good technical quality and that needs to adapt to new business challenges, then you have a good candidate for a migration.
For applications with the above characteristics, why is a migration better than a rewrite?
- Cost: when we look at cost there are several dimensions.
- Cost of the actual migration process: An automatic migration to functional equivalence can be done with about 20% of the cost of a rewrite. Most of that cost is testing and fine tuning of the application to the new platform.
- Training of end users: Since the application is functionally equivalent it is not necessary to retrain end-users. With a rewrite, chances are that the output is not going to be functionally equivalent unless you follow an algorithmic approach just like an automatic migration and therefore end users need a retraining. In addition to the actual retraining cost (which can be enormous – e.g. we worked with a customer whose system required a 6 weeks training time, for 3000 users. An application replacement or rewrite would have started with that hole in front of them) but the opportunity cost. New software, new mistakes, how does that impact the business continuity?
- Time: An automatic migration process can also be done in about 20% of a rewrite. This means that you can free up resources much faster to actually build new functionality that the business requires instead of attempting to replicate functionality that already works.
- Quality: An automatic migration does not fundamentally change the architecture of the original application (even if certain aspects like data access and some pieces of GUI architecture do change). The question is: do you really need to change the architecture for the whole application? Probably not. You might need to change the architecture for certain processes. The code that is generated by ArtinSoft is completely ready for evolution. No strange variable names, all comments preservation, no restructuring of the code, etc. Even if in the worst case scenario you need to rewrite a certain piece of the application it is always a fraction of the total cost.
Comments?
About Fzoufaly
Federico—ArtinSoft co-founder—holds a PhDC in Computer Science from the University of Florida, and a Master's degree in Computer Science and an honors Licentiate degree in Electronics Engineering from the Costa Rican Institute of Technology (ITCR).
Federico has been a faculty member of both the ITCR Computer Science Department and the University of Florida. He is currently the Executive Vice President in charge of operations at ArtinSoft. Previously, he was vice president of ZIPTEK Inc., a technology-based company that offers consultancy services in automation networks.
In 1993, the year he co-founded ArtinSoft, he won the National Electronics Award in the Research Category, awarded by the Costa Rican Federated College of Engineers and Architects.
Federico has had an active participation in several local electronic and computer research projects. He is a founding member of the Costa Rican Association of Electronics Engineers and has served as a member of its Board of Directors since 1992, holding its Presidency on two occasions. He is also member of the Association for Computing Machines, the IEEE, as well as an active member of the College of Technological Engineers.
Currently Federico is directing ArtinSoft's marketing efforts.