カットオーバーのチェックリスト｜移行当日の手順と切り戻し

システムの本番移行、いわゆるカットオーバーは、受託開発のプロジェクトで最も緊張する数時間です。開発とテストをやり切っても、移行当日の段取りが甘いと、一晩で顧客の信頼を失う事故につながります。

作業手順書はあるのに、当日になって「誰がGoを判断するのか」「どこまで進んだら戻れないのか」が曖昧なまま突入してしまう。そんな現場は決して珍しくありません。手順そのものは正しくても、判断の設計が抜けているために、トラブル発生時に全員が固まってしまうのです。

本記事では、移行当日を事故なく乗り切るためのカットオーバーのチェックリストを、事前準備・リハーサル・当日タイムライン・切り戻しの判断基準まで、そのまま使える形で整理します。移行データの検証そのものではなく、当日の実行・段取り・切り戻しに焦点を当てます。

対象読者は、システムの本番移行を主導する受託開発のPMやリーダーです。専任の移行担当を置けない体制でも回せるよう、最小限の役割分担と判断基準に絞って解説します。

チェックリストは「作業の抜け漏れ」だけでなく、当日の判断を誰がいつ下すかまで含めて設計することが肝心です。この視点を欠くと、手順書が揃っていても当日は混乱します。

カットオーバーのチェックリストが失敗を防ぐ理由

カットオーバーの事故は、技術的な難しさよりも「段取りと判断の抜け」から起きることがほとんどです。移行スクリプトが動くかどうかは事前に検証できますが、当日の意思決定は本番の緊張下で行われます。

深夜の作業で疲労が溜まり、想定外のエラーに直面したとき、人は冷静な判断を保ちにくくなります。そこで拠り所になるのが、事前に合意したチェックリストと判断基準です。属人的な勘ではなく、紙に書かれた基準に沿って進めることで、現場の誰もが同じ判断にたどり着けます。

つまりチェックリストは、当日の担当者の能力に依存しない「仕組み」として機能します。ベテランがいないと回らない移行は、そのベテランが休んだ瞬間に破綻します。仕組み化しておけば、体制の薄い現場でも安定して移行を完遂できます。

当日に起きがちな3つの崩れ方

移行当日の失敗は、次のようなパターンに集約されます。原因を知っておくだけで、対策の優先順位が見えてきます。

• 時間切れ型: 作業に想定以上の時間がかかり、朝の業務開始に間に合わない
• 判断遅延型: トラブル発生時に「続けるか戻すか」を誰も決められず時間だけが過ぎる
• 確認漏れ型: 移行自体は終わったが、疎通や整合性の確認が甘く、翌日に障害が発覚する

時間切れ型はリハーサルの実測不足から、判断遅延型は責任者と基準の未定義から、確認漏れ型は移行後確認の軽視から生まれます。いずれも移行の「実行」ではなく「設計」の問題です。

この3つはいずれも、チェックリストと判断基準を事前に決めておけば大半を防げます。

チェックリストが担う4つの役割

このチェックリストは、単なる作業一覧ではありません。次の4つの役割を同時に果たします。この4つを意識して作ると、単なるToDoリストが「事故を防ぐ道具」に変わります。

役割	内容	これがないと起きること
作業の網羅	やるべき作業を漏れなく列挙する	手順の抜けで移行が不完全になる
順序の固定	依存関係のある作業の実行順を定める	順序ミスでデータ破損が起きる
判断の明確化	Go/No-Goや切り戻しの基準を示す	当日に判断できず時間を浪費する
責任の分担	各作業の担当と承認者を決める	「誰がやる」が曖昧で作業が止まる

多くの現場で用意されているのは、このうち「作業の網羅」だけです。順序・判断・責任の3つが抜けているために、当日になって混乱が生じます。チェックリストを作るときは、この4役割がそろっているかを自問してください。

カットオーバー計画の全体像｜4つのフェーズ

チェックリストに入る前に、カットオーバー全体を4つのフェーズで捉えておきます。個々の作業は、このどこかに必ず位置づけられます。全体像を共有しておくと、関係者が「今どの段階か」を把握しやすくなります。

カットオーバーは「当日だけの作業」ではなく、準備・リハーサル・当日・移行後の連続したプロセスとして設計します。

フェーズ	主な目的	代表的な成果物
事前準備	移行対象と手順を確定し関係者を巻き込む	移行手順書・バックアップ・告知文
移行リハーサル	本番同等環境で通しの実測と検証を行う	所要時間の実測記録・課題一覧
移行当日	手順に沿って本番移行を実行する	タイムライン・Go/No-Go判定記録
移行後確認	疎通・整合性・監視で正常性を確かめる	確認結果・受付開始の合図

