LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

システム移行のカットオーバー計画とは、本番切替を成功させる実行計画

システム移行のカットオーバー計画とは、新システムへの本番切替を滞りなく完了させるために、移行方式の選定からリハーサル、切替当日の判定基準、切り戻し手順までを事前に定める実行計画を指します^*1。AWSはカットオーバーに使える時間が短くなるほど複雑さとリスクが増すと説明しています^*1。

カットオーバーは移行プロジェクトの最終工程に位置し、設計・構築・テストの積み重ねが問われる瞬間です。カットオーバーに必要な時間や複雑さ、リスクの大きさは、業務要件や技術構成、リスク許容度によって変わるとAWSは整理しています^*1。ダウンタイムの許容幅が狭い基幹システムほど、切替の難度は高まる傾向にあります^*1。

カットオーバーという工程そのものは切替の瞬間を指しますが、実務で問われるのはその前後を含めた計画全体です。国内ではIPA/SECが「システム再構築を成功に導くユーザガイド」を公開し、システム化計画の策定を支援しています^*7。事前準備(pre-cutover)、切替実施(cutover)、切替後の検証という3段階を通してリスクを段階的に減らす進め方が実務上の基本になります^*1*3。次章以降はこの3段階に沿って計画のポイントを整理します。

移行方式の選択が計画の土台となる——一括移行・段階移行・並行稼働

カットオーバー計画の内容は、採用する移行方式によって大きく変わります。AWSは移行アプローチを大きく「一括切替(all-at-once)」と「段階的切替(phased)」の2つに整理しています^*3。

一括移行は、DNSの切替やロードバランサーの設定変更などによって、対象システムを一度にすべて新環境へ切り替える方式です^*3。ホスト名の重複やライセンス認証の制約で新旧環境を同時に稼働させられない場合に適した方式ですが、切替時点で性能と機能の両面を検証しておく必要があります^*3。

段階移行は、サーバーやサービスの一部を新環境に切り替え、残りは旧環境に置いたまま、負荷分散やDNSポリシーでトラフィックを振り分ける方式です^*3。影響を受ける利用者を絞り込みやすく、問題を検知した際も新旧の比率を調整しながら切り戻せる点が特徴だと言えます^*3。AWSは、開発・テスト環境には一括移行が向き、事業継続性が重視される本番ワークロードには段階移行が採用されやすいと整理しています^*3。

並行稼働(新旧システムを一定期間同時に稼働させ、新システムの安定を確認したうえで旧システムを停止する進め方)を組み合わせるケースもあります。段階移行や並行稼働を選ぶほど検証の手間は増えますが、切替に伴う業務影響を抑えやすくなるという関係にあります。

いずれの方式でも、移行方式の選定はrehost(既存環境のまま移す方式)やreplatform(一部を最適化して移す方式)といった移行戦略の選び方とも連動します^*4。移行方式を決めたら、次はカットオーバー計画に落とし込む具体的な要素を整理します。

カットオーバー計画に必須の要素——ダウンタイム設計・依存関係整理・テスト計画

AWSは事前準備(pre-cutover)の段階で、計画の遅延・作業のやり直し・想定外の停止・データ損失・性能劣化といったリスクを減らすために、カットオーバー計画とカットオーバーワークブック(作業項目・担当者・実施時刻をまとめた一覧表)の作成、そしてリハーサルを勧めています^*2。

計画に含めるべき項目として、AWSは次の点を挙げています^*2。

1. 許容できるダウンタイムの範囲(超過時の事業影響、想定外事態への対応、切り戻しにかかる時間を含む)^*2
2. 利用者の接続経路とアプリケーション・システム間の依存関係^*2
3. インフラ変更と運用変更の内容^*2
4. 機能テスト・性能テスト・依存システムとの連携テストを含むテスト計画^*2
5. タスクの定義と所要時間、担当者、実施順序^*2

