社内のサーバー室に置いた業務システムの保守期限が近づき、「そろそろAWSなどのクラウドへ移すべきですか」と相談を受ける場面が増えています。ところが、移行にいくらかかるのか、移して本当に得なのか、止まったりしないのかが分からず、判断が止まってしまう方は少なくありません。
「オンプレミスの業務システムをAWSに移行すべきか、費用とリスクの判断ができない」
先に結論をお伝えします。「移行すべきか」の答えは、システムごとに違います。クラウドに移す・作り直す・そのまま使う・やめる、の4択以上があり、AWS自身も移行方法を7種類に整理しています。判断の材料は「保守期限」「今の年間コスト」「システムの寿命」「止められる時間」「社内の運用体制」の5つです。この記事では、この5つの視点と、開発会社に聞くべき質問をまとめます。
なお、本記事の情報は2026年10月時点のものです。費用の具体額は環境で大きく変わるため、金額の目安は載せていません。
「オンプレミス」と「クラウド移行」を、まず言い換える
オンプレミスとは、自社（またはデータセンター）に置いたサーバーで、システムを動かす形のことです。サーバーは買い取りで、故障や古くなったときの入れ替えも自分たちで行います。
クラウド（ここではAWS）は、サーバーを買う代わりに、使った分だけ借りる形です。機器の購入と入れ替えは不要になりますが、毎月の利用料がかかり続け、設定や運用の責任の一部は利用者側に残ります。
つまり「移行」は、お金の払い方と、運用の分担を変える話でもあります。ここを押さえておくと、見積もりの読み方が変わります。
「移行する」には7種類ある｜AWSが整理した移行の選択肢
AWSの公式ガイド（AWS Prescriptive Guidance）は、アプリケーションを移す方法を「7つのR」として整理しています。発注者として、名前と意味だけ知っておくと、提案の違いが見えてきます。
📰 出典：About the migration strategies – AWS Prescriptive Guidance
| 選択肢 | 一言でいうと | 発注者目線のポイント |
|---|---|---|
| Rehost（そのまま移す） | 今のシステムを変えずにクラウドのサーバーへ載せ替える | 作業は少なめ。ただし、クラウドの利点は活かしにくい |
| Relocate（仮想環境ごと移す） | 仮想化したサーバー環境をまとめて移す | 条件が合う場合に早い。向くかは環境次第 |
| Replatform（一部を載せ替える） | データベースだけクラウドの標準サービスにするなど、少しだけ手を入れる | 運用の手間が減りやすい。確認と試験の作業は増える |
| Refactor（作り直す） | クラウド向けに設計から見直す | 費用・期間は最大。得られるものも最大になりうる |
| Repurchase（買い替える） | 既製のSaaSなどに置き換える | 業務のやり方をSaaSに合わせる必要が出やすい |
| Retire（やめる） | もう使われていないシステムを停止する | 意外と多い。いちばん安い選択肢 |
| Retain（そのまま残す） | 今回は移さず、今の場所で使い続ける | 「移さない」も正式な判断です |
見積もりに「AWS移行一式」としか書かれていなければ、どの方法を想定しているのかを最初に確認しましょう。同じ「移行」でも、費用が何倍も違うことがあります。
移行すべきか判断する5つの視点
視点1：何が、いつ切れるのか（保守期限）
最初に確認したいのは、サーバー機器の保守期限、OSやミドルウェアのサポート終了日、保守を担当する担当者や会社の契約期限です。期限が決まっているなら、期限の前に「移す・作り直す・やめる」のどれかを終えなければなりません。
反対に、期限が差し迫っていない場合は、慌てて移す必要はありません。期限を起点に逆算して、いつまでに決めるかを先に決めると、検討が進みます。
視点2：今の運用に、年間いくらかかっているか
クラウドの毎月の利用料だけを見て「高い」と感じる方が多いのですが、比べる相手は「今の本当のコスト」です。次のような費用が、今のオンプレミス側にも隠れています。
- サーバー・ネットワーク機器の購入費（年数で割った分）
- 電気代、設置場所、空調、鍵の管理
- 保守契約料、バックアップ装置・媒体の費用
- 障害時の担当者の対応時間（人件費）
- 将来の入れ替え費用
これらを年額で並べ、クラウド側の利用料と比較します。AWSには、現在の環境から移行後の費用を試算する仕組みも用意されています。開発会社が試算した前提（サーバー台数・稼働時間・バックアップ量）を、必ず書面で受け取りましょう。
📰 出典：AWS料金見積もりツール（AWS Pricing Calculator）
視点3：そのシステムを、あと何年使うのか
あと2〜3年で別のシステムに入れ替える予定なら、大規模な作り直しは割に合いません。逆に10年使うなら、今のうちにクラウド向けに直す価値が出てきます。
経済産業省のDXレポートは、老朽化・複雑化したシステムを放置した場合の経済損失を警告しています。古いままでの延命が、必ずしも安全でも安いわけでもないという点は、押さえておきたい考え方です。
📰 出典：経済産業省「DXレポート ~ITシステム『2025年の崖』の克服とDXの本格的な展開~」
視点4：止められる時間と、戻せるか（リスク）
移行の本番は、システムを止める、または並行運用する時間が必ず生まれます。「月末の締め処理の日は止められない」「止められるのは土日の夜だけ」といった条件を、先に開発会社へ伝えます。
あわせて、うまくいかなかったときに元に戻せるかも確認します。移行当日まで旧サーバーを残す、データを二重に持つなどの備えがあるかどうかで、リスクの大きさが変わります。
視点5：クラウドになっても、運用する人が要る
クラウドに移しても、運用の仕事はなくなりません。サーバーの機器は触らなくて済みますが、OSの更新、脆弱性への対応、バックアップ、費用の監視、アクセス権の管理は残ります。AWSも、セキュリティの責任を「AWSの責任」と「利用者の責任」に分けて考える「責任共有モデル」を示しています。
📰 出典：AWS責任共有モデル
「移行後の運用は誰が、何を、いくらでやるのか」が見積もりに入っていなければ、移行後に追加の相談が必要になります。
判断の進め方｜小さく調べてから決める
いきなり本番移行を発注せず、段階を踏むと失敗が減ります。
- 棚卸し：動いているシステム・サーバーの一覧と、使っている人数・使う頻度を整理する
- 仕分け：システムごとに、上の7種類のどれが合いそうかを開発会社と考える（やめる・残すも含める）
- 試算：現在の年間コストと、移行後の年間コストを同じ条件で並べる
- 小さな試験：影響の小さいシステム1つで先に試し、手順と費用感を確かめる
- 本番移行の計画：停止してよい時間、切り戻しの手順、連絡体制を決めて合意する
1〜3は大きな費用をかけずに進められます。ここまでで「移さない」という結論になっても、無駄ではありません。
やりがちな失敗
- 「クラウドにすれば安くなる」と思い込む：そのまま移しただけでは、毎月の利用料が今の運用コストを上回ることもあります。比較してから決めましょう
- 全システムを一度に移そうとする：影響範囲が広がり、問題の切り分けが難しくなります。順番を付けて進めるのが安全です
- 移行後の運用を決めていない：監視・バックアップ・更新を誰が行うかが曖昧だと、障害や費用超過に気づけません
- 今のシステムの中身を把握していない：昔の担当者しか知らない連携やバッチ処理が見つかり、移行直前に手戻りすることがあります
- AWSのアカウントを開発会社名義にしてしまう：後から引き継げず困るケースがあります。名義の考え方は、AWSアカウントは発注者と開発会社どちらが持つ？でまとめています
「移行の見積もりが大きく違う原因は、たいてい『どの方法で移すか』と『どこまで含めるか』の前提の差です。前提をそろえて比べてくださいね」
発注者がやることチェックリスト
- ☐ 対象のシステムと、それぞれの保守・サポート期限を一覧にした
- ☐ 今のオンプレミス運用にかかっている年間コスト（機器・保守・電気・人件費）を出した
- ☐ システムごとに、あと何年使う予定かを決めた
- ☐ 「やめる」「残す」も含めて選択肢を検討した
- ☐ 業務上、止められない日や時間帯を整理した
- ☐ 移行後の運用（監視・更新・バックアップ・費用管理）の担当と範囲を決めた
- ☐ AWSアカウントの名義と、管理者権限を持つ人を決めた
- ☐ 見積もりの前提（台数・稼働時間・データ量）を書面でもらった
開発会社への質問例
打ち合わせで、そのまま使える質問です。
- 「今回の移行は、7種類のうちどの方法を想定していますか。ほかの方法だと費用と期間はどう変わりますか？」
- 「移行後の毎月の費用の試算は、どんな前提（サーバー台数・稼働時間・データ量）ですか？」
- 「移行しないで、今の環境のまま延命する場合の選択肢とリスクも教えてもらえますか？」
- 「本番移行の際、システムが止まる時間はどのくらいですか。うまくいかなかった場合に元へ戻す手順はありますか？」
- 「移行後の運用（更新・バックアップ・監視・費用の確認）は、どこまでが御社の範囲で、どこからが当社の役割ですか？」
答えの中に「前提」と「含まれないもの」を丁寧に説明してくれる開発会社は、移行後の相談もしやすい相手です。
まとめ：移行は「目的」ではなく、保守期限と運用コストを解く手段
オンプレミスの業務システムをAWSへ移すべきかは、次の5つで考えると整理できます。
- 何がいつ切れるのか（保守・サポート期限）
- 今の運用に年間いくらかかっているか
- そのシステムをあと何年使うのか
- 止められる時間と、元に戻せるか
- 移行後に運用する人と範囲
「全部を急いで移す」でも「何もしない」でもなく、棚卸し→仕分け→試算→小さな試験の順に進めれば、無理のない判断ができます。まずは、システムの一覧と保守期限を並べるところから始めてみてください。
次の一歩として、AWSの費用の見方はAWSの月額費用の見積もりは高い？安い？も参考になります。
あわせて読みたい関連記事
