al lee & associates, inc.
A Strategy for Migrations
Migrations of applications from one environment to another can be fraught with dangers, most of which are not obvious beforehand without an in-depth analysis by experienced technicians and managers prior to embarking on the journey.
Even projects undertaken by large, reputable consulting firms often lead to missed deadlines, large cost overruns, and pervasive system errors that may take years to ferret out and correct. We believe that the most critical phase of a large migration project occurs before actual conversion work begins.
While every project is unique, we recommend an approach for the preparation phase of the project that includes the following:
1. Survey the current application system to understand the functionality it provides and note its existing strengths and flaws. Also note planned upgrades and modifications.
2. inventory the programs, files, databases, tables, copybooks, include members, etc. that are to be migrated.
3. produce a data dictionary of all the entities.
4. expand the dictionary to a detail level (fields, rows, etc.) with the characteristics of each.
5. ascertain what tasks of the migration lend themselves to automation in order to reduce cost and increase reliability and consistency.
6. produce general specifications of automated conversion programs that can be applied. Such programs should be driven by the data dictionary.
7. produce a projection (documented in a spreadsheet) based upon anticipated manpower – the projection is to be used throughout the project as a task list and status reporting mechanism.
Of course, these are general in nature and must be tailored for each particular project; but we believe that doing this work prior to launching on the actual project will lead to a much improved probability for success and on-time, on-budget completion of the migration.
It is impossible to perfectly anticipate every detail of any large project; so it is imperative that a good working relationship be established and maintained between the migration team and the permanent system maintenance and management staff. Because the motivations of these two groups of people may not always be aligned, we prefer to employ a compensation structure that gives both sides the motivation to effect a successful project at the lowest cost and in the shortest time.
We will be happy to discuss such an arrangement with you. We have successfully used the compensation plan designed by Al Lee many years ago on many projects. It might also work well for your project with us.
It is important to note that migrating an application does not always mean merely replication of the identical functionality on a different platform. For instance, when migrating from an in-house mainframe computer system to a web-based server, it might be necessary to improve the security and error recovery mechanisms also. Or, migrating from a system that inherently has a scheduled “down time” to an environment that could potentially afford access 24/7, it might be necessary to produce new functionality to accommodate cut-off times, backup, or off-line processes. All such expanded requirements should be discussed and planned for prior to initiating the migration project.
Finally, plans for confirming the validity and accuracy of the system in the new environment should be made. Parallel processing (when possible) should be planned on, as should the accurate and automated transfer of databases when the cutover is to be done.
The preparation for the project should not be done in a hurried time frame as it is important to be thorough here. If this is done well, the actual project can proceed at a much faster pace than might have been possible otherwise, more than making up for time spend up front.
# # #