Translation Myth Busters

We must either convert or rewrite.

"Convert or Rewrite?" is a somewhat misleading question. The VB6/ASP/COM platform is very different from .NET so this type of upgrade should always be approached as a rewrite. The more important questions are "why to upgrade?" and "how to upgrade?".  There are many reasons why to upgrade, but in a nutshell you want to improve your software assets and maintain them on a strong, well-supported platform.  As for the question of how:  we think that teams should leverage tools to help them analyze and interpret their legacy codes and systematically re-implement them.  We call this approach the Tool-Assisted Rewrite Methodology (TRM).  This is an agile, results-centric methodology that involves two closely related activities:

• designing where you need to be in terms of using the new platform architecture and
• developing an efficient process to accurately re-implement your functionality in the new design

A proper tool-assisted rewrite multiplies the effectiveness of your team.  It reduces cost and risk, and produces code that accurately reproduces your functionality and takes advantage of new components and language features of the target platform.  

Using tools does not constrain your solution.  In fact, teams that invest in using software re-engineering tools effectively are able to do more re-engineering, do it faster, and do it more accurately.  The increased productivity provided by using re-engineering tools will free up resources for refinement of the new design, verification, SDLC process improvements, and functional enhancements.

We just have to rewrite it.

Many migration teams that we talk to believe that it is not possible for a translation tool to produce useful output; they believe that nothing can be salvaged from their legacy software assets; and they believe that they will just have to rewrite their applications from scratch. However, after talking with us and seeing what our technology can do, they change their minds. They appreciate that their working production code can be extremely helpful to their migration effort.

That is not to say that hand written code is not also important.  And in fact, you can configure our translator to integrate translated code and hand-written code in a repeatable, automated, and precise manner.  When it comes down to it, the most critical work of a rewrite is in selecting and refining the new architecture standards and coding patterns.  Our translator can be configured and programmed to automate radical transformations and then apply them correctly across an entire codebase. This flexibility and precision means you get the best of both worlds: the quality of a custom rewrite delivered with the efficiency and accuracy of an automated tool.

The code produced by the translator will be 'junk'.

Inspect the translation, find the "junk" and decide how you would like to make it better. You can then reconfigure the translator to meet your specifications and give you the improved translations. You may repeat this process until all "junk" is removed. If there is something you cannot do 100%, you can probably get very close so you can finish it more efficiently than trying to rewrite it all by hand.

Only a person can do it.

What exactly will the person do? What is 'it'? Can refactoring tools help the person do some of those tasks? How can you best blend the work that a person should do with the tasks that a translator should do? How can you do this more efficiently and still preserve quality?

The legacy code was designed for the old platform. It is worthless.

The legacy code meets the business requirements of your customers; and it describes what your program does in detail. Since you must preserve most if not all of the functionality of the application, the vast majority of the new code will be very similar to the old code.  The source code will do the same functions; it will just interface with a different programming platform.  

The legacy code lacks the detail to describe the new system.

What additional information is needed to describe the new system? You will have to specify that information even if you plan to do it by hand. By putting this additional information into a form that the translator can use, you can have the translator do most of the work. For example, if one describes how to replace legacy COM APIs with .NET classes, the translator will make those replacements for you.

"It" cannot be done

What is "It"? What are the specific things that the translator cannot do? Why do you think the translator cannot do them?" Bear in mind that your system is processed by a "translator" every time you do a build: it is translated from source code into machine code by a type of translator called a compiler. Our translator works very much like a compiler, the difference being it emits source code instead of machine code, and it is extremely configurable so that the format and content of the source code can be customized to your requirements. The problem of computer language translation is a difficult one, and this fact is underlined by the many translation tools that are inflexible or do a poor job. Great Migrations tools are different:

• The tools have matured over more than forty years of research and refinement based on the science of computer language translation.
• The tools use a semantic approach that allows complex restructuring much better than syntax-driven approach.
• The tools are flexible and can be tuned to meet different source and target code requirements.
• The tools are designed to work with large codebases that have many integrated components.
• The tools enable an agile methodology that refines and balances automated translation with manual work.

It is too much work to figure out how to restructure the old code to new code.

Yes it will be a lot of work, but it is a natural means of formulating a design to take advantage the new platform. In addition, using tools to help you leverage the legacy code and implement the new design will free up resources for design. If you do not use the legacy application as a reference, you will essentially be building a brand new application. This is known to be a very expensive and time-consuming process -- particularly if you intend to reproduce a huge application that has evolved over many years of accumulated development.

Leveraging your legacy code can eliminate the disruption, effort, and risk inherent in trying to regather a vast set of functional requirements that has accumulated over years of development. They key to successfully upgrading a huge legacy codebase is to leverage the code for what it is: an extremely detailed, production-tested specification. Doing that efficiently takes flexible, industrial-strength translation technology and that is what we have to offer.