カットオーバーとは？本番切替の計画と移行判定会議の基準・切り戻しの決め方

カットオーバーは、旧システムから新システムへ業務を切り替え、新システムで本番運用を始めることを指します。切替の瞬間だけでなく、前後の計画・リハーサル・判定・切替後の監視までを含めて呼ぶ現場が多い言葉です。本記事では、リリースやサービスインとの違い、切替方式の選び方、カットオーバー計画とランブックの作り方を整理します。後半では、移行判定会議（Go/No-Go）の基準を数値で置く方法、切り戻しの決め方、切替後の保証期間の長さまで、発注者が事前に決めておく事項を解説します。

まとめ：カットオーバーは判定基準と切り戻しの期限を事前に合意した計画で成否が決まる

カットオーバーの失敗は、当日の作業ミスより、事前に決めていなかった判断から起きます。どの状態なら切り替えるのか。どの時刻までに問題が解けなければ戻すのか。誰がそれを決めるのか。この3つを判定会議の前に文書で合意しておけば、当日に迷う場面はほとんど残りません。

実務の順番は、①方式を停止許容時間で選ぶ、②ランブックに作業・時刻・担当を書く、③本番と同じ手順でリハーサルを通し時間を計る、④判定会議で重大度別の残件数とデータ照合の結果から可否を決める、⑤切替後は月次締めなど業務の周期を1回通すまで旧システムを残す、です。切替日を先に固定して判定会議を追認の場にする進め方は避けてください。

カットオーバーとは何か｜本番稼働・リリース・サービスインとの違い

カットオーバー（cutover）は、システム開発の最終盤に置かれる工程です。要件定義から受入テストまでを終えた新システムに、実際の業務とデータを移し替えます。

カットオーバーの意味と旧システムから新システムへ移す対象の範囲

切り替える対象はプログラムだけではありません。データ、利用者の接続先、他システムとの連携先、運用手順、問い合わせ窓口まで、業務を動かすものすべてが新しい側へ移ります。AWSの移行ガイダンス「カットオーバー前段階」も、計画で評価する項目として停止時間・利用者の接続・アプリケーションとシステムの依存関係・インフラの変更・運用の変更・テスト計画を挙げています。

データだけを移して終わりにすると、連携先が旧システムを参照し続けたり、夜間バッチが旧サーバーで動き続けたりします。対象範囲は「業務の入口から出口まで」で洗い出すのが原則です。移行全体の進め方はシステム移行の方式と進め方を解説した記事で整理しています。

リリース・本番移行・サービスインとの使い分けと契約書類での書き方

似た言葉は多いものの、指す範囲が少しずつ違います。発注書や工程表で混ぜて使うと、完了の定義がずれる原因になります。

リリースは既存システムへの更新でも使いますが、カットオーバーは「旧の業務を止めて新に移す」意味を含みます。契約書類では「カットオーバー日」を切替作業の完了日とするのか、保証期間の終了日とするのかを明記してください。ここが曖昧だと、支払い条件や瑕疵対応の起算日で揉めます。

カットオーバーの方式｜一斉切替と段階切替を停止許容時間と切り戻しの速さで選ぶ

方式の選択は、計画全体の前提になります。並行稼働を含む3方式の比較は先に挙げたシステム移行の記事に譲り、ここではカットオーバー当日の運び方に直結する差だけを扱います。

一斉切替と段階切替の違い｜AWSが示す切り戻しの速さと手間の差

AWSの「カットオーバーステージ」は、全体を一度に切り替える方式と、利用者や処理の一部から順に移す段階的な方式を比べています。

同ガイダンスは、段階的な方式が業務上重要な本番ワークロードで最も多く採られていると説明しています。ただし、データベースと処理を分けると遅延に耐えられない構成なら、一斉切替しか選べません。判断の順番は「分けて動かせる構成か」が先で、「リスクを下げたいか」はその後です。

カットオーバー計画の作り方｜ランブックに作業・予定時刻・担当を1行ずつ書く

カットオーバー計画は、当日の作業を時刻単位で追える状態にする文書です。AWSは計画とは別に、作業の開始・終了予定時刻、順序、担当を管理するランブック（作業手順書）の作成を勧めています。

カットオーバー計画書に入れる停止時間・依存関係・テスト計画の項目

計画書で最初に決めるのは停止時間です。AWSのガイダンスは、停止枠を超えた場合の業務影響、想定外の事象で修正して前進する余地、失敗時に戻す所要時間の3点を停止時間の検討に含めるよう求めています。

