LASSIC Media らしくメディア

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

基幹システムのクラウド移行費用—リフト＆シフト〜リアーキテクチャの費用構造

基幹システムのクラウド移行費用とは、ERP（Enterprise Resource Planning、統合基幹業務システム）や販売管理・生産管理・会計システムなどをオンプレミスからクラウド環境へ移行する際に発生する、設計・移行・テスト・運用準備の全コストを指します。総務省「令和6年版 情報通信白書」（2024年公表）によれば、クラウドサービスを活用している国内企業の割合は年々上昇しており、基幹系システムへの適用も本格化しています^*1。費用は移行方式と対象システムの規模・複雑度によって幅が生じるため、あくまで市場参考値として参照してください。

リフト＆シフト（Lift & Shift）の費用内訳

リフト＆シフトとは、既存システムをほぼそのままクラウドのIaaS（Infrastructure as a Service）環境に移し替える手法です。コードの大幅改修をしないため、3つの方式の中では初期費用をもっとも抑えやすいと言われています。

費用の内訳は大きく4つに分かれます。アセスメント・設計費（移行可否の調査・設計書作成）、実際の移行作業費（データ移行・環境構築）、テスト・並行稼働費（本番切り替え前の検証）、そして移行後の初期チューニング費です。市場参考値として、中小規模の業務システム1本あたり数百万円〜1,000万円台前半の範囲に収まる事例が報告されていますが、対象システムの規模・接続数・データ量によって変動します（一次資料による裏付けはなく、あくまで市場参考値です）。

注意点は、クラウドへ移行しただけではクラウドのコストメリットを十分に得られないケースがある点です。古いアーキテクチャのままクラウドに載せると、クラウド利用料がオンプレのインフラ費用を上回る「コスト増」になることがあります。移行後の最適化計画を事前に組み込むことが大切です。

リプラットフォーム（Replatform）の費用内訳

リプラットフォームとは、基本的なアーキテクチャを維持しながらもデータベースのマネージドサービス化やコンテナ対応など、クラウドに合わせた部分的な改修を加える方式です。リフト＆シフトよりも効果が出やすく、リアーキテクチャほど費用が膨らまないため、費用対効果のバランスが取りやすい選択肢です。

費用は移行するシステムの改修範囲に比例して増加します。アセスメント・設計・テスト費に加え、改修開発費が上乗せされます。市場参考値では中規模システムで1,000万円〜3,000万円台の案件が見られますが、改修箇所の多寡で大きく変わります（一次資料による裏付けはなく、あくまで市場参考値です）。

リアーキテクチャ（Re-architect）の費用内訳

リアーキテクチャとは、クラウドネイティブ設計（マイクロサービス・サーバーレス等）に合わせてシステムを根本から再設計・再開発する方式です。初期投資はもっとも大きくなりますが、長期的な運用コストの削減や拡張性の向上を目指すうえで、実績のある選択肢です。

開発期間は1年以上になる場合も少なくなく、それに伴い費用も増加します。ERP全体の再構築では数千万円〜数億円規模の見積もりが出ることがあります（一次資料による裏付けはなく、あくまで市場参考値です）。移行後の効果を定量的に試算したうえで、投資判断を行うことが求められます。

費用を構成する6つの項目—初期費用と月額費用の内訳

クラウド移行の費用は「初期費用」と「移行後の継続費用（月額）」に分けて考えることが大切です。初期費用だけで比較すると移行の費用対効果を見誤るため、トータルコスト（TCO：Total Cost of Ownership）で試算する視点が必要です。

初期費用の主な項目（アセスメント・設計・移行・テスト）

初期費用の中でも、アセスメントと設計フェーズを省略するとコストが後から膨らむリスクが高まります。移行対象システムの依存関係・外部連携数・データ量を正確に把握することで、設計工程でのやり直しを減らせます。

テスト・並行稼働フェーズは特に見積もりが甘くなりやすい項目です。本番相当の負荷テスト・連携先との結合テストを実施するには、相応のインフラ費と人件費が発生します。並行稼働中はクラウドと旧オンプレの両方を維持するため、一時的に費用が増加します。

移行後の月額費用（クラウド利用料・運用保守）

クラウド移行後はオンプレ時のハードウェア減価償却・データセンター費用がなくなる一方、クラウド利用料が月次コストとして継続的に発生します。利用量に応じた従量課金のため、システム負荷が高い月は費用が増加することに注意が必要です。

運用保守費は、移行直後は新環境への慣れと体制整備のため一時的に増加することがあります。自社内にクラウド運用の知識を持つ担当者がいない場合は、外部の運用保守サービスを活用することで安定した運用が期待できます。

