Review the manual changes applied

Another way to identify a Customization Opportunity is to review the manual changes being applied to the migrated source code. After identifying an error, the Developer performing the fix must check if the error is recurrent. In that case a Customization Opportunity must be considered. Several factors must be taken into account at this point:

• Timing: Will the current timeframe allow the VB6 AI Migrator Development Team to develop the required customization? Even if it isn’t, the error should be reported to evaluate its inclusion in future releases so the error doesn’t appear in future projects
• Complexity: Is there an opportunity to make the massive replacement using another automated solution as Regular Expressions?
• Rework required: Will remigrating the code require a large amount of significant manual changes (such as a partial rearchitecture) to be re-applied manually? Be aware that there is always the option of performing a semi-automated code merge, as described in How to Perform a Continuous Migration

Customization Opportunities must be evaluated by the migration project’s Technical Leader, who should decide if the issue is reported to the VB6 AI Migrator Development Team at GAP and the priority given to the customization.

In case the team decides to do the manual change, there are some techniques that can help determine the best way to translate the code. This usually require some research, as manual changes usually are required for complex parts of code.

The most important step when resolving an issue manually is to identify the purpose of that section of the code in the original application. This can be achieved through several sources:

• Consultant’s knowledge
• Manual Changes Historic Database
• Product Manuals
• Internet Research
• Peer Knowledge