次に依存関係です。切り替えるシステムを呼び出している側を全部書き出します。IPアドレスを直接書いている連携先があると、切替後に接続できません。テスト計画には、機能テスト、切替前後で同じ条件の性能テスト、連携先との接続テスト、切替中と保証期間中のテストを入れます。

当日の5工程｜入力の凍結・最終バックアップ・データ同期・経路切替・検証

AWSのカットオーバーステージは、当日の作業を次の5工程に整理しています。

1. 入力の凍結：旧システムへの新しい取引やデータの流入を止める
2. 最終バックアップ：旧システムの最終状態を保存し、切り戻しに備える
3. データ同期：旧と新の間で最後の差分を同期する
4. 経路の切替：DNSや負荷分散の設定を変え、利用者を新システムへ向ける
5. 検証：移行完了と判断する前に、すべてが動くことを確かめる

ランブックはこの5工程を骨組みにし、各工程を担当者が1人で完了できる粒度まで分けます。Microsoft Learnの「クラウドへの移行を実行する」（2026年10月時点）は、レプリケーションの遅延がゼロになるまで次の工程へ進まないことと、データ照合は件数比較だけでなくチェックサムやハッシュの比較が望ましいことを明記しています。

ランブックの粒度とRACIで作業の担当と判断者を1人ずつ決める書き方

ランブックの各行には、作業内容、予定開始・終了時刻、実施者、確認者、完了の判定方法を書きます。AWSは担当の割り当てにRACI（実行・説明責任・相談・報告）の表を使えると説明しています。

実行者が複数いる行は分割します。説明責任者は1行に1人です。「インフラチーム」のような組織名ではなく個人名で書き、当日不在の場合の代理も決めておきます。切り戻しの判断者だけは、作業の担当とは別の行で明示してください。

移行リハーサルの進め方｜本番と同じ手順を時間を計って通し合格条件を決める

リハーサルは、ランブックが本番で通用するかを確かめる工程です。本番同等の環境とデータ量で、ランブックの順番どおりに作業し、各行の実績時間を記録します。

移行リハーサルで計測する作業所要時間と停止枠に残す余裕の決め方

リハーサルの回数に公的な基準はありません。本記事では、本番と同じデータ量での通しリハーサルを最低2回、うち最後の1回をランブック修正なしで通すことを合格条件の目安として勧めます。1回目は手順の漏れを見つける回、2回目は修正した手順で時間が収まるかを確かめる回です。

所要時間は、停止枠に対して切り戻しの時間を差し引いた残りに収まっているかで判定します。たとえば停止枠が12時間で切り戻しに4時間かかるなら、切替作業と検証は8時間以内に終わる必要があります。リハーサルで8時間ぎりぎりなら、本番では不合格と考えてください。

本番前に試せない連携先の扱い｜リスクと検知方法の計画書への記載

取引先のシステムや外部サービスとの連携は、本番でしか確かめられないことがあります。AWSのガイダンスは、このような場合に想定されるリスク、そのリスクを検知する方法、テストが失敗したときの対処を文書化するよう勧めています。

実務では、本番切替直後に1件だけ実データを流して結果を確認する「初回取引の確認」をランブックに入れます。確認する相手方の担当者と連絡手段も、当日までに決めておきます。

移行判定会議（Go/No-Go）の基準｜重大度別の残件数とデータ照合で可否を決める

移行判定会議は、リハーサルと受入テストの結果をもとに、予定どおり切り替えるかを決める場です。結論を出すのは会議ですが、基準は会議の前に決まっていなければなりません。

移行判定会議の開催時期と出席者｜業務部門の責任者を入れる理由

判定会議は、切替の数日前に1回、直前に最終確認を1回置く2段構えが運びやすい形です。Microsoft Learnは、移行前に各サポートチームの代表と移行計画・検証手順・切り戻し基準を確認する会議を開くよう勧めています。

出席者には、開発会社の責任者と情報システム部門に加え、切替後に新システムで業務を回す部門の責任者を必ず入れます。業務部門が「運用を始められる」と言えない状態で切り替えても、障害が出なくても業務は停止したままです。受入テストの合否基準は受入テストの進め方と合否基準を解説した記事で詳しく扱っています。

Go/No-Go判定基準の例｜重大度別の残件数とデータ照合の合格ライン

判定基準は「問題ないか」ではなく、数えられる形で置きます。次の表は、基準を作るときのひな型です。数値は案件ごとに業務部門と合意して決めます。

