クラウド移行の手順を具体化するときは、「何を移すか」に加えて、「どの順番で切り替え、何を確認して次へ進むか」を決めます。予定どおり進まない場合の中止条件と、元の環境へ戻す手順も同じ計画に入れましょう。
この記事は、対象システムを把握した企業のIT・プロジェクト担当者に向けて、切替前から完了確認までを整理します。AWSとMicrosoftの公開ガイドを基にした計画の考え方で、特定製品の操作手順や当社の移行実績を紹介するものではありません。対象の整理から始める場合は、クラウド移行前のシステム棚卸しを先にご確認ください。
クラウド移行を進める手順と、各段階で決めること
移行計画では、作業名の一覧に「次へ進める条件」を添えると、当日の判断に使いやすくなります。次の表は、この記事で扱う流れを整理したものです。実際の順序と確認内容は、システムの構成や停止可能時間に合わせて調整してください。
| 段階 | 計画に書くこと | 次へ進む前の確認例 |
|---|---|---|
| 1. 実施計画 | 順序、担当、所要時間、連絡先 | 実施担当と判断担当が決まっている |
| 2. 事前テスト | 接続、認証、業務操作、性能 | 重要な業務を移行先で確認できている |
| 3. データ移行と切替 | 書き込み停止、同期、接続先変更 | 必要なデータと設定の確認が済んでいる |
| 4. 継続・切り戻し判断 | 中止条件、判断期限、復旧手順 | 戻す場合のデータの扱いが決まっている |
| 5. 完了確認 | 業務側の確認、監視、運用引継ぎ | 完了条件を満たし、残件に担当がいる |
表は計画を作るための整理例で、これだけで移行の安全性を保証するチェックリストではありません。
1. 作業順序と担当を実施計画に落とす
AWSの切替前ガイドは、作業の順序、担当、予定開始・終了時刻を記録する実行手順書を推奨しています。停止時間の検討には、想定外の問題への対応と切り戻しに要する時間も含めています。AWS：切替前の計画
自社の計画には、少なくとも「作業」「担当」「開始条件」「終了を確認する方法」を対応させて書きましょう。たとえば「接続先変更」の直後に「業務担当によるログイン・登録・検索の確認」を置けば、設定変更が終わったことと、業務を再開できることを分けて判断できます。これは記入の例で、実際に試す操作は対象業務から選びます。
2. 移行前に接続・認証・業務操作を試す
Microsoftの準備ガイドでは、移行先の構成要素が揃っていることに加え、ネットワーク接続、認証、機能・性能の確認を挙げています。性能は移行元の基準値と比較し、業務利用者による受入確認も行う考え方です。Microsoft：移行前のワークロード準備
確認項目を「サーバーが起動した」で終えず、利用者が完了させたい操作へ置き換えてみてください。販売管理なら「登録した注文を検索できる」「関連システムへ連携できる」などが候補です。これらは仮例であり、必要な試験を網羅するものではありません。
確認できない項目は空欄のまま進めず、「未確認の理由」「当日の確認方法」「実施可否を判断する担当」を残します。
3. データ更新を制御してから接続先を切り替える
Microsoftの実施ガイドは、事前に複製を進めて停止時間を短くする方法と、書き込みを止めてから移す方法を分けています。前者でも最終同期時の書き込み停止とデータ確認を扱っており、複製しているだけで停止や確認を省けるわけではありません。Microsoft：移行の実施
計画時には、「どの処理がデータを書き込むか」「停止を誰が確認するか」「同期後に何を照合するか」を対応させます。利用者の画面だけでなく、定期処理や外部連携からの更新も確認対象として検討しましょう。
接続先を変更した後は、実際に新しい環境へ接続していることと、重要な業務操作が完了することを確認します。データ照合の方法は対象によって異なるため、件数だけで十分と決めつけず、移行方式に応じた整合性確認を設計してください。
4. 切り戻しは「新しいデータがあるか」で分けて考える
切り戻しとは、移行を続けられない場合に元の環境へ戻す対応です。AWSのガイドは、新しいデータが発生していない場合と、切替後に更新が発生した場合を分けています。更新後は、クラウド側のデータを元の環境へ戻す対応が必要になる場合があります。AWS：切替と切り戻し
接続先を元に戻すことと、業務データを正しく戻すことは別です。計画には次の違いを明記しましょう。
- 新しい更新がない段階：元の環境と設定をどの状態へ戻し、何を確認するか。
- 新しい更新を受け付けた段階：更新を止め、追加・変更されたデータをどう保全し、元の環境へ反映するか。
中止条件と判断者も事前に決めます。「問題があれば戻す」ではなく、「重要な業務操作が確認できない場合は誰が継続可否を判断するか」と書くと、判断すべき内容が具体的になります。復旧方式や所要時間は、採用する構成で検証してください。
判断期限の記入例
仮に業務再開の期限が4時、切り戻し作業に45分、その後の確認に15分を確保するとします。この条件なら、計算上は遅くとも3時に切り戻しを開始する必要があります。
4時 −（切り戻し45分 ＋ 確認15分）＝ 3時
これは説明用の仮定です。実際はリハーサル結果を基に見積もり、判断・連絡の時間や余裕も見込みます。3時を過ぎてから戻すか考え始める計画にせず、その前に判断を終える時刻を設定しましょう。
5. 業務確認と運用引継ぎまでを完了条件にする
AWSの切替後ガイドは、関係者と監視項目を決め、移行後の支援期間を対象システムに合わせて合意するよう勧めています。四半期ごとのバッチがあるシステムでは、短期間の確認だけでは足りない例も示しています。AWS：切替後の確認
自社の完了条件には、重要な業務の確認結果、監視する項目、問い合わせ先、残件の担当と期限をまとめましょう。定期処理は実行周期も踏まえ、どこまで確認済みで、何が次回実行待ちかを区別します。
まずは対象システムを一つ選び、工程ごとの担当と判断条件を埋めてみてください。空欄が残る箇所が、移行日を決める前に確認したい事項です。インフラの検討や支援内容については、インフラ・クラウド技術支援をご覧ください。