社内の業務システムをクラウドへ移行する段取り。現状の棚卸し、移行方式の選び方、切り替え日の決め方、戻し方まで

この記事の結論：社内の業務システムをクラウドへ移行するときは、「棚卸し→移行方式の選択→データの移し方→リハーサル→切り替え日→戻し方」の順に決めます。棚卸しではサーバーの台数よりも、メールの送信、取引先とのファイルのやり取り、接続元のIPアドレスの制限のような「外とのつながり」を書き出すことが大切です。移行方式はシステムごとに選び、移行と作り直しは同時にしません。切り替え日は業務の暦から逆算して選び、当日は「この時刻までに確認が終わらなければ戻す」という判断の時刻を先に決めておきます。

ここでは、社内のサーバーやデータセンターで動いている業務システムを、クラウドへ移すことを考えている会社の担当者と、移行を受け持つ開発者に向けた作業の段取りです。移行方式の分類は AWS の公開資料（AWS Prescriptive Guidance、確認日は2026年10月2日）を参照していますが、考え方はほかのクラウドでも同じです。特定の会社の事例は出てきません。

クラウド移行は6つの段階に分け、段階ごとに決めることを決める

業務システムのクラウド移行は、段階を分けて、それぞれで決めることを決めてから次に進むと、当日の判断が少なくなります。

この順番を崩しやすいのが、「切り替え日を先に決めてしまう」ことです。棚卸しの前に日付が決まると、見つかったつながりを調べる時間がなくなり、当日に動かない機能が出てきます。日付は、リハーサルで止める時間を測ってから決めます。

現状の棚卸しは、サーバーではなく「外とのつながり」を書き出す

棚卸しで書き出すべきは、サーバーの台数や性能よりも、そのシステムが外の何とつながっているかです。サーバーの中身は移せば動きますが、外とのつながりは移した先から同じように届く保証がなく、切り替えた後に初めて気づくことが多いからです。

この表は、システムの担当者だけでは埋まりません。業務の担当者に「毎月・毎週・毎朝、このシステムで何をしているか」を聞くと、定期的な処理や、取引先とのやり取りが出てきます。ログに残っている外への接続先と、聞き取りの結果を突き合わせて、漏れを減らします。

移行方式は、システムごとに7つの選択肢から選ぶ

移行方式は会社全体で一つに決めるのではなく、システムごとに選びます。AWS の移行の手引きでは、移行の方式を「7 Rs」と呼ばれる7つに分けています。

AWS の手引きでは、作り直しは最も複雑で費用のかかる方式とされ、大規模な移行では移行を終えてから作り直すことが勧められています。規模の小さい移行でも、考え方は同じです。移行と作り直しを同時に進めると、不具合が出たときに、原因が移行にあるのか作り直しにあるのかを切り分けられません。

中小企業の業務システムでよく選ぶのは、アプリケーションはそのまま移し、データベースだけを管理されたサービスに替える組み合わせです。データベースの保守とバックアップをクラウドの側に任せられ、アプリケーションの書き換えは接続先の設定程度で済むことが多いからです。

データの移し方は、止められる時間から決める

データの移し方は、業務を何時間止められるかから逆算して選びます。一度に全部を写すなら、写し終わるまで書き込みを止める必要があり、止める時間はデータの量で決まります。

先に全体を写して変更を追いかける方法は、AWS では Database Migration Service（DMS）の「全ロード＋CDC（変更データキャプチャ）」として用意されています。AWS のユーザーガイドには、元のデータベースの変更の記録（トランザクションログ）から変更を集めて反映する仕組みであること、そしてリアルタイムの複製ではなく、遅れは元のデータベースの負荷や回線などで変わることが書かれています。切り替えの直前に、遅れがなくなったことを確かめてから書き込みを止めます。

どの方法でも、写したあとに件数と中身を照合します。テーブルごとの件数、金額の合計、最新の更新日時をそろえて比べ、ずれがあれば原因が分かるまで切り替えに進みません。

リハーサルは2回行い、止める時間を測る

