LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

同じ基幹システムの移行なのに、見積もりの金額が会社によって何倍も違う。移行したのに、クラウドの利用料が思っていたより下がらない——。基幹システムのクラウド移行を検討する企業では、こうした戸惑いが起こりがちです。基幹システムのクラウド移行費用とは、ERP（統合基幹業務システム）や販売管理・生産管理・会計システムなどを、自社で持つサーバー（オンプレミス）からクラウド環境へ移すときにかかる、設計・移行・テスト・運用準備の費用を指します。

費用の見当をつけるには、まず移行方式を決めるのが近道です。ただし万能ではなく、同じ方式でも対象システムの規模や連携の数で金額は大きく変わります。本記事では、基幹システムの移行を検討する情報システム部門の担当者に向けて、方式ごとの費用の違い、費用の内訳、見積もりに幅が出る理由、期間の目安、費用を抑える進め方、そして外部に委託するときに確認したい点を整理します。

移行方式による費用の違い

総務省の令和6年版情報通信白書によると、クラウドサービスを利用する国内企業の割合は年々上がっています。^*1 移行の方式は、大きくリフト＆シフト、リプラットフォーム、リアーキテクチャの3つに分かれます。なお、ここから挙げる金額と期間は公的な統計ではなく、移行案件で一般に挙げられる目安です。実際の費用は、対象システムを調べたうえでの見積もりで確かめてください。

リフト＆シフトは、既存のシステムを、プログラムを大きく直さずにクラウドのIaaS（サーバーなどの基盤を借りる形のクラウド）へ移し替える方式です。3つの中では初期費用をもっとも抑えやすく、中小規模の業務システム1本であれば、数百万円〜1,000万円台前半が一つの目安です。

リフト＆シフトで注意したいのは、クラウドへ移しただけでは費用の面での利点を十分に得られない場合がある点です。古い構成のままクラウドに載せると、クラウドの利用料が、オンプレミスのときのインフラ費用を上回ることがあります。移行した後にどう構成を見直すかを、移行の計画に最初から入れておきます。

リプラットフォームは、全体の構成は保ったまま、データベースをクラウド事業者が運用するサービス（マネージドサービス）に切り替えるなど、クラウドに合わせた部分的な改修を加える方式です。リフト＆シフトよりクラウドの利点を得やすく、リアーキテクチャほど費用が膨らまない方式です。調査・設計・テストの費用に改修の開発費が上乗せされ、中規模のシステムで1,000万円〜3,000万円台が目安です。

リアーキテクチャは、クラウドの仕組みを前提に、システムを根本から設計し直して作り直す方式です。開発期間が1年以上になることも少なくなく、ERP全体を作り直す場合は数千万円〜数億円規模の見積もりが出ることがあります。初期費用はもっとも大きくなる一方で、長い目で見た運用費の削減や、機能を追加しやすい構成を目指せます。移行後の効果を数字で試算したうえで、投資するかどうかを決めます。

費用の内訳

クラウド移行の費用は、移行までにかかる初期費用と、移行後に毎月かかる費用に分けて考えます。初期費用だけで比べると費用対効果を見誤るため、移行後の費用まで含めたTCO（総保有コスト）で試算します。主な項目は次の6つです。

初期費用のうち、見積もりが甘くなりやすいのがテストと並行稼働です。本番に近い負荷をかける試験や、連携先のシステムとの結合テストには、相応のインフラ費と人件費がかかります。

移行後は、サーバー機器の減価償却やデータセンターの費用がなくなる代わりに、クラウドの利用料が毎月かかります。使った量に応じた料金なので、システムの負荷が高い月は費用も上がります。

見落とされやすいのが、クラウドからデータを送り出すときの通信料と、社内の教育費です。大量のデータを頻繁にやり取りするシステムでは、通信料が予想以上に積み上がることがあるため、設計の段階でデータの流れを確かめておきます。システム管理者や利用部門がクラウド環境の操作に慣れるための研修費も見込んでおきます。

なぜ見積もりに幅が出るのか

同じ基幹システムのクラウド移行でも、見積もりの金額には数百万円から数億円まで大きな幅が出ます。幅を生む主な要因は、次の4つです。

一つ目は、データの量と形式です。移すデータが多い場合や、古い形式で保存されている場合は、変換・整理・検証の工数が膨らみます。長年使ってきた基幹システムではデータの品質がそろっていないことが少なくなく、移行前のデータの整理が想定外の追加作業になることがあります。

二つ目は、連携しているシステムの数です。会計・人事・販売・在庫管理など多くのシステムとつながっている基幹システムほど、連携部分の見直しと再テストが増えます。1か所の改修がほかのシステムに影響するため、移行の順序の設計と結合テストにかかる工数も増える傾向があります。

三つ目は、パッケージ製品に加えた改修（カスタマイズ）の量です。自社向けに作り込んだ部分は、移行のときに改修が必要になることがあります。カスタマイズが多いほど開発費が積み上がるため、費用への影響が大きい要因です。

四つ目は、止まらずに動き続けることやセキュリティ、データの保存場所に関する規制など、機能以外の要件の厳しさです。要件が厳しければ、機器を二重にする構成やセキュリティ設計の費用がかかります。業務を止められる時間が短い場合は並行稼働の期間を長く取る必要があり、その分だけ二重の運用費が発生しやすくなります。

移行にかかる期間

勤怠管理や経費精算のような単独の業務システムをリフト＆シフトで移す場合は、調査から本番稼働まで3〜6か月程度が一つの目安です。連携するシステムが少なくデータ量も限られるため、比較的進めやすい対象です。ただし、古いプログラムが残っている場合は、想定外の作業が発生することがあります。調査の段階で接続先を洗い出し、優先順位を決めてから着手します。