この5点のうち、ダウンタイムの許容範囲は特に重要な検討事項です。割り当てたダウンタイムを超過した場合の売上や信頼への影響、予期しない事態への対応(fix forward)、切り戻しに要する時間を、いずれも事前に評価すべきだとAWSは述べています^*2。この評価を怠ったまま切替に踏み切ると、想定外の長時間停止に至るおそれがあります^*2。

これらの項目を整理した実行計画はランブック(cutover runbook。作業項目・開始終了時刻・実施順序・担当者を一覧にまとめた実行手順書)としてまとめます^*2*5。責任分担を明確にするRACI(Responsible・Accountable・Consulted・Informedの頭文字を取った役割分担表)を使うと、誰が何を担うかを可視化できます^*2。

移行リハーサルとデータ移行検証で本番前に問題を洗い出す

カットオーバー当日の作業内容は、AWSのガイドで概ね5つの局面に整理されています^*3。データの取り込み停止(ingestion freeze)、旧環境の最終バックアップ、新旧環境間の最終データ同期、利用者を新環境へ向けるルーティング変更、そして切替後の動作確認です^*3。

データの整合性を重視する場合は、切替直前に旧環境のデータベースをロックし、新規のトランザクションを止めたうえで最終同期を済ませる進め方になります^*3。ロックする時間が長いほどダウンタイムは延びるため、整合性と停止時間のバランスを事前に検討する必要があります^*3。

この一連の流れを本番前に試すのが移行リハーサルです。切替前のテストとして、機能テストと性能テストを済ませておくことをAWSは推奨しています^*3。切替前の環境は本番トラフィックを受けていないため、この段階のテストは業務に影響を与えずに実施できます^*3。

他システムとの依存関係によって、本番前にはどうしても検証しきれない項目も残ります^*3。検証できないリスクについては内容と検知方法、対応方針をあらかじめ文書化しておくようAWSは勧めています^*3。切替直前には運用準備状況の確認(operational readiness review。テストの網羅性、監視体制、関係者の理解度を点検する工程)も欠かせません^*3。

切替当日の実施体制とGo/No-Go判定基準

体制表(RACI)で役割を明確にする

カットオーバー当日は、複数のチームが同時に動きます。カットオーバーランブックを使い、開始・終了予定時刻や実施順序、担当者を移行チーム内で追跡できる状態にしておくことをAWSは推奨しています^*2*5。ステークホルダー間の連携を事前に整えておくことで、切替中の混乱を抑えられるという整理です^*2。

切替作業を自動化できる部分は自動化し、インフラ構築にはテンプレートを、回帰テストには自動化されたテストスクリプトを使うようAWSは勧めています^*5。切替のような負荷の高い作業中は人的ミスが生じやすいためです^*5。この指摘は、切替を人手だけで進める体制のリスクを示すものと言えるでしょう。

Go/No-Go判定は事前に基準を握っておく

切替を実行するか中止するかの判断(Go/No-Go判定)は、当日その場で決めるものではありません。Microsoft Learnのクラウド導入ガイドは、切替の失敗と見なす条件(ヘルスチェックの失敗、性能低下、セキュリティ上の問題、目標値の未達など)を、業務部門・システム所有者・運用チームと事前に合意しておくべきだとしています^*6。

あわせて、CPU使用率の上限や応答時間のしきい値、エラー率といった切り戻しを発動する具体的な条件を計画に含めておくと、緊急時の判断がぶれにくくなります^*6。切替の成功基準(性能指標や機能検証、利用者受け入れ基準など)も、実施前にあらかじめ定義しておく点が推奨されています^*6。

切り戻し(ロールバック)計画をあらかじめ用意する

移行の切り戻しが必要になる場面は起こり得ます。切替中にあらかじめ定めた基準を満たした場合に切り戻しを発動するチェックポイント、切り戻しの具体的な手順、そして「先に進めるか戻すか」を決める責任者をあらかじめ決めておくようAWSは勧めています^*3。

データが変更される前の切り戻しであれば、旧環境のインスタンスを再開し、ロードバランサーやDNSの設定を戻すだけで対応できるとAWSは整理しています^*3。しかし切替後にすでに新環境で新しいトランザクションを受け付けていた場合は、そのデータを旧環境へ戻す作業が必要になり、対応は複雑になります^*3。

