はじめに
物理的なハードウェアの消耗や、ソフトウェアのサービス終了、業務刷新等、様々な理由により、現行のシステムを新しいシステムへ載せ替える作業を「移行」と言います。
ここでは移行に関連するいくつかの内容を整理していますので、移行に初めて携わる方の参考としてもらえればと思います。
移行の分類について
移行はクラウドへの移行や、複数システムの統合、EOS等を理由にしたリプレース等のプロジェクトごとのゴールを持っていますが、基本的には以下３つのカテゴリで分類されます。
すべて必須というわけではなく、移行計画の結果、プロジェクトによっては発生しないカテゴリもあります。
１：システム移行
システムを構成する環境の移行。
サーバ構成や運用まわり、ネットワーク、ミドルウェア、アプリケーション自体の載せ替え作業。
２：データ移行
現行環境でのデータをシステム移行後の環境で動作するように移管する作業。
システム移行とセットで検討されることが多い。
３：業務移行
システム、データ移行後の環境で、業務運用が可能なように体制や教育、手順等を移管する作業。
移行方式について
システムの規模や制約等により移行の方式を検討する必要があります。
コストも期間も短いのは一括移行ですが、他の方式も計画時に検討しましょう。
１：システム一括移行
システムを一定期間停止し、新しい環境へ一気に移行する方式。
移行としてのコストや期間を他と比べて抑えることができる。
２：並行稼働
現行システムと新システムを並行で稼働させ一定期間の後、現行システムを停止させる方式。
データ同期等の問題が発生することが多いが、業務的な混乱は少ない。
３：順次移行
機能単位で順次移行させていく方式。
システムの規模や利用者への影響を加味して計画を立てる必要がある。
実際の移行におけるポイント
移行においては様々な落とし穴が存在しますが、よくやりがちなポイントを整理しました。
移行計画を作成する上でのリスクとして検討しましょう。
複数ステークホルダーの連携
移行作業はその特性から様々なステークホルダーが存在します。
関係者を特定し、計画を基にしっかりと連携をとりましょう。
例）
- 現行環境（インフラ、アプリケーション）を管理するベンダー
- 移行先環境（インフラ、アプリケーション）を構築するベンダー
- 運用まわりを管理する担当者
- 接続先システムの担当者
- 移行計画を立て、推進する担当者
- 業務移行を取り仕切る担当者
- システム利用者
リハーサルは複数回、切り戻しまで
計画時点でリハーサルは複数回予定し、可能であれば出来るだけ本番環境と近い環境での実施としましょう。
リハーサルをやり遂げるたびに成功率が上がります。
一例としてですが、初回は手順書実施における想定時間の確認や、細かい手順書ミス等の洗い出しをし、２回目以降は本番さながらの実施で、切り戻しまで実施をすることで成功率を上げることが可能です。
こちらはシステムの特性（停止可能時間等）により変動します。
データ移行は本番データに近いもので
システム移行は完璧だったものの、移行されたデータを基にしたら、設計上では見つからなかった想定外のデータパターンが見つかるというのはよく見かけるミスです。（データ破損、性能面への影響も含め）
本番データに近しいデータでの試験を計画しましょう。
さいごに
移行は業務影響という点において、「移行失敗＝業務への影響が大」となることがほとんどです。
ここまで慎重に検討するのかと思うほどリスクを細かく潰し、計画をしっかり立てることで、移行当日や移行後のスムーズな新環境での稼働が出来るように推進していきましょう。