このうち、当日の作業に目が行きがちですが、成否を決めるのは前半の2フェーズです。事前準備とリハーサルに十分な時間を割けているかが、そのまま移行の安全性に直結します。

PMが最初に押さえる3つの数字

計画段階で、PMは次の3つの数字を早めに固めておくと後工程が安定します。逆にこの数字が曖昧なままだと、当日の判断がすべて感覚頼みになってしまいます。

• 移行ウィンドウ: 移行に使える停止時間の総量（例: 土曜22時〜日曜6時の8時間）
• 切り戻しに必要な時間: 問題発生時に元へ戻すのにかかる時間（例: 2時間）
• Point of No Return: これを過ぎると切り戻せない時刻（後述）

これらは後述する判断基準の土台になります。数字を「例」として仮置きし、リハーサルの実測で確定させていく進め方が現実的です。最初から正確な値を求めるのではなく、仮置き→実測→確定の順で精度を上げていきます。

移行そのものの品質検証を深掘りしたい場合は、データ移行テストの進め方と検証設計で移行データの正しさを担保する方法を解説しています。本記事は、その検証を終えた前提で「当日の実行」に振り切ります。データの正しさは移行前に固め、当日は段取りと判断に集中するのが理想です。

事前準備のカットオーバーのチェックリスト

ここからが実務で使えるチェックリストの本体です。事前準備は、移行の成否の8割を決めると言っても過言ではありません。当日の作業を減らすほど、事故のリスクは下がります。

準備段階では「当日やらなくて済むこと」を一つでも増やす発想が有効です。事前にできる作業を前倒しし、当日のウィンドウには本当に停止が必要な作業だけを残します。

移行対象と手順の確定

まずは何を移行し、何を移行しないのかを明確にします。曖昧なまま当日を迎えると、対象の取りこぼしや二重移行が起こります。

• 移行対象のデータ・ファイル・設定を一覧化し、移行するもの／しないものを明示した
• 各作業の実行順と依存関係を手順書に落とし込んだ
• 手順書には「作業内容・想定所要時間・担当・完了確認方法」を各行に記載した
• 手動作業を可能な限りスクリプト化し、コピペ手順を減らした
• 手順書は当日の担当者以外が読んでも実行できる粒度になっている

手順書の粒度は「その場にいない人が読んでも実行できるか」を基準にします。作成者本人だけが分かる手順書は、作成者が倒れた瞬間に使えなくなります。

バックアップと復旧手段

バックアップは「取っただけ」では意味がありません。そこから確実に戻せることまで確認して、初めて安全策になります。

• 移行前の状態を完全にバックアップし、復元手順を用意した
• バックアップからの復元を実際に試し、所要時間を計測した
• バックアップの保管場所と復元権限を持つ担当を明確にした

復元の所要時間は、後述するPoint of No Returnの計算に直接使います。ここを測っていないと、切り戻しの限界時刻を正しく引けません。

関係者調整と告知

移行は開発チームだけでは完結しません。インフラ、ネットワーク、外部連携先、そして顧客まで巻き込んだ調整が必要です。

• 移行日時と停止範囲を顧客・エンドユーザーに事前告知した
• 移行当日の連絡体制（誰にどの順で連絡するか）を決めた
• インフラ・ネットワーク・外部連携先など関係部署の待機を確保した

告知は「いつ止まり、いつ使えるようになるか」を具体的な時刻で伝えることが信頼につながります。曖昧な告知は問い合わせを増やし、当日の現場を圧迫します。

下の表は、事前準備の完了状況を可視化する簡易フォーマットです。各セルを空欄にせず、必ず状態を書き込みます。空欄は「未確認」と同じであり、抜けの温床になります。

準備項目	状態	担当
移行対象の一覧化	完了	開発リーダー
手順書の作成	完了	開発リーダー
バックアップと復元テスト	完了	インフラ担当
顧客・ユーザーへの告知	完了	PM
連絡体制の確定	完了	PM

告知や初動を含む信頼維持の観点は、本番バグ発生時に信頼を守る予防と初動でも詳しく扱っています。移行はうまくいって当たり前と見られる作業だからこそ、コミュニケーションの丁寧さが評価を左右します。

移行リハーサルのチェックリスト

事前準備の次に重要なのが、移行リハーサルです。手順書が「頭の中で正しい」ことと「実際に時間内で通る」ことは別問題だからです。リハーサルを省いた移行は、ぶっつけ本番の綱渡りと変わりません。

