必要な項目は書かれているのに，精度が低く役立たないことも多い。例えば「3 移行中の影響」（第2回 図2）として業務面の影響は書いてあるのに，運用監視への影響があいまいというケースだ。
移行期間中は，一時的に特殊なシステム構成になることがあるので，平常運用時とは監視項目が変わる。こうした点を細かく洗い出し，移行計画書に反映することが必要だ。移行計画書の精度を上げるには，三つのポイントを吟味しておきたい。「移行方式」「移行データ」「権限と統制」である。
止められないなら段階移行方式で
まずは「移行方式」から。主な移行方式は3種類ある（図1）。（1）一括移行方式，（2）段階移行方式，（3）並行運用方式である。コスト，運用の手間，時間，回復の容易さ，リスクで一長一短がある。システムの規模や複雑性，重要度などを勘案しながら選択し，「1.2 移行方針」に明記する。
 |
| 図1●三つの移行方式の特徴 「一括移行」「段階移行」「並行運用」という三つの移行方式がある。★が多いほどメリットが大きい。メリットとデメリットを考慮しながら，移行計画書の「1.2 移行方針」に記述する [画像のクリックで拡大表示] |
一括移行方式は，ある時点で現行システムを休止して切り離し，全機能を新システムへと一気に切り替える方法である。現行システムとのデータ連携などを考える必要がなく，移行のコストを最小化したいときに向いている。また，現行システムをそのまま温存するので，万一新システムでトラブルが生じても，現行システムに切り替えて業務をすぐに再開できる。つまり，移行失敗に伴う回復は容易なのだ。半面，数日程度のまとまった時間のシステム停止ができないと，データ移行やシステム切り替えが難しい。全機能が一気に切り替わるために，移行自体のリスクは大きくなる。
段階移行方式は，「業務」「機能」「拠点」といった，ひとまとまりの単位ごとに現行システムを休止し，順次，新システムに切り替えていく方法だ。機能単位で移行する場合，ある機能は現行システムで稼働し，別の機能は新システムで稼働する形になる。そのため，移行過程では両システムの連携が必須となる（第2回図2の「1.4 移行フェーズごとのシステム状態」の記述例を参照）。一般的には，専用のインタフェースを開発して相互にデータを参照・更新したり，EAI（Enterprise Application Integration）ソフトを使いデータを同期させたりすることになる。こうしたデータ移行ツールの設計と実装に多少の手間がかかる。だが，一括移行方式よりも切り替えの単位が小さい分だけ，数時間から1日程度の短いシステム停止を繰り返せば移行できる。最近では，大規模システムの移行で，一括移行方式のリスクを負えないときに段階移行方式を選択することが多い。
並行運用方式は，現行システムと新システムを同時並行で稼働させ，結果を比較検証しながら移行する方式である。サービス開始後しばらくは現行システムと新システムを二重運用し，新システムに問題がないと分かった時点で現行システムを停止する。このため移行のリスクは小さい。業務担当者がデータの二重入力などに協力してくれれば別だが，通常は両システム間でデータを同期させるEAIソフトなどが必要になる。結果を常に比較検証できるので互換性を高められるが，チェックを繰り返す業務担当者の手間が増える。両システムの監視・管理が必要な運用担当者の作業負担も倍増する。
正常なのに異常と見なされる
段階移行方式や並行運用方式を選択した場合，移行期間中に移行済みの一部機能を停止させたり，移行ツールでデータを同期させたりすることになる。現行システムにとっても，新システムにとっても，本来の運用ではあり得ないシステム構成になる。その結果，システムは正常に稼働しているのに監視ソフトが“異常”を検出したり，一見するとトラブルと思える現象が発生したりしがちだ。
例えば，現行システムで一部の機能を段階移行した場合，移行した機能が動作していないことを監視エージェントが“異常”と見なし，運用担当者に警告メッセージを送ってしまうことがある。こうした事態に慌てないように，移行前から移行完了までの工程ごとに，監視・管理上の注意点を洗い出し，運用担当者などの理解を求めたり，移行計画書の「3 移行中の影響」（第2回 図2）に具体例を記述したりするのである。