隠れコストに注意—データ転送・接続・再教育

見落とされやすい隠れコストとして、クラウドのデータ転送費用（アウトバウンド通信料）があります。大量データを頻繁にやり取りするシステムでは、通信費が予想外に積み上がるケースがあるため、設計段階でデータフローを確認することが大切です。

また、システム管理者・利用部門向けのトレーニング費用も発生します。クラウド環境の操作・セキュリティポリシーへの対応など、社内教育コストを事前に見込んでおくことが求められます。

クラウド移行費用を左右する5つの要因—なぜ見積もりに幅が出るのか

ここまで移行方式別・費用項目別の目安を紹介しましたが、同じ「基幹システムのクラウド移行」であっても、見積金額には数百万円から数億円まで大きな幅が生じます。この幅を生む要因を事前に把握しておくと、自社のケースがどの価格帯に近いかを見立てやすくなるはずです。

データ量・データ形式の複雑さ

移行対象のデータ量が多い、あるいはデータ形式が古い独自形式である場合、変換・クレンジング・検証にかかる工数が膨らみます。特に長年運用してきた基幹システムでは、過去の運用でデータ品質が揺れているケースが少なくなく、移行前のデータクリーニングが想定外の追加工程になることがあります。

外部連携システムの数と依存関係

会計・人事・販売・在庫管理など複数システムと連携している基幹システムほど、連携インターフェースの見直し・再テストの範囲が広がります。連携先が多いプロジェクトでは、1つの改修が他システムに影響を及ぼすため、移行順序の設計と結合テストに割く工数が増加する傾向があります。

カスタマイズ・アドオンの改修範囲

パッケージ製品を大幅にカスタマイズして使っている場合、標準機能に依存する移行方式（リプラットフォーム等）だけでは対応しきれず、独自開発部分の改修が必要になることがあります。カスタマイズ箇所が多いほど改修開発費が積み上がりやすく、費用を左右する要因の中でも影響度が大きい項目といえるでしょう。

非機能要件とダウンタイム許容度

可用性・セキュリティ・データ所在地に関する規制対応など、非機能要件が厳しい場合は、冗長構成やセキュリティ設計に追加のコストがかかります。また、業務を止められる時間（ダウンタイム許容度）が短い場合は並行稼働期間を長く取る必要があり、その分の二重運用コストが発生しやすくなる点に注意が必要です。

移行期間の目安とスケジュール—規模別の所要期間

クラウド移行のスケジュールは、対象システムの規模・複雑度・移行方式によって大きく異なります。以下は一般的な目安です（市場参考値・一次資料による裏付けはありません）。

中小規模システム（業務システム1本）の進め方

単独の業務システム（例：勤怠管理・経費精算など）のリフト＆シフトであれば、アセスメントから本番稼働まで3〜6ヶ月程度が一つの目安とされています。依存システムが少なくデータ量も限定的なため、比較的スムーズに進めやすい対象です。

ただし、連携先のシステム数が多い場合や、レガシーなコードが残っている場合は想定外の工数が発生することがあります。アセスメントで接続先を洗い出し、優先順位を決めてから着手することが大切です。

基幹システム全体（ERP等の複合的なシステム）の進め方

ERPや複数システムが連携する基幹システム全体を移行する場合は、6〜18ヶ月以上のプロジェクト期間になることがあります（市場参考値・規模・方式による）。段階的な移行（フェーズ分割）により、リスクを分散しながら進めるアプローチが一般的です。

特に会計・人事・販売・生産が連携しているERPでは、ある機能の移行がほかの機能に影響を与えるため、移行順序の設計が重要です。プロジェクト全体を通じた品質管理体制を確立することが求められます。

サーバーリプレイス（オンプレ更改）との違い

サーバーリプレイスとは、老朽化したオンプレミスサーバーを新しいオンプレミス機器に更改する作業です。クラウド移行とは目的も費用構造も異なります。サーバーリプレイスはハードウェア購入・設置・OS再設定が中心で、クラウドサービス費用は発生しません。

一方、クラウド移行は「インフラの所有から利用へ」のシフトであり、以降の設備投資サイクルが変わります。将来のEOS（End of Support、サポート終了）時期を見据えてどちらを選ぶかを検討する際は、TCO（総保有コスト）での比較が有効です。

クラウド移行費用を抑える5つの勘所

クラウド移行を検討する企業にとって、費用の最適化は重要なテーマです。以下に、移行前から移行後にわたってコストをコントロールするための実務上の勘所を整理します。

アセスメントで移行可否・優先度を決める

