20 questions your Code Conversion partner better have a good answer for: If they don't, you need to find another partner

23. July 2010 13:16 by Fzoufaly in General  //  Tags: , , ,   //   Comments (0)

I recently found this interesting list of questions on the Datatek Inc. website. I enjoyed answering them and I want to share ArtinSoft’s answers.

Go ahead and judge for yourself if ArtinSoft is the right partner for your VB6 migration projects.

Q1: If you are manually converting the code, how many different programmers will be converting the code and how are you ensuring consistency and accuracy?

A1: ArtinSoft does not execute manual migration projects. However, there is always a percentage of code that requires manual adjustments. All the team members in a migration project follow the same coding standards to ensure a high level of consistency in the manual changes. If a certain issue is detected multiple times in the source code, its fixing will be implemented in the automatic migration process.

Q2: If this is a manual conversion, how do you minimize the issue of bugs being introduced by each and every programmer, which will have to be found individually during testing?

A2: Most of the work is performed by an automatic migration tool. People working in a migration project share a Knowledge Base where they record every manual change they perform. This knowledge sharing process minimizes the number of bugs introduced by programmers.

Q3: If you are automatically converting the code, what percentage is automated and what percentage is manual?

A3: The percentage of automatic code migration changes depending on the source/target platform. For example, in the case of Visual Basic 6 to .NET automation reaches 95% of the actual lines of code. This level of automation ensures consistency in the quality of the generated code.

Q4: Our programmers still need to make modifications to our code in order to support ongoing business requirements. Is there a “code freeze” and how long is it?

A4: ArtinSoft understands that software applications are ever evolving creatures. We have developed a mechanism where it is easy to incorporate changes during a migration process, we call it continuous migration. This process minimizes the code freeze period to the last acceptance testing phase of a project.

Q5: When we receive the converted code back from you, are we required to make any changes in order for it to be functional?

A5: When ArtinSoft bids on a functional equivalence migration project, the code that is delivered is ready for deployment.

Q6: Is the converted code guaranteed to compile?

A6: In a functional equivalence project, the code not only compiles, it runs!

Q7: Once the code compiles, do you just hand responsibility over to us or are you responsible for problems found during testing?

A7: NO! (See answer 6!)

Q8: What are we, the customer, specifically responsible for during the conversion project?

A8: The customer is mainly responsible for the testing of the project. This responsibility starts with the creation and delivery of test cases to ArtinSoft and ends with final project acceptance. The testing workflow is the main path of communication between the teams. This process ensures that project expectations are clearly set up front and is key to the success rate of the project.

Q9: Can our coding standards be applied to the converted code?

A9: Our migration tool can be customized to include the application of your coding standards. Coding standards are identified and agreed upon during the initial phase of the project.

Q10: What kinds of customizations can we make to the converted code?

A10: ArtinSoft delivers code that is completely standard to the target platform. There are no dependencies on ArtinSoft or any strange “programming behavior”. Any programmer that is fluent in the target platform is able to understand and evolve the generated code. This ensures that your application really gets a new life under the new platform.

Q11: How maintainable is the converted code? How long have other customers stayed on code you have converted for them?

A11: The generated code is fully maintainable. Our customers continue to use and modify it long after it has been converted.

Q12: What happens if we don’t like how certain pieces of the code got converted?

A12: This can be approached at to different moments: before the migration stats or during the evolution phase of the application. Before the migration start, the conversion tool or the migration process can be customized to change its behavior according to your coding preferences. During the evolution phase, since the application is written in standard maintainable source code, it can be evolved using your normal software development process.

Q13: What happens if our code inadvertently makes use of undocumented features? Will you support that functionality?

A13: Yes! ArtinSoft guarantees functional equivalence. If it worked before, it should work after the conversion.

Q14: What happens if we have existing bugs in our code that run fine on our current platform (such as uninitialized variables). Are you responsible for making sure that everything works like it did on the old platform?

A14: Yes! ArtinSoft guarantees functional equivalence.

Q15: Can we get a fixed price contract for the conversion?

A15: Absolutely. The great majority of ArtinSoft projects are executed on a fixed price & fixed time basis. Our Ready™ assessment methodology together with our experience allows us to minimize the risk for our clients.

Q16: Are there any runtime charges for any support code and/or libraries you supply? Do we have ownership rights to this code?

A16: An important element in our philosophy is to minimize the amount of necessary support code. Code should be converted to its “native” counterpart as much as possible. In case a support class is needed, the client will have full access to the source code and absolute independence from ArtinSoft moving forward.

Q17: How are we charged if we miss giving you a file after you have already started the conversion?

A18: ArtinSoft always include a price per line of code that can be used for adding/subtracting code from a migration project during its execution. Clients will always know beforehand how much additional work is going to cost.

Q18: How long does the conversion take?

A18: Each project is different. Typically, project length is a function of the size of the source code. ArtinSoft always insists on performing an assessment before the start of the project that will clearly state the required effort to successfully complete the migration.

Q19: What type of guarantees do you provide?

A19: ArtinSoft guarantees functional equivalence between the source and converted code. We typically include a guarantee period when clients can report bugs after project acceptance and ArtinSoft is responsible to fix them.