データ照合は件数だけでは足りません。件数が合っていても、金額や残高がずれている移行は珍しくないためです。残高の突き合わせ方はERP導入の失敗事例と残高突合の手順をまとめた記事で具体例を示しています。

移行判定で条件付きGoを出してよい場面と延期を選ぶべき場面の線引き

基準を一部満たさないまま切り替える「条件付きGo」は、回避策が手作業で回り、その手作業の担当者と期間が決まっている場合に限って認めます。帳票の体裁崩れや、月1回しか使わない画面の不具合が典型です。

一方、データ照合の不一致と、切り戻し手順の未検証は延期にします。この2つは切替後に発覚すると、旧システムにも戻れず新システムも信用できない状態になるためです。延期の費用は確かに発生しますが、本番データが壊れた後の復旧費用と比べれば小さく済みます。

切り戻し（ロールバック）の決め方｜発動する期限と決断者を当日前に固定する

切り戻しは、切替を中止して旧システムでの業務に戻すことです。計画書に手順を書くだけでは使えません。いつ、誰が、どの条件で決めるかまで固定して初めて機能します。

切り戻しを発動するチェックポイントと決断者を1人に決める理由

AWSは切り戻し計画に、事前に定めた条件を満たしたら切り戻しを発動するチェックポイント、データの扱いを含む切り戻しの戦略、修正して前進するか戻すかを決める窓口の3つを含めるよう勧めています。

チェックポイントは時刻で置きます。「データ同期の完了が午前2時を過ぎたら戻す」のように書けば、当日の議論が要りません。決断者は1人に絞ります。複数人の合議にすると、問題が起きている最中に判断が遅れ、切り戻しの時間まで食いつぶすためです。

切替後に入力された新規データがある場合の切り戻し方と3つの選択肢

新データが無い段階の切り戻しは、旧システムを再開して接続先を戻すだけで済みます。難しいのは、新システムで取引が始まった後に戻す場合です。AWSはこの場面の選択肢として、旧環境とは別の戻し先へデータを複製し続けるフェイルフォワード、旧と新の両方へ書き込む二重書き込み、バックアップからの復元を挙げています。

どれを選ぶかは、切替後に何時間分の取引を戻せる必要があるかで決まります。バックアップからの復元を選ぶなら、復元にかかる時間を本番以外の環境で事前に計っておくことを同ガイダンスは勧めています。計っていない復元手順は、切り戻し手順として数えないでください。

カットオーバー後の保証期間｜監視の範囲と旧システムを止める時期を業務周期で決める

切替作業が終わっても、カットオーバーは完了していません。新システムが業務の周期を一巡し、問題が出ないことを確かめるまでが範囲です。

切替直後24〜48時間の監視項目とダッシュボードに出す業務指標

Microsoft Learnは、切替後の最初の24〜48時間、システム性能、エラー率、利用者のアクセス状況を監視するよう求めています。AWSの「カットオーバー後の段階」は、到達可能性・可用性・セキュリティ・トラフィックの傾向をダッシュボードに出し、関係者と見る指標を決めておくよう勧めています。

業務側の指標も並べます。受注件数、出荷件数、問い合わせ件数を旧システム時代の同じ曜日と比べると、エラーにならない不具合を見つけられます。

保証期間は1日〜1週間が目安でも月次や四半期の処理がある業務では足りない

AWSは、移行チームが問題に対応する保証期間を通常1日から1週間と説明しつつ、四半期ごとのバッチがあるアプリケーションでは1週間では足りない場合があると注記しています。

基準は業務の周期です。月次締めのある会計・販売管理なら、最初の月次締めが終わるまでを保証期間に含めます。Microsoft Learnも、問題が許容時間内に解決しない場合に戻れるよう、安定化期間中は旧環境を残すよう勧めています。旧システムの停止と契約解除は、最初の月次締めと照合が通った後に決めてください。保守契約の期限が先に来る場合は、切替日をずらすか延長費用を計画に入れます。

カットオーバーで失敗する発注者の判断パターンと開発会社に任せる範囲

失敗の多くは技術ではなく、発注者側の段取りから起きます。代表的なパターンを、起きやすい順に挙げます。

切替日を先に固定して判定会議を追認の場にしてしまう失敗パターン

最も多いのは、決算期や旧システムの保守期限から切替日を先に決め、判定会議がその日程を追認するだけになるケースです。基準を満たしていなくても「延期できない」が前提になり、条件付きGoが積み重なります。