移行前のアセスメントを丁寧に行うことが、後工程での手戻りを防ぐための出発点です。全システムを一度に移行しようとするのではなく、移行の容易さ・ビジネス価値・リスクの3軸で対象を優先度付けし、フェーズを分割する方法が現実的です。

「クラウドファースト」の方針を掲げていても、すべてのシステムがクラウドに適しているわけではありません。高頻度のリアルタイム処理・特殊なハードウェア依存・規制対応上のデータ所在制限がある場合は、オンプレとのハイブリッド構成が適切なケースもあります。

リフト＆シフト→段階的最適化で初期投資を抑える

大規模なリアーキテクチャを最初から目指すのではなく、まずリフト＆シフトで早期にクラウドへ移行し、その後に段階的な最適化（リプラットフォーム化）を進める方法があります。この「Migrate First, Optimize Later」のアプローチは、初期投資を分散できる点でプロジェクトリスクを抑えやすいです。

ただし、最適化フェーズを後回しにしすぎると、クラウドコストが想定より高い状態が長期間続く可能性があります。移行ロードマップの中に最適化フェーズの時期とKPIを設定することが大切です。

Reserved Instance・Savings Plansの活用

AWS・Azure・GCPなどの主要クラウドプロバイダーは、一定期間（1〜3年）の利用をコミットすることで割引価格が適用されるプラン（AWSであればReserved Instance・Savings Plans）を提供しています。

移行後の利用量が安定してきた段階でこれらのプランを活用することで、オンデマンド価格に比べてクラウド利用料を大幅に圧縮できる場合があります。利用量の実績が見えてきたタイミングで改めて試算することが大切です。

テスト・並行稼働期間の見積もりを甘くしない

クラウド移行プロジェクトで費用超過が発生しやすいのが、テスト・並行稼働期間の延長です。結合テストで不具合が見つかった場合、並行稼働（旧環境維持）のコストがその分長く発生します。

テスト計画を早期に策定し、テスト環境のクラウドコストも予算に含めておくことが求められます。本番相当のデータ量・負荷での事前検証を行うことで、本番移行後のトラブルを減らせます。

不要なリソースの棚卸しで余剰コストを削減

クラウドでは使用していないインスタンス・ストレージが稼働し続けることでコストが発生します。移行後の定期的なリソース棚卸し（クラウドコスト管理ツールの活用）を運用フローに組み込むことが、中長期的なコスト最適化につながります。

移行後のランニングコスト最適化—継続的に費用を抑える視点

クラウド移行が完了した後も、費用の最適化は一度きりの作業では終わりません。オンプレミス時代は減価償却で費用がおおむね固定化されていたのに対し、クラウドは利用量に応じた従量課金であるため、運用フェーズに入ってからも継続的な見直しが求められます。

コスト可視化とタグ運用による使用状況の把握

クラウド利用料は、システム単位・部門単位で内訳が見えていないと、どこに費用がかかっているかを特定しにくくなります。リソースにタグ（コスト配分用のラベル）を付与し、利用状況を可視化する運用を移行と同時に設計しておくと、後からのコスト分析がしやすくなるでしょう。

オートスケーリング・インスタンスサイズ見直しの機会

移行直後は余裕を持って大きめのインスタンスサイズで稼働させることが多く、実際の負荷データが蓄積された段階でサイズを見直すと、コストを圧縮できる余地が見つかることがあります。日次・時間帯によって負荷が変動する業務であれば、オートスケーリング機能の活用も検討に値します。

定期的なコストレビュー体制を運用に組み込む

移行時に決めた構成が半年後・1年後も最適とは限りません。四半期ごとなど定期的にクラウド利用料をレビューし、不要リソースの停止・料金プランの見直しを行う体制を運用フローに組み込むことが、移行後のコストを継続的に抑えるうえで有効です。社内にその体制を構築しにくい場合は、運用保守を委託しているパートナーに定期レビューを依頼することもできます。

移行を内製するか外注するか—必要スキルとリスク

クラウド移行を社内で対応するか外部パートナーに委託するかの判断は、保有スキルと予算・リスク許容度によって変わります。ここでは内製に必要な要件と外注との差分を整理します。

内製する場合に必要なスキルと工数

クラウド移行を内製するには、以下のスキルを持つ担当者が必要です。

• クラウドアーキテクチャ設計（AWS/Azure/GCP いずれかの設計知識）
• ネットワーク・セキュリティ設計（VPC・IAM・専用線設計）
• データベース移行（スキーマ変換・データクレンジング）
• 既存システムのソースコード理解（対象システムの内部仕様）
• プロジェクト管理（スケジュール・リスク管理）