切り替えの手順は、本番と同じ量のデータを使って少なくとも2回リハーサルします。1回目で手順の抜けを見つけ、直した手順を2回目で通し、止める時間を測ります。

リハーサルで見る点を5つ挙げます。

1. 手順書どおりに、上から順に実行できるか：手順書にない作業をした箇所は、手順書に書き足す
2. データを写す時間と、照合にかかる時間：これが当日に業務を止める時間の元になる
3. 棚卸しの表の外とのつながりが、移した先で動くか：メールが届くか、取引先とのファイルの受け渡しが通るか
4. 業務の担当者が、ふだんの操作を一通りできるか：画面を開くだけでなく、登録・修正・帳票の出力まで
5. 戻す手順が動くか：戻すリハーサルもしておく

外とのつながりのうち、取引先の側で接続元のIPアドレスを許可しているものは、移した先のアドレスを前もって取引先に登録してもらう必要があります。相手の作業の日程があるため、リハーサルより前に依頼しておきます。

切り替え日は業務の暦から逆算して選び、当日は判断の時刻を決める

切り替え日は、月末の締め、給与の計算、請求書の発行のような、止められない業務の日を避けて選びます。そのうえで当日は、作業の順番と担当に加えて、「この時刻までに確認が終わらなければ戻す」という判断の時刻を先に決めておきます。

業務の暦で避けたい日の例です。

当日の進行表は、時刻と作業と担当、そして判断の点を1枚にまとめます。時刻は「開始から何時間後」で書いておくと、リハーサルの記録と比べやすくなります。

表の時間は例で、実際の値はリハーサルで測った時間に余裕を足して決めます。切り替えの前の一定期間は、システムへの機能の追加や設定の変更を止めておくと、リハーサルと当日の状態がずれません。

戻し方は「どの時点までなら、どうやって戻すか」を決めておく

戻し方で決めるべきなのは、手順そのものより、「どの時点までなら戻せるか」と「戻すときに、切り替え後に入ったデータをどう扱うか」の2つです。切り替えたあとに新しい環境で業務が進むほど、戻すときに持ち帰るデータが増え、戻すこと自体が難しくなります。

この表のとおり、戻せる期限を「業務の再開から何時間まで」のように決め、期限を過ぎたら新しい環境で直す方針に切り替えます。期限を決めないままだと、不具合が出るたびに戻すかどうかの議論になり、判断が遅れます。

旧環境は、切り替え後もすぐには止めず、書き込みのできない状態で残します。戻す判断の期限を過ぎ、月末の締めのような業務を新しい環境で一巡してから、旧環境にしか残っていないファイルや設定がないかを棚卸しの表と照らし合わせて止めます。

移したあとに残す記録と、保守への引き継ぎ

切り替えが終わったら、新しい環境の構成、外とのつながりの一覧、定期的な処理の一覧を、保守を受け持つ人が読める形で残します。棚卸しの表を「移行後の状態」に書き換えれば、そのまま保守の台帳になります。

移した先のバックアップも、決めた時点の状態に戻せるかまで確かめます。その手順はバックアップの復元テストの記事にまとめています。

移行の段取りで時間をかけるべきなのは、技術の作業よりも、棚卸しと業務の担当者との確認です。

株式会社bundlyzeでは移行の作業に限らず、業務システムの要件の整理から稼働後の保守運用までを受け持ち、AWSでデータ分析の基盤を組む仕事もしています。棚卸しから切り替え、戻し方までの段取りを一緒に組む場合の進め方は、クラウドの構築・移行・運用の支援のページに載せています。

出典（AWSの公式ドキュメント／2026年10月2日に確認）

• AWS Prescriptive Guidance「About the migration strategies」（Guide for AWS large migrations）：7つの移行方式（7 Rs）、作り直しは最も複雑で費用がかかり、移行後に行うことが勧められている点
• AWS Database Migration Service ユーザーガイド「AWS DMS を使用した継続的なレプリケーション用のタスクの作成」：全ロード＋CDC、トランザクションログからの変更の収集、リアルタイムの複製ではない点