前項の「基盤更改向けの推奨移行手順」で説明した「新テンプレートへの乗せ換え移行方式」については、
コチラにも書いていたのですが、具体的な手順は記述していませんでしたので、今回は、弊ブログに、この手順をメモして行こうと思います。
＜１．リリース情報のチェック＞
初めに、以下のリリース情報をチェックしておく。
特に、「
後方互換性に影響を与える変更」の部分に注意だが、新テンプレートへの乗せ換え移行方式を採用した場合、基本的には、殆どのアプリケーションには影響がない。
＜２．テンプレートの改修部位のチェック＞
次に、移行元のアプリケーションを開発した際に使用したテンプレートを保有しているなら、このテンプレートと移行元のアプリケーションとのDiffを取得しておく。コレによって、テンプレートやベースクラス２の改修やライブラリの追加を確認できる。この中で、新テンプレートへの乗せ換え移行時に、新テンプレートにも変更を加える必要があるものをメモしておく。
＜３．新テンプレートの準備＞
以下から、新テンプレートを取得し、先ず、新規開発可能な環境を整える。
環境が整ったら、２．でチェックした改修を新テンプレートにも加える（テンプレートやベースクラス２の改修やライブラリの追加など）。
＜４．最初の乗せ換え作業＞
手順、１、２、３で、土台となるテンプレートが整ったら、移行元のアプリケーションの「UOC（User Own Coding）」部分を新テンプレートに載せ替えていく。B層やD層など、ヘッダー部やフッター部に差異が無いモノは、ファイルごと移行できる。
＜５．最小セットのビルド作業＞
最小セット（ログイン・ログオフ画面、メニュー画面、CRUD機能辺り）の乗せ換えが完了したら、ビルドを行い、その範囲でビルドを行いテストを行う。ビルドエラーや実行エラーなどの不具合があったら、今後の類似不良対応のために、不具合の内容と対応方法をメモしておく。
＜６．最後まで載せ替え作業＞
４、５の作業を繰り返して、
移行元のアプリケーションをすべて移行したら、アプリケーションのテストを行った後、リリースを行う。
ココでのテスト内容は、テスト計画に従う。テスト計画は、前項に記載した「3rd party製のUIコンポーネント」、「RDBMSの変更」など、基盤更改の状況や、受け入れ先との役割分担による。従って、弊ブログでテストのポリシーについては言及しない。
...と、こんな感じで、移行して行くことが出来ると思います。
手順を再確認して、新テンプレートへの乗せ換えは、ストコンと違い、内容を理解して作業する必要はありますが、工数には大差はないと思います（移行案件は、殆どがテスト工数なので、見積もりはテスト計画次第だと思います）。 
Open COBOL Solution WG
【Open棟梁】新テンプレートへの乗せ換え移行方式の手順
