Choosing A Migration Vendor And Technology
Migrating a large application from legacy languages and legacy technologies to a new platform is a serious and difficult business, with significant costs in time, effort and budget. One should choose the migration vendor carefully based on skills, experience and migration technology used to minimize the risk and maximize the benefit.
The principals of evaluating automated code translation vendors and their technology is fundamentally the same as any vendor evaluation in regards to attempting to quantify the vendor's solution as to risk, cost, value and overall synergy to the organizational goals. The difference lies in the details of what constitutes risk and value and the questions the organization needs to ask.
The greatest risk and cost accelerator associated with a migration project is incomplete or inaccurate translations. Vendors promising 50%, 60% even 90% automated code conversion seems inviting because they often promise low costs and fast delivery of initial results. However, the pieces left to be manually converted are most complex and difficult or they would have been translated; worse, they need to be translated in a way that is compatible with the already translated part, but that is the part the manual programmers don't want or can't afford to look at. The manual effort to finish the code conversion is often underestimated and corresponding often the source of cost overruns and even out right project failure. Next when customers evaluate the vendor price, they tend not to factor in the long term costs of maintaining the translated code. The ongoing support cost between a high quality translation vs. a low quality can be significant, and the general argument for migration in the first place is to lower the cost of ongoing development.
Vendor Background Relevant to Task
Company Purpose and Technology
- What is the vendor's core business competency?
- Is there a focus on building sophisticated program analysis/transformation tools?
- Is the vendor's technology flexible, mature, robust and solid?
- How big is the company team capable working directly the with translation technology?
- How much experience does the staff have working on technology supporting migrations and building translators?
- What is the longevity of staff at company?
- Are there competing priorities? Is this project a priority?
- How long has company been doing similar types of tasks?
- Do they use one technology for all the tasks, or a different technology for each task?
- Senior Management experience with translations?
- Success/Failure rate past migrations?
Translation Tool Technology Foundation
Is the translator based on proven classic compiler technology?
- Preprocessor handling?
- Symbol Tables?
- Control Flow Analysis?
- Data Flow Analysis?
- Pointer Analysis?
Does that translator use any specific or additional theory or technology to achieve its purpose?
- For which purposes?
- To investigate the legacy program structure to help find issues and problems?
- To support program analysis?
- For building up custom code fragments?
- For translation?
- For testing the result?
- To ensure maintainable results?
- Which advanced technologies?
- Processing source code with arbitrary character sets (EBCDIC card images, ISO-8859-1, UTF-8, Shift-JIS, GB-18030)?
- Parallel execution for faster performance?
- Attribute evaluators?
- Abstract Interpretation?
- Boolean logic simplification via Binary Decision Diagrams?
- Pattern matching on code fragments?
- Source-to-source transformation rules?
- Pattern matching on code fragments tied by dataflows?
Is that theory/technology used by the translator advanced compared to the state of the practice?
- Do the current company technologists know, use, or create that theory/technology?
- How mature is the translator technology?
- What is the variety of applications to which the foundation technology can be applied?
- Is the translation technology well documented?
- Is the vendor willing to describe it in detail?
- Is the technology designed for large scale code bases?
- How much of the full application can it read and analyze, to effect the conversion of a single component?
- Can the tool operate at large scale with low overhead?
- What is the ratio of custom code written for a specific translation by the translation engineers, compared to the existing code in the foundation technology that the translator will be using?
Details of Translation Technology
What are the legacy and modern target technologies supported?
- Does the vendor support all technologies (programming/scripting languages, database, macros...) within the legacy architecture?
- How many of these are supported off the shelf?
- Can the technology be configured to handle different dialects of the legacy technologies?
- Can the technology be configured to handle legacy technologies it does not already handle?
- Can it integrate inputs from multiple languages to influence specific outputs?
- Can it produce consistent, interoperable outputs in multiple languages?
- Is technology designed to be flexible enabling multiple targets and styles?
- How easily can the translator be adapted to handle special code syntax or target architectures?
- Can it handle changes to the languages of interest?
- How easily can the translator be modified to handle a mid-course change of plan?
- How is the translation expressed: via coded procedures, or by a rule-driven engine?
Translation completeness: How much manual coding/recoding and/or support resources is required from customer?
What percentage of automated conversion does the vendor typically achieve?
- Can the translator achieve near 100% automated conversion?
- How are deficiencies in the translator result resolved?
- What happens if a legacy source module gets revised and needs to be re-translated?
- Can translator implement arbitrary analyses to enable the most precise conditions driving translation results?
- Can translator carry out massive transformations to achieve architectural shifts?
- Is there means to rename variables and functions more meaningfully in the translated code?
- Are comments retained? In sensible places?
- Is the translation line by line in legacy source order, or is translated code moved to the most appropriate place?
- Is translated code at one point
- always translated the same way,
- is it affected by nearby code/declarations producing different tuned variations?
- affected by code/declarations that are far away in the source including in other modules?
- Is the translated code maintainable?
- Does the code look like something a typical programmer for the target languages(s) might write?
- Does the code depend heavily on support libraries that directly simulate features of the original language?
- Does the translator do deep and accurate control/data/call analysis on large bodies of code?
- Can the translator perform composable transforms to enable complex transformations across multiple languages?
- Can the translator be customized to client's specific needs?
- Can the translator results meet client style guidelines?
- Can the translator eliminate most or all GOTOs?
- Can the translator eliminate duplicated code?
- Can the translator eliminate dead code?
- Can the translator optimize assignments to temporaries?
- Does the translator produce readable code with nice, consistent formatting?
Approach for validating Translator and Translated Code
- How is/was the base technology on which the translator is built validated?
- Can translator elements ("rules") be inspected by all parties for accuracy?
- Does the translator have the ability to trace its execution for diagnostic purposes?
- Does the vendor have a process for testing translation of language features for accuracy?
- How does translator support making iterative changes/bugs found in testing?
- Does the vendor support tracking coverage of tests applied to converted code?
- Tracking what converted code has been tested?
- Tracking what tests activate what code?
Synergy of Translation Technology with Other Customer needs
- Can the translation technology support massive code reorganization:
- to achieve high level re-architecture shifts?
- Replacement of legacy database/accesses with modern databases/accesses?
- Can database schema changes be reflected into code?
- Exposure of internal APIs as services
- Does technology have possibility to help generate tests?
- Capture/Generate Inputs and/or Outputs?
- Capture/Generate Conditions of execution by flow analysis?
- Compare legacy outputs to converted outputs?
- Can the technology support code analysis needed for planning?
- Relation of code to other modules
- Detail tracing of data across modules
- Analyses applied to other legacy and modern languages (Java)
- Can the vendor support transformation of other legacy languages used by client, e.g., HLASM, COBOL, Natural, other?