これらの知識を持つ社内エンジニアが複数名揃っていない場合、移行の設計ミスや並行稼働期間の長期化が生じるリスクがあります。設計漏れによる本番障害が発生すると、復旧コストが当初の移行予算を超える場合もあります。

工数の目安としては、中小規模システム1本のリフト＆シフトであっても、アセスメントから本番稼働まで2〜4名×3〜6ヶ月程度の体制が必要になるケースがあります（市場参考値・一次資料による裏付けはありません）。

外注（専門パートナー活用）との差分

専門パートナーに委託する場合、クラウド移行の設計・テスト・運用移管までを一貫して担ってもらうことができます。社内に移行ノウハウがなくても、プロジェクト推進を支援してもらえる点が内製との大きな差分です。

また、移行後の運用フェーズを同一パートナーに継続委託することで、移行〜運用の知識断絶を防ぐこともできます。LASSICでは元請（プライムベンダー）として基幹システムの移行・運用支援に対応しており、移行後も継続的な保守体制を提供しています。

外注を選ぶ際には、ベンダーが「移行フェーズのみ」か「移行後の運用まで一貫対応」かを確認することが大切です。移行後に別パートナーに引き渡す場合、知識移転コストが発生することに注意が必要です。

まとめ—クラウド移行費用を適正化するための3つの判断軸

本稿では、基幹システムのクラウド移行費用を移行方式・費用項目・移行期間の観点から整理しました。要点を3つに集約すると次の通りです。

第一に、費用は移行方式（リフト＆シフト・リプラットフォーム・リアーキテクチャ）によって初期投資の規模が大きく異なります。目的と予算に応じた方式の選定が費用最適化の入口です。第二に、初期費用だけでなくTCO（月額利用料・運用保守費・隠れコスト）で試算することが、オンプレとの正確な比較につながります。第三に、移行を内製するには複数の専門スキルが必要であり、不十分な体制で進めると後工程での手戻りコストが増大します。外注の検討も含めてリスク管理の観点から判断することが求められます。

よくある質問

基幹システムのクラウド移行費用の相場はどのくらいですか？

移行方式と対象システムの規模によって幅があります。市場参考値として、中小規模のシステム1本のリフト＆シフトであれば数百万円〜1,000万円台前半、複数システムが連携するERP全体の移行では1,000万円〜数億円規模になる場合があります。ただしこれらはあくまで市場参考値であり、一次資料による裏付けがないため、正確な費用は要件定義後の見積もりでご確認ください。

リフト＆シフトとリアーキテクチャの費用差はどのくらいですか？

同じシステムを対象とした場合、リアーキテクチャはリフト＆シフトの数倍〜十数倍の初期費用になることがあります（市場参考値・一次資料による裏付けはありません）。ただし、リアーキテクチャは移行後の運用コスト削減や拡張性の向上が期待できるため、長期的なTCOで比較することが大切です。どちらが最適かは対象システムのライフサイクルと将来の拡張計画によって異なります。

クラウド移行後は運用コストが下がりますか？

下がるとは限りません。リフト＆シフトのみでは既存アーキテクチャのままクラウドに載せるため、クラウドのコストメリットを十分に得られない場合があります。クラウドに最適化した構成にすることで、ハードウェア更新サイクルのコストやデータセンター維持費の削減が期待できます。移行後の最適化計画をあらかじめ立てておくことが大切です。

基幹システムの移行にはどのくらいの期間がかかりますか？

中小規模の業務システム1本のリフト＆シフトで3〜6ヶ月程度、ERPなど複数システムが連携する基幹システム全体では6〜18ヶ月以上かかるケースがあります（市場参考値）。アセスメント・設計フェーズを丁寧に行い、段階的な移行計画を立てることで、リスクを分散しながら進めることができます。

移行を外注する場合の選定ポイントは何ですか？

選定時には主に3点を確認することをお勧めします。①移行フェーズのみか移行後の運用まで一貫対応しているか、②対象システム（ERPやオンプレ基幹系）の移行実績があるか、③技術スタック（AWS／Azure／GCP）の対応範囲と得意領域が要件と合っているかです。移行後の運用も含めた一貫対応ができるパートナーを選ぶことで、知識断絶によるトラブルを防ぐことが期待できます。

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

---

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

1. *1　出典：総務省「令和6年版 情報通信白書」（2024年公表）
2. *2　出典：経済産業省「DXレポート2.2」（2022年公表）レガシーシステムがDXの足かせになる警告（通称「2025年の崖」問題）を含む
3. *3　出典：IPA「DX動向2025」（2025年公表）国内企業のクラウド活用動向・DX推進状況