Q20: How long have you been doing code conversions?

A20: ArtinSoft has been doing automated code conversions since 1993 (we’re about to reach legal age!). In fact, ArtinSoft was founded on the premise that source code should be freed from its platform dependencies. Since day one, we’ve been applying our Artificial Intelligence research to providing cost-effective and low risk solution to code migrations. Companies choose ArtinSoft for our proven experience and comprehensive methodology.

Aberdeen Group recognizes ArtinSoft as a key player in the VB 6 migration industry

Aberdeen Group recently published a report titled “Migrating from VB6 to .NET: The challenge of Software Agility in a Volatile Economy”.

The report contains a good summary of the status quo with respect to Visual Basic 6 renewal efforts.  It is based on a survey of 130 organizations at the end of 2008. 

The Aberdeen report contains lots of advice for organizations that are faced with the challenge of upgrading their infrastructure, I think it is worth reading it.

ArtinSoft is very proud to have been recognized as a key player in the Visual Basic migration game along with a number of its outsourcing partners.  This shows once more how our 15 years trajectory in the migration business is our best letter of presentation.

In his summary of the report, Aberdeen analyst Michael Lock also shows how best in class companies have a much greater tendency to use automatic migration tools to support their porting efforts.  During these times of financial uncertainty is more important than ever to minimize the cost of evolving your infrastructure and automation is certainly a good way of doing so.  ArtinSoft approach to automatic migration is aimed at minimizing the cost of reaching functional equivalence while at the same time ensuring that all delivered code is completely .NET native and ready to be evolved to the next level by our customers.  ArtinSoft offers the best balance between cost speed and future insurance.  Jose Aguilar also analyzes some of the conclusions from Aberdeen in this blog post.

If you are deciding what’s your next move with VB6, you should certainly read the Aberdeen report and you should look at our Visual Basic Upgrade Companion 3.0 and our new technical resources site www.VBtoNET.com .

I've decided to move away from VB6. Now What?

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.


How to move billions of lines of code from VB6

Danish magazine Version2 published an interesting article last week on VB6 migrations: http://www.version2.dk/artikel/9908-saadan-flyttes-milliarder-af-kodelinjer-fra-vb6#forum_post_anchor .

Microsoft is finally waving goodbye to Visual Basic Version 6. Its successor, VB.Net, is not backward compatible, but the company Artinsoft from Costa Rica can help with a translation machine.

By Tania Andersen, Wednesday 11 February 2009

This article really shows momentum in northern Europe.



More than 800k lines of ISVs code successfully migrated using the ArtinSoft Visual Basic Companion

ArtinSoft recently published a number of case studies of Visual Basic migrations for ISVs.  The projects were successful both from the technical as well as the economical perspective.  If you are an ISV and you are considering an evolution of your application and a port to the .net platform I encourage you to take a look:http://www.artinsoft.com/vertex-omiga-vb-to-net-migration-case-study.aspx




 In this blog I am trying to be as unbiased as possible in reporting my opinion with regards to VB migrations.  This time I am mentioning the case studies as evidence that a lot of the conceptual discussions that I have are actually happening in reality.  It is interesting to see how many of the comments to this blog tend to be from skeptics and from people that just love VB6 and do not want to abandon it.  My purpose is to show that there is life after VB6 and that an automatic migration is not only possible but, in many cases, a great alternative for your evolution plans.Please let me know what you think of the case studies.


Is the grass greener while doing green-field development?

Milan Negovan in his blog aspnetresources recently published an excerpt of Michael Feathers' book Working Effectively with Legacy Code.  I liked the excerpt so much and I believe that it is so pertinent to the topic of my blog that I also will reproduce it verbatim.


Often people who spend time working on legacy systems wish they could work on green-field systems. It’s fun to build systems from scratch, but frankly, green-field systems have their own set of problems. Over and over again, I’ve seen the following scenario play out:

An existing system becomes murky and hard to change over time. People in the organization get frustrated with how long it takes to make changes in it. They move their best people (and sometimes their trouble-makers!) onto a new team that is charged with the task of “creating the replacement system with a better architecture.”

In the beginning, everything is fine. They know what the problems were with the old architecture, and they spend some time coming up with a new design. In the meantime, the rest of the developers are working on the old system. The system is in service, so they receive requests for bug fixes and occasionally new features.

The business looks soberly at each new feature and decides whether it needs to be in the old system or whether the client can wait for the new system. In many cases, the client can’t wait, so the change goes in both. The green-field team has to do double-duty, trying to replace a system that is constantly changing.

As the months go by it becomes clearer that they are not going to be able to replace the old system, the system you’re maintaining. The pressure increases. They work days, nights, and week-ends. In many cases, the rest of the organization discovers that the work you are doing is critical and that you are tending the investment that everyone will have to reply on in the future.

The grass isn’t really much greener in the green-field development.


I concord 100% with Michael Feathers.  Rewriting code is something that can be achieved only at a very large rate of consumption of time and money!  My thesis is that migration, specially automatic migration, is often the best option.  You can easily change the platform and then focus on rewriting/rearchitecting only the pieces that truly deserve it.  This has been proven over and over again at ArtinSoft.