ERPのように複数のシステムが連携する基幹システム全体を移す場合は、6〜18か月以上かかることがあります。会計・人事・販売・生産が連携している場合は、移行の順序を設計したうえで、段階に分けて移すのが一般的です。

クラウド移行と混同されやすいのが、サーバーリプレイスです。サーバーリプレイスは、古くなったオンプレミスのサーバーを新しい機器に入れ替える作業で、クラウドの利用料はかかりません。クラウド移行は、設備を持つことから借りて使うことへの切り替えです。どちらを選ぶかは、総保有コストで比べて決めます。サーバーの入れ替えを委託するときの進め方は「サーバーリプレイス外注｜費用・進め方・依頼先の比較ガイド」で扱っています。

費用を抑える進め方

まず、移行前の調査で、移すかどうかと優先順位を決めます。すべてのシステムを一度に移すのではなく、移しやすさ・事業上の価値・リスクの3つで対象に優先順位を付け、段階に分けるのが現実的です。社内でクラウドを優先する方針を掲げていても、すべてのシステムがクラウドに向いているわけではありません。頻繁なリアルタイム処理、特殊な機器への依存、データの保存場所の規制がある場合は、オンプレミスとクラウドを組み合わせる構成が適切なこともあります。

次に、最初から大規模な作り直しを目指さず、まずリフト＆シフトで早めにクラウドへ移し、その後に段階的にリプラットフォームへ進める方法があります。初期投資を分けて払えるため、計画全体のリスクを抑えやすくなります。ただし、見直しを後回しにしすぎると、クラウドの費用が高いままの状態が長く続きます。移行の計画の中に、見直しを行う時期と目標値を書いておきます。

クラウドの利用料そのものは、割引プランで下げられます。AWS・Azure・Google Cloudなどの主なクラウド事業者は、1〜3年の利用を約束すると割引価格が適用されるプランを用意しています（AWSならReserved InstanceやSavings Plans）。利用量の実績が見えて安定してきた段階で使えば、通常の料金に比べて利用料を大きく下げられる場合があります。

費用の超過が起きやすいのは、テストと並行稼働の期間が延びたときです。結合テストで不具合が見つかると、そのぶん旧環境を維持する費用がかかります。テスト計画を早めに作ってテスト環境の費用も予算に入れ、本番と同じくらいのデータ量と負荷で検証しておけば、本番移行後のトラブルを減らせます。

移行が終わった後も、費用の見直しは続きます。リソースにコスト配分用のラベル（タグ）を付けて、システムや部門ごとの利用状況を見えるようにしておくと、どこに費用がかかっているかを特定しやすくなります。移行直後は大きめのサーバーで動かすことが多いため、負荷のデータがたまった段階でサイズを見直すと費用を下げられることがあります。時間帯で負荷が変わる業務なら、台数を自動で増減させる機能（オートスケーリング）も検討に値します。

移行時に決めた構成は、半年後・1年後には利用量に合わなくなることがあります。四半期ごとなどの周期でクラウドの利用料を点検し、使っていないサーバーやストレージの停止、料金プランの見直しを行う体制を運用に組み込みます。社内で体制を作りにくければ、運用保守の委託先に点検を依頼することもできます。

外部に委託するときに確認しておきたい点

移行を社内で進めるか外部に委託するかは、社内の技術力と予算、どこまでのリスクを受け入れられるかで決まります。社内で進めるには、次の知識を持つ担当者が要ります。

• クラウドの構成の設計（AWS・Azure・Google Cloudのいずれか）
• ネットワークとセキュリティの設計（アクセス権限や専用線を含む）
• データベースの移行（データ構造の変換とデータの整理）
• 対象システムの内部の仕様とプログラムの理解
• スケジュールとリスクの管理

こうした知識を持つエンジニアが複数そろっていないと、設計の誤りや並行稼働の長期化が起きやすくなります。設計の漏れで本番障害が起きれば、復旧の費用が当初の移行予算を超えることもあります。中小規模のシステム1本のリフト＆シフトでも、調査から本番稼働まで2〜4名で3〜6か月程度の体制が要る場合があります。

外部に委託すれば、移行の設計・テスト・運用への引き継ぎまでを一貫して任せられます。委託先を選ぶときは、「移行の作業だけ」を請け負うのか、「移行後の運用まで」続けて担当するのかを確かめておきます。移行後に別の会社へ運用を引き継ぐと、システムの仕様や移行の経緯を伝え直す費用がかかるためです。

まとめ：クラウド移行費用で確かめておきたい3つの点

基幹システムのクラウド移行費用を見積もるうえで、確かめておきたい点は3つに整理できます。第一に、目的と予算に合った移行方式を選ぶこと。第二に、初期費用だけでなく、月々の利用料・運用保守費・見落とされやすい費用まで含めた総保有コストで、オンプレミスと比べること。第三に、社内の体制で移行を進められるかを見極め、足りなければ委託も含めて検討することです。この3点を踏まえておけば、「移行したのに費用が下がらず、テストのやり直しで予算も超えた」という事態を避けやすくなります。移行方式の選定や体制づくりに迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：総務省「令和6年版 情報通信白書」（https://www.soumu.go.jp/johotsusintokei/whitepaper/r06.html）。出典：総務省「令和6年版 情報通信白書」（2024年公表）。データ集「企業におけるクラウドサービスの利用状況」（出典は総務省「通信利用動向調査」）を参照（2026年9月確認）

Tweet