リハーサルの最大の目的は、手順の確認ではなく所要時間の実測にあります。時間が読めなければ、当日のGo/No-Goも切り戻しも判断できません。

リハーサルで必ず測る項目

リハーサルでは、手順が動くことよりも「どれだけ時間がかかるか」を重視します。時間の実測こそが、当日の判断材料になるからです。

• 本番と同等のデータ量・構成の環境で、移行手順を頭から末尾まで通した
• 各作業ブロックの所要時間を実測し、手順書の想定値を更新した
• 移行ウィンドウ（停止可能時間）に対して、実測の合計時間が収まることを確認した
• リハーサルで発生した課題を一覧化し、当日までに解消する担当を決めた

特に注意したいのが、データ量の差です。開発環境の少量データでは一瞬で終わる処理が、本番相当のデータ量では数時間かかることも珍しくありません。必ず本番に近いボリュームで測ります。

切り戻しリハーサルも必ず行う

移行の通しだけでなく、切り戻し（ロールバック）も一度は通しておきます。切り戻し手順は「使わないこと」を願う手順ですが、練習していなければ本番で使えません。

• バックアップからの復元を含む切り戻し手順を、実際に最後まで実行した
• 切り戻しにかかる時間を実測し、Point of No Returnの設定に反映した
• 切り戻し後にシステムが移行前の状態へ正しく戻ることを確認した

切り戻しは、最も緊迫した状況で発動される手順です。だからこそ、平常時に一度手を動かしておく価値があります。手順書を眺めるだけでは、いざというときに動けません。

リハーサルと本番の差分は、次のように整理して当日リスクを見積もります。

比較項目	リハーサル	本番当日
データ量	本番相当のコピー	本番実データ
実行者の緊張度	低い	高い
想定外事象	少ない	起こり得る
所要時間の余裕	確保しやすい	圧縮されやすい

この差分を踏まえ、当日は実測時間に2〜3割のバッファを上乗せして計画すると安全です。リハーサルでぴったり収まった計画は、本番の想定外で簡単に溢れます。

当日のタイムライン例｜作業ブロックと担当

事前準備とリハーサルが済んだら、当日のタイムラインを1枚にまとめます。時刻・作業・担当・完了確認をひとつの表で共有すると、現場の認識ずれが減ります。

タイムラインは、当日の全員が同じ紙を見て動くための共通言語です。口頭での指示は聞き漏らしや解釈違いを生みますが、1枚の表があれば「今どこにいるか」を全員が把握できます。

タイムラインには「判定ポイント」を明示的に組み込むことが重要です。作業だけを並べると、判断のタイミングが抜け落ちます。

以下は、8時間の移行ウィンドウを想定したタイムライン例です。時刻・時間はあくまで一例であり、実際はリハーサルの実測値で置き換えます。

時刻(例)	作業ブロック	担当ロール	完了確認
22:00	サービス停止・アクセス遮断	インフラ担当	停止画面の表示確認
22:15	移行前バックアップ取得	インフラ担当	バックアップ完了ログ
23:00	データ移行スクリプト実行	開発担当	スクリプト正常終了
01:00	整合性・件数チェック	QA担当	チェック結果の合格
02:00	Go/No-Go判定	PM(責任者)	判定記録への署名
02:30	アプリ切替・疎通確認	開発担当	主要機能の疎通OK
04:00	監視・受付開始準備	運用担当	監視アラート正常
06:00	サービス再開	PM(責任者)	再開告知の発信

この例で重要なのは、02:00に「Go/No-Go判定」という判断のブロックを独立して置いている点です。作業の合間に判断を埋め込むのではなく、判断そのものを一つの工程として時間を確保します。

ロールと権限を先に決める

タイムラインが機能するのは、各ロールの担当が事前に決まっている場合だけです。特に次の3つの役割は、当日始まる前に指名しておきます。

• 移行実行者: 手順書に沿って作業を進める担当
• 確認者: 各ブロックの完了を独立して確認する担当
• 判断責任者: Go/No-Goと切り戻しを最終決定する人（多くはPM）

見落とされがちなのが「確認者」の独立性です。作業した本人が確認まで兼ねると、思い込みによる見落としが起きます。可能なら、実行者とは別の人が完了確認を行う体制にします。

当日の進捗を可視化する発想は、通常のテスト工程の進捗管理と共通します。作業の状態を全員が見える形にしておくことが、移行当日でも遅延の早期発見につながります。

Go/No-Go判定と切り戻しの判断基準

カットオーバーで最も難しいのは、作業そのものよりも「続けるか、戻すか」の判断です。ここを曖昧にすると、当日の現場は必ず止まります。判断基準は、緊張した現場で感情に流されないための「事前の約束」です。

