「自社のオンプレミスシステムをクラウドに移したいが、何から始めればいいか分からない」「クラウドマイグレーションには色々なパターンがあるらしいが、自社にはどれが合うのか」——基幹システム刷新を検討する経営者・情シス責任者から、こうした問いが届きます。クラウドマイグレーション（クラウド移行）は、進め方を誤ると 移行費用が当初想定の 2～3 倍に膨らむ・業務が止まる・移行後にコストが下がらない といった失敗につながります。本記事では、クラウドマイグレーションの定義、中堅企業の基幹システム刷新で検討頻度が高い 6 つの移行パターン、移行先クラウド層の選び分け、5 ステップの進め方、費用・期間の目安、よくある失敗を整理します。
『自社のシステムをどう・どこまでクラウド化すべきか整理したい』 25 年の経験で、現状システムと業務要件から最適な移行計画を一緒に整理します。 無料相談 ＞結論：クラウドマイグレーションは『6 パターン × 5 ステップ』で進める
クラウドマイグレーションの成否は、『どのパターンで移すか（手法）』と『どの順序で進めるか（プロセス）』の組み合わせ で決まります。手法の選択を誤ると費用と期間が大幅にズレ、プロセスを飛ばすと現場の混乱が発生します。
| 観点 | 選択肢 | 判断軸 |
|---|---|---|
| ① 移行パターン | リフト＆シフト／リプラットフォーム／リファクタリング／リパーチェス／リタイア／リテイン | 業務独自性・コード保守可否・投資余力 |
| ② 移行先クラウド層 | IaaS／PaaS／SaaS の 3 層 | 業務独自仕様の維持要件・運用負荷の許容度 |
| ③ 進め方プロセス | 現状把握 → 評価 → 計画 → 実行 → 運用最適化（5 ステップ） | 段階移行 or 一括移行・並行稼働期間 |
本記事では、上記 3 観点をそれぞれ詳説します。『クラウド = AWS／Azure／GCP に移すこと』ではなく、業務要件と制約条件をもとに 3 観点を往復しながら検討する のが中堅企業の現実解です。
クラウドマイグレーションとは｜オンプレからクラウドへの移行
クラウドマイグレーションとは、自社が所有・運用するオンプレミス環境（自社サーバ・自社データセンター）で稼働しているシステムを、クラウドベンダーが提供する環境へ移行する ことを指します。移行対象は、業務システム（基幹システム・会計・販売管理）、ファイルサーバ、メールサーバ、認証基盤など多岐にわたります。
| 比較項目 | オンプレミス | クラウド |
|---|---|---|
| ハードウェア所有 | 自社購入またはリース | クラウドベンダーが所有 |
| 初期投資 | 大（サーバ・ストレージ・ネットワーク機器） | 小～中（移行費用が中心） |
| 拡張性 | 段階的（追加機器の調達が必要） | 柔軟（オンデマンドで増減） |
| 運用・保守 | 自社の専門スタッフが必要 | 物理インフラ層はベンダーが担う（責任分界点は IaaS／PaaS／SaaS で異なる） |
| セキュリティ | 自社管理（物理層から自社責任） | 共同責任モデル（責任範囲は層により異なる） |
経営視点で重要な変化は、サーバ購入・リース中心の固定的な投資から、利用量や契約に応じた運用支出中心のコスト構造へ移ること です。需要変動が大きい・将来の事業規模が不確実な企業にとって、この変化は財務上のメリットになります。一方で、すべてのシステムをクラウド化する必要はなく、業務特性によってはオンプレ維持が合理的なケースもあります。
補足：クラウド利用料が必ず完全な変動費になるわけではありません。予約割引・長期契約・SaaS 年間契約・最低利用料などにより、実質的には固定費的な性格を持つこともあります。会計上の資本支出（CapEx）／運用支出（OpEx）の扱いは契約形態・会計方針によって異なります。
クラウドマイグレーションの 6 つの移行パターン
クラウド移行戦略では、AWS などが整理する 6R／7R の分類がよく使われます。7R では Relocate（仮想化基盤ごとの移動）も含まれますが、本記事では中堅企業の基幹システム刷新で検討頻度が高い 6 パターン（リホスト／リプラットフォーム／リファクタリング／リパーチェス／リタイア／リテイン）に絞って整理します。
| パターン | 概要 | 費用目安（当社想定） | 期間 | 業務影響 |
|---|---|---|---|---|
| ① リフト＆シフト（リホスト） | アプリケーションコードの変更を最小限にし、サーバ・ストレージ・ネットワークなどの実行基盤をクラウドへ移す | 1,000 万～3,000 万円 | 6～12 ヶ月 | 小 |
| ② リプラットフォーム | OS・DB・ミドルウェアの一部を最新化、またはクラウドのマネージドサービスへ置き換える | 2,000 万～5,000 万円 | 8～15 ヶ月 | 小～中 |
| ③ リファクタリング／リアーキテクチャ | コードの書き直しから、API 化・データモデル見直し・アーキテクチャ再設計まで含む（範囲によって幅が大きい） | 3,000 万～2 億円 | 12～30 ヶ月 | 中～大 |
| ④ リパーチェス（リプレース） | パッケージ／SaaS に置き換える | 3,000 万～1 億円 | 12～24 ヶ月 | 大 |
| ⑤ リタイア | 不要なシステムを廃止する | 小～数百万円程度 | 1～3 ヶ月 | 小～大（利用実態次第） |
| ⑥ リテイン | 現状を維持する判断（保守期限・リスク評価・将来移行時期の確認は必要） | 既存運用費＋リスク評価費用 | 短期（判断自体は即時可能） | 小（移行影響はないが継続利用リスクは残る） |
費用・期間の前提条件：上記は 150～300 名規模の中堅企業で、基幹システムの一部または主要サブシステムを対象とした場合の概算（当社想定） です。実際の費用・期間は、対象範囲・画面数・帳票数・バッチ本数・外部連携数・データ移行量・テスト範囲によって大きく変動します。一般相場ではなく自社想定の概算としてご覧ください。
中堅企業では、リフト＆シフトを短期的な延命策として位置づけ、その後にリファクタリング／リパーチェスへ進める段階戦略 が取られることがあります。リフト＆シフトのみで終わるとレガシー依存が残るため、数年単位で再投資が必要になる可能性を見込んでおくことが重要です。一方、リフト＆シフトは初期費用を抑えやすく、保守切れ対応や短期移行では有効な選択肢でもあります。
移行先クラウドの選び方｜IaaS／PaaS／SaaS の 3 層
クラウドと言っても、大きく 3 つの層（レイヤー） があり、業務独自仕様の扱い方や運用負荷の許容度によって最適な層が変わります。多くの議論は IaaS（AWS／Azure／GCP 等）に集中しがちですが、PaaS／SaaS も含めて検討するのが本来の選定です。
| 層 | 概要 | 主な選択肢 | 適合ケース |
|---|---|---|---|
| 層 1：IaaS（仮想サーバ層） | OS・ミドルウェアを自社で構築し、計算資源・ストレージ・ネットワークを借りる | 大手グローバルクラウド・国産クラウド | 既存運用ノウハウを活かしたい／段階的にクラウド化したい |
| 層 2：PaaS／アプリケーションプラットフォーム | アプリケーション実行基盤・マネージド DB から、認証・UI 基盤まで含むものまで幅がある | マネージド PaaS／アプリケーションプラットフォーム型 PaaS | 業務独自仕様を維持しつつ、運用負荷をベンダーに任せたい |
| 層 3：SaaS（業務パッケージ層） | 特定業務に特化した完成形アプリケーションをサブスクリプションで利用 | 業界特化型 ERP SaaS | 業務改革を伴う抜本的刷新／業務独自性が業界差別化に直結しない |
PaaS の幅について：PaaS には、アプリケーション実行基盤やマネージド DB を提供するものから、認証・UI 基盤まで含むアプリケーションプラットフォーム型のものまで幅があります。本記事では、業務アプリケーション刷新で使われるアプリケーションプラットフォーム型 PaaS も含めて扱います。
実務では、『業務要件から移行先層の仮説を置く → ベンダー候補を比較する → 移行パターンと整合するか見直す』という往復型 で検討します。層・ベンダー・移行パターンは一度で決め切るのではなく、業務独自性・運用負荷・予算を見ながら相互に調整することが重要です。
IaaS 層の主要クラウドベンダー比較
層 1（IaaS）を選ぶ場合、選択肢として大手クラウドベンダーが並びます。以下は、IaaS 選定時に比較されやすい観点 を整理したものです。実際の選定では、最新のサービス提供状況・リージョン・SLA・セキュリティ要件・既存ライセンス・運用体制・パートナー支援体制を個別に確認する必要があります。
| 項目 | 大手グローバルクラウド A | 大手グローバルクラウド B | 大手グローバルクラウド C | 国産クラウド |
|---|---|---|---|---|
| 選ばれやすい観点 | 国内シェア・移行支援サービスの選択肢の多さ | Microsoft 製品（Windows Server・SQL Server・Office 365）との親和性 | データ分析・AI／ML 活用 | 国内事業者との契約・契約管轄・日本語サポート・公共／自治体／特定業界の要件・既存国内ベンダーとの関係 |
| 向いている企業 | 移行実績の知見を重視・製造／流通／金融 | Microsoft 製品利用中・Windows ベースのシステム | データ活用・AI 推進に積極的な企業 | 国内事業者との契約・サポート体制を重視する企業 |
クラウドマイグレーションの進め方｜5 ステップ
移行パターンと移行先層の仮説が決まったら、5 ステップのプロセス で順に進めます。ステップを飛ばすと、要件定義の漏れ・想定外コスト・現場混乱が発生します。
ステップ① 現状把握（Discovery）
移行対象システムの 棚卸し から始めます。サーバ構成・OS・ミドルウェア・依存関係・データ量・トラフィック・利用ユーザー数・業務影響度を洗い出し、移行対象の全体像を可視化します。このステップでは、『使われていない隠れシステム』『誰も把握していない依存関係』が見つかることも多く、移行対象の全体像を正しく把握するうえで重要 です。
ステップ② 評価（Assessment）
各システムを 移行パターン（6R）と移行先層（IaaS／PaaS／SaaS）にマッピング します。「業務独自性・コード保守可否・投資余力・業務改革の意志」の 4 軸で評価し、サブシステム単位で最適なパターンを選定します。『すべて同じパターンに揃える』のは現実的ではない。サブシステムごとに 6 パターンを組み合わせるのが中堅企業の現実解です。対象範囲にもよりますが、中堅企業の主要基幹システムでは、ステップ①②に 2～4 ヶ月程度 を見込むと、後工程の手戻りを抑えやすくなります。
ステップ③ 計画（Planning）
移行優先順位・スケジュール・体制・予算を策定します。段階移行と一括移行 の選択もこのフェーズで決定。中堅企業では、業務領域ごとに切り分けられる場合 段階移行の方がリスクを抑えやすいケースがあります。一方で、システム間依存が強い場合は一括移行の方が適することもあるため、並行稼働期間とデータ整合性を含めて判断してください。
ステップ④ 実行（Migration）
計画に沿って 実際の移行作業 を進めます。データ移行・アプリケーション移行・テスト・並行稼働・本番切替を順に実施。『データ変換工数』『テスト工数』『現場研修工数』を別建てで予算化 することが、想定外コスト回避のポイントです。
ステップ⑤ 運用最適化（Optimization）
移行完了は『ゴール』ではなく『スタート』。クラウドコストの管理（FinOps）・パフォーマンス最適化・セキュリティ運用を継続的に行います。クラウド利用料は、過剰スペック・停止忘れ・ストレージ／バックアップ増加・データ転送料・監視／ログ費用・サポートプラン費用 などで膨らむことがあるため、移行後のコスト管理を運用設計に含めることが重要です。
クラウドマイグレーションの費用・期間目安
クラウドマイグレーションの費用は、移行パターン・対象範囲・既存システムの複雑度 によって大きく変動します。中堅企業（150～300 名規模）の典型的な目安を整理します。
| 移行範囲 | パターン | 初期費用目安（当社想定） | 期間 | クラウド月額利用料（IaaS 中心） |
|---|---|---|---|---|
| 単一業務サブシステム | リフト＆シフト | 500 万～2,000 万円 | 4～8 ヶ月 | 10 万～50 万円／月 |
| 複数業務サブシステム | リフト＆シフト＋一部リプラットフォーム | 3,000 万～8,000 万円 | 8～15 ヶ月 | 50 万～200 万円／月 |
| 基幹システム全体 | リファクタリング or リパーチェス | 5,000 万～2 億円 | 15～30 ヶ月 | 100 万～500 万円／月 |
費用前提：クラウド月額利用料は、IaaS 中心の場合のインフラ利用料 を想定しています。SaaS／PaaS を選ぶ場合は、ユーザー数・機能・データ量に応じたライセンス費用が中心となるため、別途試算が必要です。実際の費用は、利用ユーザー数・処理量・データ量・可用性要件・バックアップ要件・リージョン・データ転送料・サポートプラン・監視／ログ保持期間・ライセンス費用の含め方・為替・予約割引適用有無によって大きく変動します。
重要なのは、『初期費用』だけで判断しないこと。簡易的には、5 年 TCO ＝ 初期費用 ＋ クラウド／ライセンス月額費用 × 60 ヶ月 ＋ 運用人件費 で比較します。実際には、監視・ログ管理、バックアップ、サポートプラン、データ転送費用、旧環境の並行稼働費、教育費、追加改修費も含めて試算する必要があります。リフト＆シフトは初期費用が安いものの、レガシー依存が残る場合は、将来的な再投資を見込んだ TCO 比較が必要です。
クラウドマイグレーションの『よくある失敗』
失敗 1：『とりあえずクラウド化』で業務要件を整理しない
「クラウド化が目的」になってしまい、業務要件・移行範囲・優先順位の整理を後回し にするケース。ステップ①現状把握とステップ②評価を 2～4 ヶ月程度かけて完了させる（対象範囲による）ことで、後の手戻りを防げます。
失敗 2：『コスト削減』だけを目的にする
「クラウドは安い」というイメージで移行したが、過剰スペック・停止忘れ・ストレージ／バックアップ増加・データ転送料・監視／ログ費用・サポートプラン費用 などで想定より高くなる失敗。クラウドマイグレーションは 『コスト構造の転換』『拡張性の獲得』『運用負荷の軽減』 といった複数価値で評価すべきです。
失敗 3：すべてを 1 つのパターン・1 つの層に揃える
「全部リフト＆シフトで」「全部 IaaS で」と一律に決め、業務独自性の高いサブシステムが結果的に不適合 になるケース。サブシステムごとに 6 パターン × 3 層から最適な組み合わせを選ぶのが現実解です。
失敗 4：移行後の運用最適化を計画していない
移行完了で『プロジェクト終了』とせず、FinOps（クラウドコスト最適化）・パフォーマンス監視・セキュリティ運用を継続的に行う体制 を構築しないと、半年～1 年後にクラウド利用料が想定の 1.5～2 倍になっているケースが発生します。
失敗 5：並行稼働期間を業務サイクルに合わせて設計しない
旧環境と新環境の並行稼働期間は、月次・四半期・年次処理など、確認すべき業務サイクルに応じて設計 します。販売管理や会計など重要システムでは、少なくとも主要な締め処理を 1 回以上確認できる期間を確保することが安全です。単純なサブシステムなら数週間で足りることもありますが、四半期・年次処理まで確認するなら 3～12 ヶ月必要になることもあります。
まとめ｜クラウドマイグレーションは『6 パターン × 3 層 × 5 ステップ』で設計する
クラウドマイグレーションの成否は、『移行パターン（What）』『移行先層（Where）』『進め方プロセス（How）』の 3 つを業務要件と制約条件に照らして往復しながら検討できているか で決まります。コスト削減だけを目的にするのではなく、コスト構造の転換・拡張性・運用負荷軽減 の複数価値で評価することが重要です。
- 6 つの移行パターン：リフト＆シフト・リプラットフォーム・リファクタリング・リパーチェス・リタイア・リテイン（7R のうち Relocate を除く、中堅企業で検討頻度が高い 6 つ）
- 3 つの移行先層：IaaS（AWS／Azure／GCP／国産）／PaaS／SaaS
- 5 つのプロセスステップ：現状把握 → 評価 → 計画 → 実行 → 運用最適化
- 意思決定の進め方：業務要件から移行先層の仮説を置く → ベンダー候補を比較する → 移行パターンと整合するか見直す（往復型）
- サブシステム単位の最適化：『すべて同じパターン・同じ層』を避け、業務独自性に応じて組み合わせる
- 判断のコツ：初期費用ではなく 5 年 TCO（簡易式：初期費用＋月額費用×60 ヶ月＋運用人件費）で比較。リフト＆シフトは保守切れ対応に有効だが、レガシー依存が残る場合は将来の再投資を見込む
株式会社クオンツでは、『現状システムの棚卸し』『6 パターン × 3 層の組み合わせ設計』『5 年 TCO 試算』『クラウドマイグレーションプロジェクト支援』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のシステム規模・業務要件・予算感に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
