Port or Rewrite?

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.

The following sections present some common opinions about software translation and how our Tool-Assisted Rewrite approach is changing minds and giving people a sensible means to migrate huge legacy applications.

1. Tools constrain the new design
2. We just have to rewrite it
3. The code produced by the translator will be 'junk'
4. Only a person can do it
5. The legacy code was designed for the old platform. It is worthless
6. The legacy code lacks the detail to describe the new system
7. It cannot be done
8. It is too much work to figure out how to restructure the old code to new code

 Tools constrain the new design

Teams that understand translation tools and invest in using them effectively are able to do more re-engineering than teams that don't.

Leveraging migration tools frees up resources so a team can spend more time on analysis and redesign and also facilitates experimentation with different design options and ultimately enables an efficient, systematic implementation of a new design across the target codebase.

We believe the answer to the question: "To port or rewrite?" is "Balance!". We specialize in a hybrid approach that we call the Tool-Assisted Rewrite. In a nutshell this is an iterative methodology that involves two closely related activities:

1) defining where *you* need to be in terms of the new platform architecture and
2) implementing an efficient conversion process to take you there.

By leveraging our flexible, powerful translation tools to help transform your existing VB6/ASP software assets into correct .NET code you will minimize the total cost of conversion *and* be able to enjoy lower total cost of ownership once your codebase is in .NET.

A proper tool-assisted re-write balances the economics of manual development with automated conversion. It reduces cost and risk, and produces an architecture that takes advantage of new components and best practices of the target platform, rather than one prescribed by a single tool vendor and inextricably constrained to the legacy design.

 We just have to rewrite it

Rewriting some of the application makes sense and our translator is designed to take advantage of this. We can configure the translator to integrate translated code and hand-written code automatically. In addition, the real work of a rewrite is in designing the new architecture standards and coding patterns not typing them in and our translator can be configured to automate radical transformations and then apply them correctly across an entire codebase. Our flexibility 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'

Look at the translation, find the 'junk' and tell us how you would make it better. We will then reconfigure the translator to your specifications and give you an improved translation. We can repeat this process until all "junk" is removed. If there is something we cannot do 100%, we can probably get you 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 with some of those tasks? How can we best balance the work that a person should do with the tasks that a translator should do? How can we 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 we must preserve the functionality of the application, the majority of the code will be semantically similar, even on in the new platform. The source code will do the same functions; it will just describe those functions in a different way.

 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 figure that out even if you plan to do it by hand. By putting this additional information into a form that the translator can use, we can let the translator do most of the work for us. For example, if one describes how to replace legacy COM APIs with .NET classes, the translator will make those replacements for us.

 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. The Great Migrations tools are different:

• The tools have matured over almost thirty years of research and refinement in the science of computer language translation.
   
• The tools use a semantic approach that handles complex restructuring much better than a 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 separate components.
   
• The tools enable a 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 work.

Leveraging your legacy code can eliminate the disruption, effort, and risk inherent in trying to regathering 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.