切替日の制約があるなら、その日から逆算してリハーサルの最終日と延期した場合の代替日を計画時点で置いてください。延期の選択肢が無い計画は、判定会議を開いても判定になりません。基幹システムの切替当日の障害が業績予想の修正まで広がった事例は、先に挙げたERP失敗事例の記事で経緯を確認できます。

業務部門が切替準備に参加せず運用手順と問い合わせ窓口が空く失敗

次に多いのが、情報システム部門と開発会社だけで準備を進め、業務部門が切替当日に初めて新しい画面を触るケースです。操作手順書が現場の業務と合っていない、問い合わせ先が決まっていない、といった問題は障害監視では見つかりません。

業務部門の担当者をリハーサルに1回は参加させ、切替後1週間の問い合わせ窓口と回答期限を決めておきます。

開発会社に任せてよい作業と発注者が手放してはいけない判断の線引き

ランブックの作成、リハーサルの実施、データ照合の仕組み作り、切替当日の作業は開発会社に任せて構いません。一方で、判定基準の数値、条件付きGoの承認、切り戻しの最終判断、旧システムを止める時期は、業務の責任を負う発注者が決めます。

発注者側に移行の経験者がいない場合は、計画と判定の設計から外部の支援を入れる方法があります。一創のシステムマイグレーション・リプレイスでは、現行システムの調査から移行計画、リハーサル、切替後の安定化までを支援しています。

よくある質問

カットオーバーについて、発注者からよく寄せられる質問をまとめました。

カットオーバーは土日や夜間に行うべきですか？

利用者が最も少ない時間帯が基本ですが、それだけで決めると失敗します。AWSのガイダンスも、利用者の少なさと、問題が起きたときに対応できる支援チームがその時間に揃うかを比べて決めるよう説明しています。取引先との連携がある業務なら、相手方の担当者が連絡を受けられる時間かも確かめてください。土日に切り替える場合は、月曜朝の業務開始を最初の本番確認と位置づけ、その時間帯に開発会社の担当者を待機させる計画にします。

カットオーバーの延期はどの時点まで判断できますか？

原則は、旧システムへの入力を止める前までです。入力を止めた後でも、新システムで取引が始まる前なら旧システムを再開して戻せます。新システムで取引が始まった後は、切り戻しにデータの扱いが加わり、判断の重さが変わるため、慎重な検討が必要です。そのため最終判定会議は入力凍結の直前に置き、延期を決めた場合の利用者への連絡文面も事前に用意しておくと、当日の混乱を抑えられます。

運用テストとカットオーバーはどちらが先ですか？

運用テストが先です。運用テストは、本番に近い環境で実際の運用手順やバッチ、障害時の連絡体制が回るかを確かめる工程で、その結果がカットオーバーの判定会議の材料になります。順番としては、受入テスト、運用テスト、移行リハーサル、移行判定会議、カットオーバー、保証期間と進むのが一般的です。運用テストを省くと、切替後に夜間バッチや帳票出力の手順で詰まる確率が上がります。

カットオーバー後に不具合が見つかったら開発会社に無償で直してもらえますか？

契約の内容によります。請負契約であれば、仕様と合わない不具合は契約不適合として修補を求められるのが一般的ですが、通知期間や範囲は契約書の条文で決まります。カットオーバー日と検収日、保証期間の起算日が同じとは限らないため、契約時に3つの日付の関係を確認してください。仕様にない要望や業務手順の変更は、不具合ではなく追加開発として扱われます。

小規模なシステムでもカットオーバー計画は必要ですか？

必要です。ただし文書の量は規模に合わせて調整してよいものです。利用者が数十人の社内システムでも、データを移す順番、切り戻しの判断時刻と判断者、切替後に確認する業務の3点は1枚のシートに書いておきます。小規模な案件ほど担当者が1人で作業と判断を兼ねがちで、問題が起きたときに戻す決断が遅れる傾向です。判断者だけは作業者と別の人にしておくと、規模に関係なく失敗を減らせます。

関連記事

• システム開発の流れとは？工程の全体像と各フェーズのポイントをわかりやすく解説：カットオーバーが開発工程全体のどこに位置するかを確認できます。
• クラウド移行のセキュリティ｜移送・並行稼働・切り替え直後に穴が空く工程と対策設計：切替直後に起きやすいセキュリティ上の抜けを工程別に整理しています。
• 購買管理システムのリプレイス｜刷新を決める条件とデータ移行・切替の進め方：業務システムのリプレイスで切替をどう進めるかの具体例です。
• クラウドデータ移行の手順とは?移行ツール・整合性検証・大容量転送の実務を実装者向けに解説：データ照合や大容量転送を実装の側から解説しています。