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