Every time that we use the tool to complete a project, we make adaptations to it based on the language constructs used in the source system and the desired target output (including desired coding standards, architecture, language, target language features, etc.). This adaptability is actually one of the features of the tool—it is quickly and efficiently customized to a particular customer’s desired output, rather than being a “one size fits all” tool that probably disappoints most customers.
When the code in scope is run through the tool the first time, the tool identifies the language features for which there is adaptation required. These are displayed in some indices of the initial documentation it generates. This is one of the reasons for an initial onsite visit of a couple days—we can run the code through, make some minor initial adaptations, and generate code that is transformed with 95% or greater automation. We would also gather some information from you about the desired target architecture, and use that information to select which rules are used, and make changes to existing transformation rules as needed.
Typically, the next steps on the project are to decide upon desired target outputs and tune the toolset to address any parse errors remaining or other transformation rules to the target language. Since the tool uses rules applied to a model of the original source system, we can adjust and adapt the rules being used and rapidly regenerate the system (even many dozens of times, fairly rapidly) to iteratively regenerate the target until it meets the project requirements.