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?