Point of No Return（切り戻し限界点）の決め方

Point of No Returnとは、これを過ぎると切り戻しが間に合わなくなる時刻を指します。移行ウィンドウの終了時刻から、切り戻しに必要な時間を逆算して決めます。

Point of No Returnは、移行ウィンドウ終了時刻から切り戻し所要時間を引いた時刻として計算します。

• 例: 移行ウィンドウが翌6:00まで、切り戻しに2時間かかるなら、Point of No Returnは4:00
• 4:00までに正常性が確認できなければ、続行せず切り戻しを選ぶ
• この時刻は当日全員が見える場所に明示し、共有する

この考え方の肝は、「まだ時間がある」という楽観を排除することです。人はトラブル時に「もう少しで直る」と考えがちですが、切り戻しには一定の時間が必要です。その時間を確保できる最終時刻を、あらかじめ引いておきます。

Go/No-Goの判定項目

判定は雰囲気ではなく、事前に決めた項目で行います。すべてがGoなら進み、ひとつでもNo-Goなら止めるのが原則です。判定項目を明文化しておくと、その場の空気に押されて無理に進むことを防げます。

判定項目	Goの条件	No-Goの場合
データ移行	件数・整合性チェックに合格	切り戻しを検討
主要機能の疎通	主要導線が正常に動作	原因調査後に再判定
所要時間	Point of No Return前に完了見込み	続行せず切り戻し
重大な想定外事象	発生なし	発生時は即エスカレーション

誰が決めるかを先に決める

判断基準と同じくらい重要なのが、「誰が最終判断するか」です。当日その場で決めようとすると、責任の押し付け合いで時間を失います。

• 判断責任者を1名（通常はPM）に定め、事前に顧客と合意しておく
• 顧客側の承認が必要な場合、当日連絡可能な決裁者を確保しておく
• 判定結果は口頭で流さず、記録に残す

顧客側の決裁者が深夜に連絡不能というのは、よくある落とし穴です。移行が深夜帯なら、顧客側の承認プロセスも深夜に回せる形にしておく必要があります。事前に「この時間帯は誰が承認するか」を握っておきましょう。

リリース可否そのものの考え方は、ソフトウェアリリース延期の判断基準でも整理しています。移行当日のGo/No-Goと共通する視点が多く、あわせて読むと判断の軸が固まります。

切り戻し（ロールバック）の手順とデッドライン

Go/No-Go判定でNo-Goとなった場合、あるいは移行中に重大な問題が起きた場合は、切り戻しに移ります。切り戻しは「失敗」ではなく、事前に設計された正規の選択肢です。

切り戻しを「恥ずかしい撤退」ではなく「計画された安全策」と位置づけることが、冷静な判断につながります。撤退を恥と捉える空気があると、判断が遅れて被害が拡大します。

切り戻し手順の基本

切り戻しは、移行と逆の手順をたどってシステムを元の状態へ戻す作業です。基本の流れは次のとおりです。

• バックアップからデータと設定を移行前の状態へ復元する
• アプリケーションを旧構成へ戻し、旧環境で受付を再開する
• 切り戻し完了後、旧環境が正常に動作することを確認する

切り戻し後も、移行前と同じように動作確認を行います。「戻したから大丈夫」と確認を省くと、切り戻し自体が新たな障害を生むことがあります。

データ差分の扱いに注意する

切り戻しで見落としやすいのが、移行後に発生したデータ差分です。移行後に一部の受付を始めていた場合、その間に入ったデータの扱いを事前に決めておきます。

状況	差分の扱い	事前準備
受付前に切り戻し	差分なし	特になし
受付後に切り戻し	差分を退避・再投入	差分抽出手順を用意
差分の再現が困難	手動での補正が必要	補正手順と担当を決定

差分の扱いを決めていないと、切り戻しで顧客のデータを失うという最悪の事態を招きます。受付を再開するタイミングと、そこから切り戻す場合の手順は、必ずセットで設計してください。

デッドラインを守る

切り戻しにも締め切りがあります。Point of No Returnを過ぎてから切り戻そうとすると、業務開始に間に合わず二次被害を生みます。

• Point of No Returnを過ぎたら、原則として前進のみとし、障害対応モードへ切り替える
• 切り戻すなら、必ずPoint of No Return前に決断する
• 切り戻し発動の権限も、判断責任者に集約しておく

限界点を過ぎたあとに「やはり戻そう」と動き始めるのが、最も危険なパターンです。前進と撤退のどちらを選ぶにせよ、限界点の前に腹を決めることが求められます。

