NOTE: To use the advanced features of this site you need javascript turned on.

Home Knowledge Base Cost Aspects Manual Rewrite vs. Software Migrator

Manual Rewrite vs. Software Migrator

The straightforward way of migrating a software application is to perform a complete manual rewrite. This approach presents several advantages:
  • possibility of application redesign, having a better understanding of the business domain;

  • optimal use of the technologies available for the target language

There are however disadvantages as well:

  • significant effort, as this involves a complete development life-cycle for what is in essence a new application: financial costs, long period of time, significant allocation of human resources;

  • the inherent bugs that are produced by any software development process, even if most bugs in the original application had been detected and resolved throughout the application's usage over time;

  • stakeholders will probably make pressures to add new features while rewriting the application; this multiplies the risks of defects;

  • new features, or even existing features that are altered by the rewrite, might change the user experience and cause learning difficulties; users are normally capable of dealing with few changes at a time, but not with many/radical ones – affecting their productivity and incurring training costs.

Automated translation using a software migrator is by default limiting the scope of the change to porting existing functionality without adding new features. This can be done at a later stage, benefiting from all the advantages of the target language: refactoring support, more powerful technologies and tools.

Among the advantages of automated software translation are:

  • lower effort, as the analysis, design and implementation processes are not executed; only testing and deployment need to be performed;

  • as the existing functionality is closely reproduced, no application-specific bugs are introduced into the software;

  • the usability closely matches that of the original application; even if the user interface changes (e.g. transform a text-based interface into a GUI), there is a close correspondence between each interface element of the old and new application;

  • the back-end of the application can be re-engineered using optimization algorithms during the migration process; being automated rather than applied manually, the result is uniform and less prone to bugs.

  • by-products of the migration process include detailed information about the structure and flows of the application, information that can be used by implementing analysis tools.

Inherent disadvantages of automated software migration are:

  • not taking full advantage of the technologies available for the target language, since a generic automated process cannot capture project-specific optimization nuances as well as the human mind; refactoring can be efficiently performed a later stage though;

  • all bugs that are still undetected in the original application will be ported into the new one (these are probably few in number and unimportant since the original application had been in use for a significant period of time);

  • new bugs could be introduced into the new application, due to bugs in the software migrator itself; this risk can be minimized by thorough testing of the migrator and by test harnesses/pilot migration projects to check the translation of individual constructs.

These disadvantages can be countered by implementing software migrators that are customizable for specific translation projects. Individual particularities of each application can be better addressed this way.

Finally, feasibility considerations apply to the development of software migrators themselves. Economical constraints must be balanced with quality needs, more stringently so because a migrator is a product and not a project. It thus needs to have a superior quality and to be designed for high maintainability, extensibility and reuse.

In practice, a software migrator will not offer a 100% coverage for the source language and its libraries. Each development iteration should prioritize the most commonly used constructions, whose implementation effort does not surpass a reasonable limit. The translator won't usually cover the constructions that are rarely used and/or require extensive effort to be translated – these shall be translated manually.

If a certain software application contains specific patterns, these can be translated in a special manner by elaborating heuristic algorithms that are custom-tailored to the respective situation. The disadvantages of automated translation using an off-the-shelf software migrator are thus minimized.