In an earlier post on Project Genre, we talked about the characteristics of migration projects in general. And we had observed these projects are heavily process driven. A good part of the conversion would have to be carried out even without understanding the functionality of the code pieces under conversion.
The migration process executes a rigorously pre-conceived migration methodology. Let us look at some major steps in laying out the methodology of conversion whether the conversion itself is carried out manually or with the help of a tool:
Also let us reasonably assume the conversion is one-to-one with no enhancements or optimization for the target context attempted.
1. The source context (application to be migrated) has certain architecture. In this context, various code pieces and meta-data (asp/jsp pages, Java beans, Active-X, client-side scripts, Dll’s, html pages, css, cgi modules, database stored procedures, triggers, schema, xml files, forms lay-out files, etc.) are architected to work together. Let us flag each of these as a distinct code-class (like file extensions). And, in the application, there would be numerous instances of these code-classes.
2. Similarly the target context also has code-classes architected together. Now establish the correspondence/mapping between source and target code-classes. Migration effort is less if the two code-classes are similar. This is where the migration tools shine with the advantages of speed and quality. Tools are usually good at transforming instances of one code-class in the source context to a similar code-class instance in the target context. They may not achieve 100% conversion all by themselves. Certain constructs may have to be migrated manually. Prima-facie a tool that minimizes manual effort is a better one, other things being equal. A likely area where manual intervention may be required is when some features of the code-class in the source context are de-supported/deprecated in the corresponding code-class in the target context.
So, line up a set of tools after due evaluation that together migrate as many code-classes and with as less manual intervention as possible.
3. Strategize how a code-class will be migrated (possibly rewritten) when there is no similar corresponding code-class supported in the target context. For instance, Active-X controls may be supported in the source context and not in the target context. The conversion could be totally manual or partially assisted by tools.
4. At this point, it is fairly clear what part of migration is driven by tools and what part needs to be handled manually.
5. Now set up the Transformation Model. The Model lists every step (well, almost) of transformation of the application. These steps fall into three kinds of buckets: (a) a tool-driven transformation (b) supplementary manual changes to make up for a tool’s deficiencies or to cover some special situations and (c) a total re-write of some code-class instances.
For easy comprehension, (a) and (b) could be organized tool-wise and (c) by code-class.
(b) actually consists of a number of different cases or change-unit-classes, each change-unit-class representing a single case of a source construct to be modified into an equivalent target construct. These are code snippets in the source not handled by the tools automatically. Many of the simpler change-unit-classes may be implemented by grep-like utilities and only the remaining need to be converted manually. Even when manual rewrite is necessary, it could be done without an over-all understanding of the processing logic.
(c) is like any new development. Importantly, it would require an understanding of the functionality realized by that code-class instance.
From here, we’ll continue in the next post with the Estimation Model and the Process Model including sequencing of the steps.
Tags: Migration, Project, Project Genre
