先に要点
システム開発やサーバー移行の話で、カットオーバーはいつですか カットオーバー後に確認してください という言い方がよく出ます。
ただ、初心者には 公開日 リリース 移行日 と何が違うのか分かりにくい言葉でもあります。
現場では、カットオーバーを単に 公開する日 くらいに軽く扱うと危険です。
本当に見るべきなのは、どの時点で旧環境から新環境へ本番利用を切り替えるのか、その前後で何を止めて何を確認するのかです。
この記事では、カットオーバー とは何かを、本番切り替えの意味、リリースや移行との違い、事前準備、当日確認、切り戻し判断の観点から整理します。
DNS 切り替え後の確認項目を先に一覧で見たい場合は、DNS切り替え後に確認すること｜Web・メール・SSLのチェックリスト もつながりやすいです。ロールバック と 切り戻し の言い方や使い分けが気になる場合は、ロールバックとは？切り戻しとの違いと実務での使い分けを整理 もあわせて読むとつながりやすいです。切り替え方式そのものを見たい場合は、ブルーグリーンデプロイとは？切り戻ししやすい理由と向いているケースを整理 も関連します。切り替え当日に一時停止の案内を出すべきか迷う場合は、メンテナンス画面はなぜ必要？切り替え作業での使いどころと出し方の基本 もあわせて読むと判断しやすいです。受託案件で本番作業に誰が立ち会うべきか、クライアント側とベンダー側の役割まで整理したい場合は、本番作業の立ち会いは誰が必要？受託案件で決めたい役割分担と連絡体制 もあわせて読むと実務で使いやすいです。
この記事では、2026年4月22日時点で AWS Prescriptive Guidance の cutover phase、Microsoft Learn の cutover migration、IPA の公開資料中のカットオーバー記述を確認しながら整理しています。ここでは特定製品の手順書ではなく、システム移行や本番切り替えで共通して押さえたい基本としてまとめます。
結論：カットオーバーは「本番を新環境へ渡す瞬間とその前後の実務」
一言でいうと、カットオーバーは 旧環境から新環境へ本番運用を切り替えること です。
だから、開発完了や納品完了と同じではありません。
実務では、次のようなものが一緒に乗ります。
データ
データ移行
旧環境のデータを新環境へ移します。
公開
アプリ公開と切り替え
アプリ公開、DNS や接続先の切り替えです。
業務
停止時間の調整
業務停止やメンテナンス時間の調整です。
判断
確認と切り戻し判断
動作確認と、切り戻し判断です。
つまり、カットオーバーは 最後のスイッチを入れる作業 というより、本番を安全に渡すための一連の段取り です。
カットオーバーと似た言葉の違い
ここは混ざりやすいので、最初に分けておくと実務で楽です。
| 言葉 | 意味 | 実務での違い |
|---|---|---|
| リリース | 新機能や新バージョンを出すこと | アプリ更新全般を指しやすい |
| 移行 | 旧環境から新環境へデータや機能を移すこと | 準備期間を含む広い言葉 |
| カットオーバー | 本番利用先を新環境へ切り替えること | 当日作業、確認、切り戻し判断が重い |
| 検収 | 納品物を受け入れるか確認すること | 契約上の完了確認に近い |
たとえば、移行作業は1か月かけて進めても、カットオーバー自体は土曜深夜の2時間だけ、ということがあります。
この違いを分けて話さないと、準備期間と切り替え当日の話が混ざります。
どんな場面でカットオーバーが出てくるか
カットオーバーという言葉は、次のような場面でよく出ます。
サーバー
旧サーバーから新サーバーへ
旧サーバーから新サーバーへ移すときです。
業務
システムの刷新
基幹システムや業務システムを新しくするときです。
サイト
WordPress の移設
WordPress サイトを別環境へ移すときです。
メール・認証や大改修
メールシステムや認証基盤を切り替えるとき、大きな改修後に本番を新構成へ切り替えるときです。
特に、旧環境と新環境がしばらく並行する案件では、どこで「本番はこちらです」と決めるかが重要になります。
カットオーバーが難しくなりやすい理由
技術的には動いていても、カットオーバーで失敗することはあります。
理由は、コードだけでなく運用面が一気に乗るからです。
よくある難所は次です。
データ
どこで止めて移すか
最新データをどこで止めて移すか。
判定
誰が完了判定を出すか
完了を宣言する人が決まっているか。
反映
切り替えの反映差
DNS や接続先切り替えの反映差。
周知
利用者への周知
止まることを利用者へ伝えます。
旧環境
いつ止めるか
旧環境をいつ止めるか。
戻し
どこまで戻すか
問題が出たときにどこまで戻すか。
AWS の cutover phase でも、カットオーバー前の準備と移行後の検証が重視されています。
Microsoft Learn の cutover migration でも、切り替え前に環境変更や前提準備を済ませる必要があることが案内されています。
カットオーバー前に決めておきたいこと
実務では、当日より前に次をそろえておくとかなり事故が減ります。
ここが曖昧だと、当日に まだ確認していない 誰が止めると言うのか分からない が起きやすいです。
カットオーバー当日の基本的な流れ
案件ごとに違いますが、基本形はだいたい次の流れです。
問い合わせフォーム、管理画面、メール通知、SSL エラー、旧サーバーアクセス残りは最低限見たいです。
カットオーバー後に確認したいこと
切り替えた瞬間より、そのあとが大事です。
よくある確認項目は次です。
表示
ページが見えるか
トップページと主要下層ページが見えるか。
操作
ログイン・管理画面
ログインや管理画面が使えるか。
送信
フォームと通知メール
フォーム送信や通知メールが届くか。
証明書
暗号化のエラー
旧環境
通信の残り
旧環境へまだ通信が残っていないか。
定期処理
バッチ
バッチや定期処理が動いているか。
このあたりは、DNS切り替え後に確認すること｜Web・メール・SSLのチェックリスト とかなり相性がよいです。
切り戻しは「失敗扱い」ではなく設計の一部
ここは大事です。
切り戻しを考えると縁起が悪い、と感じることがありますが、実務ではむしろ逆です。
切り戻し条件を決めておかないと、問題が出ても「このまま直すか」「戻すか」の判断が遅れます。その結果、利用者影響だけ長く続くことがあります。
たとえば次のような条件は先に決めたいです。
時間
ログイン不可が続いたら
ログイン不可が何分続いたら戻すか。
業務
決済・受注が通らない
決済や受注が通らない場合は即戻すか。
データ
データ不整合
データ不整合が出たら続行しないか。
連絡
戻したあと
戻したあとに誰へ連絡するか。
よくある失敗
失敗1
「公開できた」だけで完了にする
トップページだけ見えて完了にすると、フォームやメール、管理画面だけ不具合が残ることがあります。
失敗2
旧環境を早く止めすぎる
切り替え直後は、旧環境へのアクセスやメールが少し残ることがあります。すぐ止めると、追跡や切り戻しが難しくなります。
失敗3
業務側の確認者が決まっていない
技術側は問題なしでも、業務側の必須確認が終わっていないことがあります。ここが曖昧だと、完了宣言がぶれます。
カットオーバーのよくある質問
Q. カットオーバーとリリースの違いは？
A. リリースは 新機能を世に出すこと 全般、カットオーバーは 旧から新への切り替え時点 を指します。新規プロジェクトの公開ならリリース、システム移行ならカットオーバー、という使い分けです。
Q. カットオーバーの時間帯は？
A. 業務影響が最も小さい時間が原則。一般 Web なら深夜、平日業務システムなら週末や祝日前夜、メディアサイトなら新聞配達前の早朝、など業務特性に合わせて選びます。
Q. カットオーバー失敗時のロールバックは？
A. 事前にロールバック計画を文書化、復旧時間目標を決定、データ移行のロールバック可否を確認、関係者の判断権限を明示、までを準備します。引き返せない作業 は最後の最後にやります。
Q. カットオーバー前夜にやるべきことは？
A. 全関係者の到達確認、緊急連絡網確認、本番に近いリハーサル、バックアップ取得、旧環境のクローズ計画確認、カットオーバーチェックリスト最終確認、です。
Q. データ移行はカットオーバーに含まれますか？
A. 含まれます。多くの場合 事前にデータをコピー → カットオーバー時に差分のみ移行 の構成です。データ量が多いと数時間〜数日かかるので、データ凍結時間 をどう確保するかが重要です。
Q. 完了判定は誰がしますか？
A. 業務責任者 + 開発責任者 + 運用責任者 の3者合意が望ましいです。業務的に問題なし + 技術的に問題なし + 運用継続できる を全員が確認してから完了宣言します。
Q. カットオーバー後の様子見期間は？
A. ハイパーケア期間 として2〜4週間、開発側が手厚いサポートをするのが定番です。期間中の対応工数は契約に含めるか、別途見積もりするかを事前に決めておきます。
まとめ
カットオーバー は、単なる公開日ではなく、旧環境から新環境へ本番を渡すタイミングとその前後の実務を指す言葉です。
技術だけでなく、移行、連絡、確認、切り戻し判断まで含むので、最後の工程ほど段取りが重要になります。
初心者向けには、本番を新しい環境へ正式に切り替えること と理解すると入りやすいです。
そのうえで、何を切り替えるのか、誰が確認するのか、戻す条件は何かまで決めておくと、かなり事故を減らしやすくなります。
参考リンク
- AWS Prescriptive Guidance: Cutover phase
- Microsoft Learn: Migrate email to Exchange Online using the Exchange cutover method
- IPA: ITプロジェクトの「見える化」