To the non-specialist, translating a piece of software from IDEAL to COBOL (or to any other language for that matter) is similar to compilation. It is an atomic process that converts a system written in IDEAL into a (hopefully) equivalent system in COBOL:
While possible in theory, such a monolithic approach (where the translation is performed by a single, probably complex process as opposed to a sequence of smaller, more manageable components) is vastly sub-optimal, because it requires the translation process to deal with all the facilities provided by CA-IDEAL, in all possible combinations.
The translation is divided in 3 steps but totally transparent to the end-user, who only sees the final result of this scaffolding of intermediate transformations.
When dealing with a non-trivial translation, where the source language does not map trivially to the target language, it is preferable to start by applying a number of simplifications to the source system to transform it to a canonical form, thereby reducing the number of constructs and cases to be taken care of by the translation process.
The process which ultimately translates a system from IDEAL to COBOL. It must be complete, in the sense of addressing all (or at the very least, a canonical subset thereof) the supported features of IDEAL and providing an equivalent implementation in the target language. It must be monolithic. If it isn’t, if it is to be divided in processes which each address some of the aspects of the translation from IDEAL to COBOL, its intermediate results would be inconsistent. They would be made of a mix of IDEAL and COBOL, which is a less than desirable property.
Similarly, to the case for the division of the preliminary transformation in a sequence of independent passes, allowing for additional transformation after the migration process is an equally appealing proposition. It allows for division of concern and reusability. Equally importantly, it allows the IDEAL to COBOL phase to remain as simple as possible, since a number of quality improvement processes can now be performed post hoc.
What makes this even more appealing is the fact that the COBOL restructuring facility used at the end of this translation chain is a standard component provided by RaincodeLabs in a number of situations, including PACBASE, COOL:Gen or MetaCOBOL migrations.