万一、移行後に障害が発生した場合の動き方は、システム障害時の初動対応手順が実務の助けになります。初動の設計まで含めておくと、切り戻し後も慌てずに対応できます。

移行後確認とよくある失敗

移行が完了しても、確認が終わるまでカットオーバーは終わりません。「移行できた」ことと「正常に使える」ことは別だからです。移行後確認の抜けは、翌営業日の障害として跳ね返ってきます。

移行直後は「終わった」という安堵から確認が甘くなりがちです。しかし、業務が本格的に動き出すのは翌営業日です。ユーザーが使い始めてから障害が発覚すると、対応は一気に難しくなります。

移行後に必ず確認する項目

移行後の確認は、システムが「本番の負荷と使われ方で正常に動くか」を見るものです。テスト環境での確認とは別に、本番での疎通を必ず行います。

• 主要な業務導線が本番で正常に動作することを疎通確認した
• 移行データの件数・整合性が期待どおりであることを確認した
• 監視・アラートが正常に稼働し、異常を検知できる状態になっている
• 問い合わせ窓口・運用担当が受付を開始できる体制になっている

データの整合性を丁寧に確かめたい場合は、データ整合性テストの進め方と観点が確認項目の設計に役立ちます。件数だけでなく、関連するデータ間の整合まで見ることが、移行後の隠れた不整合を防ぎます。

よくある失敗と回避策（例）

以下は、現場で繰り返し見られる典型的な失敗を匿名化した例です。自社の移行計画と照らし合わせてみてください。どれも「起きてから気づく」種類の失敗です。

失敗例(匿名)	起きたこと	回避策
時間読み違え	リハーサル未実施で当日に時間切れ	本番同等環境で通しリハーサルを実施
判断者不在	深夜に決裁者と連絡が取れず停滞	決裁者の当日待機を事前に確保
確認スキップ	移行後の疎通確認を省き翌日障害	移行後確認をタイムラインに組込む
差分放置	受付後の切り戻しでデータ消失	差分退避手順を事前に用意
告知不足	停止時刻が伝わらず問い合わせ殺到	具体的な時刻で事前告知

これらの失敗はどれも特別なものではなく、チェックリストと判断基準の欠落という共通点があります。裏を返せば、準備で防げる失敗ばかりです。

ここに挙げた5つは、いずれも技術力の不足ではなく、段取りの不足から生まれています。優秀なエンジニアがそろっていても、判断設計が抜けていれば同じ失敗を繰り返します。

振り返りまで含めてカットオーバー

移行が無事に終わったら、当日の記録をもとに振り返りを行います。実測時間・発生した課題・判断の妥当性を残しておくと、次回の移行計画の精度が上がります。

• 実測したタイムラインと想定との差分を記録する
• 発生したトラブルと対応内容を一覧化する
• 次回に向けた改善点をチェックリストへ反映する

一度作った移行の知見を組織の資産に変えられるかどうかは、この振り返りにかかっています。属人的な経験で終わらせず、次のプロジェクトが使える形で残しましょう。

まとめ｜カットオーバーのチェックリストを味方にする

カットオーバーの成否は、当日の技術力よりも、事前の準備と判断設計で決まります。本記事で示したカットオーバーのチェックリストは、次の要素で構成されていました。

• 事前準備: 移行対象・手順書・バックアップ・関係者調整・告知
• 移行リハーサル: 本番同等環境での通しと所要時間の実測、切り戻しの練習
• 当日タイムライン: 時刻・作業・担当・判定ポイントの一枚化
• 判断基準: Point of No ReturnとGo/No-Go、誰が決めるかの明確化
• 移行後確認: 疎通・整合性・監視・受付、そして振り返り

チェックリストは配布して終わりではなく、リハーサルで実測し、当日の判断基準まで含めて磨き込むことで初めて機能します。

移行の全体設計や品質保証の考え方については、公的機関の資料も参考になります。ソフトウェア開発の実態データはIPAの社会・産業のデジタル変革、テスト用語や技法の標準的な定義はJSTQBの認定資格情報が信頼できる出典です。

少人数のテスト体制で移行当日まで手が回らない、あるいは移行前の検証を第三者の視点で固めたいと感じている場合は、テスト体制の見直しについてお気軽にご相談ください。準備段階から伴走できる体制を整えることが、事故のない本番移行への近道です。

次に読むならこの記事

• PMの品質責任が重いと感じたら｜抱え込まない設計
• リリース判定チェックリスト｜GO/NO-GOで揉めない判断軸
• 品質管理におけるソフトウェアテストの重要性とは

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する