AWS移行で「方式」より先に決めるべき5つのこと

クラウド移行の相談は、たいてい「リホストがいいのか、作り直すべきか」という方式の話から始まります。しかし、ホストマシンからの基盤移行やPOSシステムの移行を担当してきた経験から言うと、方式の議論から入ったプロジェクトは高い確率で手戻りが起きます。方式は「制約が決まれば自動的に絞られる」ものだからです。ここでは、方式やツールの前に確定させておくべき5項目を整理します。

01停止許容時間と切替ウィンドウ

最初に決めるのは「何分（何時間）なら止めてよいか」です。これが数時間なのか、数分なのか、実質ゼロなのかで、取れる方式がまったく変わります。夜間バッチの終了から翌朝の業務開始までしか窓がないシステムと、週末にまとめて止められるシステムでは、同じ「移行」でも別物です。

ポイントは、システム単位ではなく業務単位で決めることです。「サーバは止められるが、店舗のレジは止められない」というケースでは、止められない業務側から逆算して切替手順を組みます。

02切り戻し（ロールバック）の条件

「何が起きたら、誰の判断で、どの手順で戻すか」を切替前に決めておきます。切り戻しの判断基準が曖昧だと、当日トラブルが起きたときに「もう少し粘るか、戻すか」の議論で時間を溶かし、結果的に停止許容時間を超過します。

• 切り戻しを発動する具体的な条件（例：切替開始からN時間で疎通確認が完了しない）
• 判断者を一人に決めておく（合議にしない）
• 切り戻し手順そのものもリハーサルしておく

切り戻せる設計になっているかどうかは、方式選定にも影響します。データを一方向にしか流せない移行は、それだけでリスクの取り方が変わります。

03アカウント設計と責任分界

移行「先」の器を先に決めます。具体的には、AWSアカウントをどう分割するか（本番・検証・ログ集約など）、rootアカウントと請求を誰が管理するか、お客様と支援会社のどちらが何に責任を持つか、です。

ここを後回しにして「とりあえず1アカウントで」始めると、本番稼働後にアカウント分割というもう一度の移行が発生します。最初からOrganizationsを前提に、小さくても分割された構成で始める方が、結果的に安くつきます。

04移行方式の使い分け

ここまで決まって、はじめて方式の議論が意味を持ちます。大まかには、そのまま持っていくリホスト、OSやDBだけ載せ替えるリプラットフォーム、作り直すリファクタリングの3択ですが、システム一式を単一の方式で移す必要はありません。

実務では「基幹部分はリホストで先に移し、周辺システムは段階的に作り替える」といった組み合わせが大半です。止められないシステムほど、一度に全部を動かさず、切替単位を小さく刻むことがリスク管理になります。移行の順番は、依存関係の棚卸しから機械的に導くのが基本です。

05運用の引き継ぎ形

移行プロジェクトのゴールを「切替完了」に置くと、翌月から運用が回らなくなります。ゴールは「新環境で運用が回っている状態」です。そのために、監視項目と通知先、変更申請のフロー、障害時の一次対応手順を、移行の成果物として最初から計画に含めます。

誰が運用するのか（内製か、委託か、ハイブリッドか）によって、作るべき手順書の粒度も変わります。ここが決まっていないと、手順書が「書いたけれど誰も使わない」文書になりがちです。

—まとめ

5項目に共通するのは、いずれも「技術選定ではなく合意事項」だという点です。停止許容時間、切り戻し条件、責任分界、切替単位、運用体制。この5つが文書として固まっていれば、方式とツールの選定は驚くほど短時間で終わります。逆に、ここが曖昧なまま進んだ移行は、方式が何であれ苦しくなります。