Let us continue with the remaining steps in putting together the methodology for the core process of migration.
6. The Estimation Model is simply derived from the Transformation Model by putting down the time required for carrying out each step in the Transformation Model. Steps of (b) (only those not handled by grep-like utilities) and (c) kind, being manual, would be time consuming. Any inaccuracy in estimation for (a) kind of step will not significantly impact the over-all estimates, being tool-driven.
7. Finally put together the Process Model for the project. The Process Model is like a kitchen-book recipe for carrying out the migration. It lays down the entire conversion in terms of a sequence of steps cataloged in the Transformation Model to cover all instances of all code-classes in the source context.
A sample section of the Process Model for migrating a module ABC shows the following sequence of steps cataloged in the Transformation Model, limited to migrating a set of ASP code-class instances of the module ABC:
d.1: Use an identified tool X to convert 10 ASP pages of the module ABC. This is a step of (a) kind.
d.2: Use grep on these converted ASP pages to handle instances of change-unit-classes: 1, 3 and 6, a step of (b) kind not handled by the tool X.
d.3: Manually scan the converted pages to identify instances of change-unit-classes: 2, 4 and 5, again not handled by tool X or grep-like utilities in steps d.1 and d.2. Note manual scans are not explicitly included in the Transformation and Estimation Models. Also note that sometimes, a grep-like tool may also be used to flag these instances even if the conversion is done manually, thereby averting this manual scan.
d.4: Manually convert in all the 10 ASP pages, the flagged instances of change-unit-classes: 2, 4 and 5 as per the transformations cataloged in the Transformation Model.
In general, one or more partial or full manual scans of source or target code-class instances must be provided in the Process Model for: a) detecting instances of change-unit-classes that are not handled by the tools or by grep-like utilities b) to cover some special situations c) to look out for new change-unit-classes not listed in the Transformation Model and d) to check the target after conversion. Some over-all scan rates are assumed and factored into effort computation.
Note that the efforts required for this piece of migration in the Process Model could be computed, given the Estimation Model, and if the number of instances of those change-unit classes (2, 4 and 5) across the whole set of 10 ASP pages which need to be handled manually in step d.4 are known (not considering d.3 for simplicity). This is the key to estimating efforts in migration projects. In simple terms, find out all instances requiring manual conversions and what is the time taken for converting an instance. This exercise may also be called as Impact Analysis. At project execution time, Impact Analysis is obviously done exhaustively covering all instances of code-classes to achieve error-less migration. Whereas at the time of submitting a proposal or initially planning the timeline for the project, Impact Analysis is often done on a representative set of code-class instances and the results are projected across the complete set of code-class instances comprising the source application. Herein lies the serious risk of going wrong with the effort estimates.
There is an important question that we have not addressed yet. Given the source context comprising numerous instances of many code-classes how do we sequence our steps in the Process Model? Note that the other two models, Transformation and Estimation Models, do not address this question.
Let us think of the migration project as made of migration units representing chunks of migration which may be progressively carried out and even verified. These chunks could be organized by function. For instance, a set of Oracle Forms in Order Entry or a set of web pages of Product Catalog in an e-commerce site, or they could be by code-class; for instance, all asp pages, all the code in data access layer, etc. It is usually a mix of both approaches. With the former, a migration unit has instances of multiple code-classes to be migrated. For instance, migrating a set of JSP pages would mean migrating the JSP pages themselves, Java beans used by these pages, possibly the CSS, etc.
The function-wise approach makes it possible to validate the migration methodology, models and tools early in the project. Once validated, migration could now be undertaken code-class-wise until sufficiency is reached to take up a function-wise migration and switch back and forth. Or, any other mix and sequence of the two approaches.
We have, in the above, successfully laid out the key steps in the migration methodology which is neutral to technologies; and its principles are applicable to a wide range of migration projects: upgrade of infrastructure systems like mail, platform migration of application systems and even ERP version upgrades.
This piece focuses only on the core methodology of project execution. It does not cover initial phases like Inventorying, Pilot for validation and estimation or the closing phases like Testing, Data Migration, Cut-over or the pre-project phases of Initial assessment, Preparing the project proposal, etc., all of which are also rigorously methodology-driven.