この複雑な切り戻しへの備えとして、AWSは3つの方式を挙げています^*3。新環境から旧環境へデータを複製しておくフェイルフォワード方式、新旧両方への書き込みを許容するデュアルライト方式、そして本番以外の環境で事前にバックアップと復元の所要時間を検証しておく方式です^*3。どの方式を選ぶかによって、切り戻しにかかる時間と準備の工数は変わってきます。

切り戻し手順は、リハーサルの段階で実際に動かして確認しておく必要があります。Microsoft Learnのガイドも、切り戻し手順を検証環境で模擬実行し、権限や依存関係の不備を見つけたうえで、安定した既知の状態に戻せることを確認するよう述べています^*6。

内製と外注の判断軸——カットオーバー計画をどこまで委託するか

カットオーバー計画そのものの型は公開されていますが、実際に運用するには複数領域の知識と実務経験が必要です。ダウンタイムの許容範囲を業務影響から見積もる力、依存関係を洗い出す調査力、ランブックの作成と運用、Go/No-Go判定基準の設計、切り戻し手順の検証など、対応範囲は移行の設計から本番切替までの複数フェーズにわたります^*2*5。

内製で対応する場合、既存の運用担当者が通常業務と並行してこれらを担うことになります。移行対象のシステム数が多い、あるいはAuto Scalingやコンテナ基盤のような複雑な構成が絡む場合ほど、検証と体制構築に割ける時間は限られやすくなります。

専門パートナーに依頼する場合は、依頼範囲の広さが選定の分かれ目になります。移行方式の検討からリハーサルの計画・実施、当日の体制構築、切り戻し手順の検証までを一括して依頼できるかどうかが実務上の判断材料です。負荷の高い切替作業では人的ミスが生じやすいとAWSは指摘しており^*5、当日の実施体制を専門家に委ねることで、そのリスクを抑えられるという見方もできます。

。移行対象システムの規模や依存関係の複雑さによって、内製と外注をどこまで組み合わせるかは変わってきます。現状の移行計画を診断したうえで、委託範囲を検討することが実務的です。

まとめ：システム移行のカットオーバー計画で押さえる3つの判断軸

本稿ではシステム移行のカットオーバー計画について、AWSやMicrosoftの公式情報をもとに整理しました。要点は3つに集約できます。第一に、移行方式には一括移行と段階移行があり、事業継続性を重視するほど段階移行や並行稼働が選ばれやすい傾向があります^*3。第二に、カットオーバー計画にはダウンタイムの許容範囲・依存関係・テスト計画・体制・ランブックという要素が欠かせず、Go/No-Go判定基準と切り戻し手順は実施前に合意しておく必要があります^*2*6。第三に、対応範囲は移行設計から本番切替までの複数フェーズにわたり、システムの規模や複雑さに応じて内製と外注の組み合わせを検討することが判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：AWS「Overview of the cutover phase」（AWS Prescriptive Guidance）（https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/overview-cutover-phase.html）
2. *2　出典：AWS「Pre-cutover stage」（AWS Prescriptive Guidance）（https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/pre-cutover-stage.html）
3. *3　出典：AWS「Cutover stage」（AWS Prescriptive Guidance）（https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html）
4. *4　出典：AWS「About the migration strategies」（AWS Prescriptive Guidance, Large migration guide）（https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html）
5. *5　出典：AWS「Application migration process」（AWS Prescriptive Guidance, Creating a cutover runbook for application migration）（https://docs.aws.amazon.com/prescriptive-guidance/latest/cutover-runbook/app-migration.html）
6. *6　出典：Microsoft「Plan your migration」（Cloud Adoption Framework for Azure、Microsoft Learn、2025年8月更新）（https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migration）
7. *7　出典：IPA/SEC「システム再構築を成功に導くユーザガイド　第2版」（2018年2月）（https://www.ipa.go.jp/archive/publish/secbooks20180223.html）

Tweet