Migrating before you’re forced to is clearly a wise IT strategy, but maybe it’s too late for that strategy. If you’re already past the point where you can take a more leisurely view of migration, you may be facing increased technical risk or cost. You may have to extend your total migration schedule and may not be able to exploit the new functionality and performance features of the technology as quickly as you’d like.
So, what about users who now face an immediate LE migration to move to CICS TS V3.1 or DB2 V8? For them, some approaches are better than others; under pressure, none are perfect.
Three LE Migration Potholes
Migrating entire portfolio: A mass migration has been used in a few cases, but you significantly increase your risks by attempting to migrate your entire portfolio simultaneously. Change management strategies almost universally emphasize making only one change at a time to allow for less complicated testing, backout, and recovery processes.
Emulation: Attempting to migrate by emulating an environment IBM no longer supports also raises the risk of failure, and may hamper performance. This Band-Aid method hides the real wound and only delays the inevitable updates that really should occur.
One step at a time: In this approach, a CICS or DB2 customer would migrate the run-times and re-compile one program or application at a time with the LE-conforming compilers when required. Clearly, many customers will take this approach because of such factors as time, resources, cost, etc. The exposure here is that you must understand all the inter-relationships and cross-talk among your applications to avoid introducing errors in the applications not yet migrated. This is probably the best approach as long as good planning and proper management techniques are followed. Certainly, it’s the way to go when not under the duress of other pending migrations. You can reduce your risks by following the guidance below.
The IBM Migration Guides