クラウド移行とは？7つの方式と手順・費用・注意点をわかりやすく解説

クラウド移行とは、オンプレミスなど自社で運用しているサーバーやシステム、データを、クラウドサービスの環境へ移すことです。移す範囲はサーバー1台から基幹システム全体まで幅があり、移し方も、そのまま移す方法から、作り直して移す方法まで複数あります。本記事では、クラウド移行の意味、移行方式の7つの分類、メリットとデメリット、手順、費用の考え方、移行後の運用、注意点、クラウドからデータを取り出す方法までを整理します。内容は、2026年10月22日時点の総務省・公正取引委員会・IPA・AWS・Microsoftなどの公開情報と、各サービスの商品ページにもとづきます。

目次

開く

閉じる

1. クラウド移行とは｜既存のシステムやデータをクラウド環境へ移すこと
2. クラウド移行の方式｜7つの分類(7R)と、システムごとの仕分け
3. クラウド移行のメリットとデメリット
4. クラウド移行の手順｜3つのフェーズと、実務の8ステップ
5. クラウド移行の費用の考え方｜移行時の費用と、移行後の費用に分けて見る
6. クラウド移行後の運用｜責任範囲と、監視・設定・端末環境の体制を決める
7. クラウド移行の注意点とリスク｜失敗しやすい6つのポイント
8. クラウドからデータを移す方法｜別のクラウドへ移す、パソコンに取り出す
9. よくある質問(FAQ)
10. まとめ｜クラウド移行で押さえたい7つのこと
11. 参考文献

クラウド移行とは｜既存のシステムやデータをクラウド環境へ移すこと

クラウド移行とは、オンプレミスなど自社で運用しているサーバー、アプリケーション、データを、クラウドサービスの環境へ移すことです。

移す対象は、サーバー(OSを含む)、業務アプリケーション、データベース、ファイルなどです。移す向きは1つではありません。AWSの移行サービスの案内では、オンプレミスのサーバーだけでなく、他のパブリッククラウドで動くアプリケーションをAWSへ移すことも対象に挙げています(AWS Application Migration Service)。また公正取引委員会の報告書は、利用者がクラウドから別のクラウドへ、または自社のオンプレミスへ移れることを前提に、競争政策上の考え方を整理しています。

移す向き	内容
オンプレミスからクラウド	自社で保有するサーバーやシステムを、クラウドの環境へ移す。一般にクラウド移行と言うときは、この向きを指すことが多い
クラウドから別のクラウド	利用中のクラウドから、別の事業者のクラウドへ、または同じ事業者の別のリージョンやアカウントへ移す
クラウドからオンプレミス	利用中のクラウドから、自社の環境へ戻す。公正取引委員会の報告書でも、移行先の選択肢として挙げられている

オンプレミスそのものの意味と構成要素は、別の記事で整理しています(オンプレミス環境とは)。本記事は、そこから先の「どう移すか」に絞って解説します。

移行を検討する企業は多く、総務省の令和7年通信利用動向調査によると、クラウドサービスを一部でも利用している企業は83.5%で、全社的に利用している企業は60.0%でした。利用している用途で多いのは、ファイル保管・データ共有(73.3%)、社内情報共有・ポータル(61.4%)、電子メール(57.4%)です(総務省「令和7年通信利用動向調査の結果」)。業務への影響が比較的小さい用途から使い始める企業が多いことが分かります。

クラウド移行は、移して終わりではありません。移したあとは、サーバーの稼働を見守る監視と、止まったときの一次対応を、だれが担うかを決める必要があります。移行先がAWSの場合の一例が、GMOグローバルサイン・ホールディングス株式会社のAWS監視・運用 マネージドクラウド for AWSです。商品ページでは、運用監視ツールをAmazon CloudWatch、Zabbix、Mackerelから選べることと、24時間365日の有人監視体制で人手不足や夜間・休日の対応に備えられることが、おすすめのポイントとして紹介されています(2026年10月22日確認)。注意点は、障害発生時の一次対応が手順書に沿った復旧を基本とすることで、自社の要件に合わせるオプションも用意されています。対象はAWSの環境で、料金はプランによって異なるため、資料や公式サイトで確認してください。

基本の要件は24時間365日の監視でしたが、CloudCREW の提案にはAWS認定資格をもったSEによるサポートを受けられるメニュー（※）がありました。

AWS事例(ジャスネットコミュニケーションズ株式会社。依頼の決め手として掲載) 出典：導入事例ページ

クラウド移行の方式｜7つの分類(7R)と、システムごとの仕分け

クラウド移行の方式は、AWS規範ガイダンスでは、リタイア、リテイン、リホスト、リロケート、再購入、リプラットフォーム、リファクタリングの7つ(7R)に分類されます。

クラウド移行は、すべてのシステムを同じ方法で移すものではありません。システムごとに、移さない、置き換える、そのまま移す、一部を直して移す、作り直す、のどれを選ぶかを決めます。AWS規範ガイダンスの「移行戦略について」は、次の7つを挙げています(AWS規範ガイダンス「移行戦略について」)。

方式	内容(AWS規範ガイダンスの説明)	検討しやすい場面の例
リタイア	廃止またはアーカイブするアプリケーションの移行戦略。廃止すると、そのアプリケーションスタック内のサーバーをシャットダウンできる	使われなくなったシステムや、役目を終えたデータ
リテイン	ソース環境に保持するアプリケーション、または移行する準備ができていないアプリケーションの戦略。将来移行することも選べる	連携先やライセンス、社内規程の都合で、今は移せないもの
リホスト	アプリケーションを変更せずに、ソース環境からクラウドへ移動する。リフトアンドシフトとも呼ばれる	保守期限が近く、短い期間で環境だけ移したいもの
リロケート	多数のサーバーを、特定の時点でオンプレミスのプラットフォームから、クラウドバージョンのプラットフォームに転送する。新しいハードウェアの購入、アプリケーションの書き換え、既存オペレーションの変更は必要ない	仮想化基盤ごと、まとめて移したい場合
再購入	アプリケーションを別のバージョンまたは製品に置き換える。ドロップアンドショップとも呼ばれる。新しいアプリケーションは、既存のものより多くのビジネス価値を提供する必要がある	会計、電話、グループウェアなど、SaaSで代替できるもの
リプラットフォーム	クラウドに移行し、効率的な運用、コスト削減、クラウド機能の活用のために、ある程度の最適化を行う。リフト、ティンカー、シフトとも呼ばれる。例は、Microsoft SQL ServerデータベースをAmazon RDS for SQL Serverへ移すこと	アプリケーションは変えず、データベースなど一部だけを、クラウドのサービスに替えたいもの
リファクタリング(リアーキテクト)	クラウドネイティブ機能を最大限に活用して、俊敏性、性能、拡張性を高めるために、クラウドへ移行しアーキテクチャを変更する	利用が増える見込みがあり、作り自体を見直す価値があるもの

(右の列は、各方式の定義から一般的な考え方を整理したもので、個別の判断は、システムの要件とライセンスを確認して行ってください。)国内の解説では、リホスト、リプラットフォーム、リファクタリング、リビルド、リプレイスの5つに整理するものもあります(ARI「クラウド移行とは？種類やメリット・デメリット」)。呼び方や分け方は解説によって異なるため、社内で使うときは、どの分類を基準にするかをそろえておくと話が通じやすくなります。

システムごとの仕分けの流れ

7つの方式は、次の順に問いかけると、システムごとに当てはめやすくなります(上の7Rの定義にもとづく進め方の例です)。

1. 廃止してよいか: 使われていない、または役目を終えているなら、リタイアにする
2. 今は移せない理由があるか: 連携先、ライセンス、社内規程などで難しいなら、リテインにして、見直す時期を決める
3. SaaSで置き換えられるか: 会計や電話など、同じ役割のSaaSがあるなら、再購入を検討する。たとえばクラウド会計やクラウドPBXは、その例です
4. 変更せずに移したいか: まず環境だけ移すなら、リホスト(または仮想化基盤ごとのリロケート)にする
5. 一部だけ最適化したいか: データベースなどを、クラウドのサービスに替えるなら、リプラットフォームにする
6. 作りから見直す価値があるか: 拡張性や俊敏性を高めたいシステムは、リファクタリングを検討する。時間と費用の負担が大きいため、対象を絞る

基幹システムのように、止まると事業への影響が大きいものを移す場合の論点は、基幹システムをクラウド化する必要性とはで、メリット・デメリットと注意点を整理しています。

クラウド移行のメリットとデメリット

クラウド移行のメリットは、設備の保有と保守の負担を減らせることと、場所や機器を選ばず使えることで、デメリットは、設定や運用の責任が利用者に残ることと、利用料が従量で変わることです。

メリット

総務省の令和7年通信利用動向調査で、クラウドサービスを利用する理由(複数回答)の上位は、次のとおりです(総務省「令和7年通信利用動向調査の結果」)。

クラウドサービスを利用する理由(総務省 令和7年調査)	割合
場所、機器を選ばずに利用できるから	50.7%
安定運用、可用性が高くなるから	45.1%
資産、保守体制を社内に持つ必要がないから	42.8%
災害時のバックアップとして利用できるから	38.7%
既存システムよりもコストが安いから	19.4%

メリットとして挙げられやすい、設備投資や保守の負担の軽減、利用量に応じた拡張、災害への備えは、上の理由とも重なります。一方、「既存システムよりもコストが安いから」を挙げた企業は19.4%にとどまり、移行すれば必ず安くなるとは限らないことも読み取れます。費用の見方は、後の節で整理します。

デメリット

1. 設定や運用の責任が利用者に残る: Microsoftの説明では、データ、エンドポイント、アカウント、アクセス管理は、デプロイの種類に関係なく、常に利用者側の責任です(Microsoft Learn「クラウドにおける共同責任」)。物理設備の運用は事業者に移っても、設定ミスや権限の管理は自社の仕事として残ります
2. 利用料が従量で変わる: 使った量に応じて請求が変わるため、想定以上の利用で費用が増えることがあります。請求と利用状況を定期的に確認する仕組みが必要です
3. インターネット接続が前提になる: 回線や社内ネットワークに問題があると、業務に影響が出ます。クラウド側が動いていても、手元の環境が原因で使えないこともあります
4. カスタマイズに制約が出ることがある: 標準化された機能を使うため、自社独自の業務の再現や、既存システムとの連携に制約が出る場合があります
5. 移行中と移行後に、現場の混乱が起きやすい: 画面や手順が変わるため、周知と教育が欠かせません
6. 乗り換えにくくなることがある: 公正取引委員会の報告書では、別のクラウドへ切り替えるときの技術上、契約上、経済上の制約が論点に挙がっています。詳しくは、注意点の節で扱います

クラウド移行の手順｜3つのフェーズと、実務の8ステップ

クラウド移行の手順は、AWS規範ガイダンスでは評価、準備、移行とモダナイズの3フェーズに分けられ、実務では、目的の設定から運用・改善までの8ステップで考えると進めやすくなります。

AWS規範ガイダンスの「大規模な移行のフェーズ」は、移行を3つのフェーズに分けています(AWS規範ガイダンス「大規模な移行のフェーズ」)。評価フェーズは、移行のビジネスケースを作る段階で、組織の準備状況の評価や、関係者の調整を行います。準備フェーズは、移行先の土台(ランディングゾーン)や、セキュリティと運用の仕組みを整え、チームが変化に備える段階です。移行とモダナイズフェーズでは、標準運用手順(ランブック)を作ったうえで、移行を実施し、管理・改善します。ガイダンスは、この3つを順番に実行することを推奨しています。大規模な移行向けの資料ですが、順序の考え方は、小さな移行にも当てはまります。

これを、自社で進めやすい8つのステップに置き換えると、次のとおりです(3フェーズの考え方にもとづく整理の例です)。

ステップ	やること	確認のポイント
1. 目的と範囲を決める	なぜ移すのか(保守期限、運用負担、拡張性、事業継続など)と、移す範囲を決める	目的が曖昧だと、移したあとに効果を判断できない
2. 棚卸しをする	サーバー、アプリケーション、データ、つながっているシステム、保守期限、担当者を一覧にする	一覧にない連携が、切替え時のトラブルになりやすい
3. 方式で仕分ける	前の節の7Rで、システムごとに、移す、残す、置き換える、やめるを決め、優先順位を付ける	影響の小さいものから始める
4. 移行先と事業者を選ぶ	SaaS、PaaS、IaaSのどれにするか、どの事業者にするかを決める。責任範囲と、契約終了時のデータの取り出し方も確認する	「出るとき」の条件は、契約前に確認する
5. 計画と体制を決める	スケジュール、役割分担、セキュリティと運用の方針、手順書(ランブック)を決める	設定と権限の管理を、だれが担うかを決める
6. テスト移行をする	影響の小さいシステムや一部のデータで試し、動作とデータを確認する	本番と同じ手順で試す
7. 本番に切り替える	移行を実施し、動作とデータを検証する。切替えに失敗したときの戻し方も用意する	業務への影響が少ない時間帯を選ぶ
8. 運用して見直す	監視、バックアップ、費用の確認を続け、使い方や設定を見直す	移したあとの運用体制を、移行前に決めておく

移行の作業を支える道具も、各事業者から提供されています。たとえばAWS Application Migration Serviceは、物理サーバーやVMware vSphere、Microsoft Hyper-Vなどの環境をAWSへ移すサービスで、レプリケーション(複製)の間も通常の業務を続けられると説明されています(AWS Application Migration Service)。AWS Database Migration Serviceは、データベースを最小限のダウンタイムで移すサービスで、移行が完了するまで移行元のシステムを稼働させ続けられると説明されています(AWS Database Migration Service)。他の事業者にも移行を支援する仕組みがあるため、移行先を決めたら、その事業者の公式の資料で確認してください。

実際の流れの一例として、ジャスネットコミュニケーションズ株式会社の事例では、約10年前からデータセンターにサーバーを置いてWebサイトを運営していたところ、複数のサービス提供や事業規模の拡大で従来の環境では対応が難しくなり、クラウドへ切り替える方針にしたと紹介されています。移行作業は2022年の秋から年末にかけて行い、AWS環境への移行は社内のチームだけでできた一方、移行後の運用では、24時間365日の監視を外部に相談したとあります(AWS事例「ジャスネットコミュニケーションズ株式会社」)。移行の作業と、移行後の運用は、分けて考えられることが分かります。

ここまでの手順を、自社の状況に当てはめて確認できるセルフチェックを用意しました。移行を始める前に、抜けがないかを確かめてみてください。

クラウド移行の費用の考え方｜移行時の費用と、移行後の費用に分けて見る

クラウド移行の費用は、調査や移行作業、並行稼働などの移行時の費用と、利用料や運用、教育などの移行後の費用に分けて見積もる必要があり、クラウドにすれば必ず安くなるとは限りません。

費用を見落とす原因の多くは、移行時だけ、または利用料だけを見ることです。次のように、時期ごとに費目を並べると、抜けを防げます(費目の整理の例で、金額の目安ではありません)。

時期	費目	見落としやすい点
移行時	棚卸し・調査	一覧がないと、調査に時間がかかる
移行時	移行作業(自社の工数、または外部への委託)	自社で行う場合も、担当者の工数がかかる
移行時	並行稼働	切替えまで、旧環境と新環境の両方の費用がかかることがある
移行時	テスト・教育・周知	現場への説明や、手順書の作成が必要
移行後	利用料(従量・定額)	利用量が増えると、請求も増える
移行後	データ転送	データを取り出す方向に費用がかかる設定がある事業者もあるため、料金の条件を確認する
移行後	監視・運用・バックアップ	自社で担うか、外部に任せるかで、費用の形が変わる
移行後	見直しと最適化	使われていない環境が残ると、費用がかかり続ける

データ転送については、公正取引委員会が2022年6月に公表した「クラウドサービス分野の取引実態に関する報告書」に、論点が示されています。報告書は、有力なクラウド提供事業者が不当に高額なデータ転送料を設定することは、利用者が他のクラウドを使うことを妨げるなどの市場閉鎖効果が生じる場合には、独占禁止法上問題となり得るとしています。また、利用者からは、入力時は無料でも、出力時の転送料が高額だと、蓄積したデータの移行のハードルになるとの指摘があったと紹介しています(公正取引委員会「クラウドサービス分野の取引実態に関する報告書(概要)」)。事業者ごとの条件は異なるため、移行先を選ぶ段階で、データの出し入れの条件を確認することが大切です(本記事は法的助言ではありません)。

AWSに移したあとの利用料の支払いを、円建ての請求書にそろえたい場合の一例が、同じくGMOグローバルサイン・ホールディングス株式会社のCloudCREW AWS請求代行です。商品ページでは、AWSの定価から値引きを受けて利用できること、日本円建ての請求書に対応し、後払いオプションで支払い期限を延長できること、初期費用や代行手数料などの各種手数料がかからないこと、クラウドのアセスメント支援を無料で受けられることが紹介されています(2026年10月22日確認)。注意点は、監視や運用サービスを利用する場合は有料オプション扱いになることです。対象はAWSの利用料で、料金はプランによって異なるため、資料や公式サイトで確認してください。

AWS請求代行サービスによってAWS利用料のコストを大きく抑えることができ、取り組み当初に抱えていた最も大きな課題を解決できています。

AWS事例(株式会社パム。導入後の成果として掲載) 出典：導入事例ページ

クラウド移行後の運用｜責任範囲と、監視・設定・端末環境の体制を決める

クラウド移行後も、データ、ID、設定の責任は利用者に残るため、監視、バックアップ、アカウント管理、費用の確認、端末とネットワークの管理を、だれがどう担うかを、移行前に決めておく必要があります。

IPAの「中小企業のためのクラウドサービス安全利用の手引き」は、クラウドの固有リスクとして、インターネットを利用すること、多数の利用者で共用すること、複数の事業者で構成されることの3点を挙げ、選択6項目・運用4項目・セキュリティ管理5項目の15項目のチェックシートを示しています(IPA「中小企業のためのクラウドサービス安全利用の手引き」)。また総務省は、設定の不備による事故を防ぐために、「クラウドサービス利用・提供における適切な設定のためのガイドライン」を示しています(総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」)。これらを土台に、移行後の運用で決めておく項目を整理すると、次のとおりです(整理の例です)。

運用の項目	決めておくこと	確認のポイント
監視と障害対応	何を監視し、止まったときに、だれが一次対応するか。夜間・休日の対応者	担当者の兼務で、24時間の対応が回るか
バックアップと復元	何を、どこに、どの頻度で保存し、戻せることをどう確認するか	事業者側の仕組みと、自社で取るものを分けて把握する
アカウントと権限の管理	管理者権限を持つ人、退職・異動時の削除手順、多要素認証の有無	アカウントとアクセス管理は、利用者側の責任として残る
設定の見直し	公開範囲や権限の設定を、定期的に確認する担当と頻度	総務省のガイドラインの設定項目を、チェックの基準にする
費用の確認	請求と利用状況を、毎月だれが確認するか	使われていない環境が残っていないか
端末とネットワーク	社内のパソコン、回線、ネットワーク機器の不調を、だれが切り分けるか	クラウド側に問題がなくても、手元の環境が原因で使えないことがある

複数のクラウドを使う場合の管理の考え方は、クラウド管理ツールとはで整理しています。ここでは、移行前後の運用を支える選択肢を、役割の違いで並べます(2026年10月22日に各商品ページで確認した内容です)。3サービスは、いずれも、クラウド移行の作業そのものを請け負うサービスとして紹介されているものではありません。

AWS監視・運用 マネージドクラウド for AWSは、移行先がAWSの場合の監視と運用の一例として、前の節で紹介しました。CloudCREW AWS請求代行も、利用料の管理の一例として紹介しています。もう1つの観点が、端末とネットワークです。クラウドに移しても、社内のパソコンや回線、ネットワーク機器は自社に残ります。画面が開けない原因が、クラウドではなく手元にある場合、原因の切り分けは社内の担当者の仕事になります。PC・ネットワークの相談先を外部に持つ選択肢の一例が、株式会社庚伸のDr.オフィスSystanです。商品ページでは、電話、遠隔、訪問の3段階でトラブルに対応する体制が紹介され、定額制の料金設定で追加料金が不要な点が、おすすめのポイントとして挙げられています(2026年10月22日確認)。注意点は、トラブル復旧を目的としない「データ移行」は別途見積もりとなることです。クラウド移行の作業そのものが対象になるかは、商品ページに記載がないため、資料で範囲を確認してください。料金はプランによって異なるため、資料や公式サイトで確認してください。

一番良かったと思うところは、その場でリモート接続をして早く解決してくださるという部分です。

Dr.オフィスSystan 導入事例(有限会社ヒアリングテクノ。導入後の評価として掲載) 出典：導入事例ページ

クラウド移行の注意点とリスク｜失敗しやすい6つのポイント

クラウド移行で失敗しやすいのは、目的が曖昧なまま移すこと、設定ミス、移行中のデータとダウンタイム、連携とライセンスの見落とし、人材と周知の不足、そして出るときの条件を決めていないことの6つです。

1. 目的が曖昧なまま移す: 保守期限、運用負担、拡張性など、移す目的を決めておかないと、移したあとに効果を判断できません。総務省の調査でも、利用の理由は、場所を選ばない、安定運用、保守体制を持たなくてよいなど、企業によって異なります
2. 設定ミスとセキュリティ: 責任範囲の表で見たとおり、データ、ID、設定は利用者の責任として残ります。IPAの手引きの15項目と、総務省の設定ガイドラインを、移行前のチェックに使えます
3. 移行中のデータ損失とダウンタイム: テスト移行を行い、切替え手順と戻し方を決め、旧環境を検証が終わるまで残します。移行ツールは、複製しながら業務を続けられる仕組みを持つものがあります
4. 既存システムとの連携、ライセンス、性能要件、サポート期限の見落とし: 連携先の一覧を作り、ライセンスの条件を確認します。処理性能や、業界の規制・社内規程で求められるデータの扱いも、システムごとに移す前に確かめます。サポート期限は日付で管理します。たとえばWindows Server 2016の延長サポートは、2027年1月に終了します(Microsoft Lifecycle「Windows Server 2016」)
5. 人材と周知の不足: 移行後は、画面や手順が変わります。現場への説明と、クラウドの専門知識を持つ人材の確保・育成が必要です。公正取引委員会の報告書も、利用者が取り組むことが推奨される事項として、専門知識を有する人材の確保・育成を挙げています
6. 出るときの条件を決めていない: 次の項で説明します

出るときの条件を、契約前に決めておく

公正取引委員会の報告書は、利用者が取り組むことが推奨される事項として、次を挙げています。契約する事業者のサービスから退去する必要が生じることも念頭に、契約を終了する条件(許容できる費用増加の上限、技術の陳腐化への対応方針)を、あらかじめ決めておき、その条件に照らして定期的に検証すること。契約を終了する場合に、クラウド上に保存したデータを完全な形で取り出す方法が提供されているか、提供されている場合はその方法を確認すること。特に移行させる可能性がある重要な情報システムは、異なる事業者のクラウドでも動作する、ポータビリティの高い技術(オープンソースソフトウェア、コンテナなど)を優先的に採用するなど、移行しやすい設計にすること(公正取引委員会「クラウドサービス分野の取引実態に関する報告書(概要)」)。

確認する項目	契約前に確認すること
退出の条件	どの条件になったら、そのサービスの利用をやめるか(費用の上限、サービスの終了など)を、社内で決めておく
データの取り出し方	保存したデータを、完全な形で書き出せるか。方法(画面、API、移行ツール)と形式は何か
移行の条件	他社への移行や、オンプレミスへの戻しが可能か。可能な場合の方法、費用、手続き
システムの設計	重要なシステムは、別の事業者でも動かせる技術を使うか

(上の表は、公正取引委員会の報告書の推奨事項を、確認項目に直した整理です。本記事は法的助言ではなく、個別の契約の判断は、専門家に確認してください。)オンプレミスから移す前に、手元の環境の棚卸しを済ませておきたい場合は、オンプレミス環境とはの運用タスクの表が、そのまま台帳に使えます。

クラウドからデータを移す方法｜別のクラウドへ移す、パソコンに取り出す

クラウドからデータを移すときは、移す前にそのサービスがデータの書き出し(エクスポート)に対応しているかを確認し、形式、容量、転送の条件を確かめ、書き出したデータが移行先で開けることを検証してから切り替えます。

「クラウドからデータを移行するにはどうすればいいか」「クラウドのデータをパソコンに移す方法はあるか」という疑問は、どちらも、書き出し(ダウンロード)の方法と、移した先で使える形かどうかが分かれ目になります。手順は、移す先を問わず、次の順で考えると抜けが減ります。

1. 書き出しの可否と方法を確認する: そのサービスに、データを書き出す機能(エクスポート、ダウンロード、API)があるか、公式のヘルプで確認します。公正取引委員会の報告書も、利用者がデータの取り出し方法を、契約前に確認することを推奨しています
2. 対象の範囲と容量を確認する: どのデータを、どれだけ移すかを決めます。サービスによって、1回に書き出せる量や、期間の制限が異なります
3. 形式を確認する: 書き出されるファイルの形式が、移行先で開けるか、取り込めるかを確かめます。形式が合わないと、変換の作業が必要になります
4. 転送の条件と費用を確認する: データを出す方向に、転送料がかかる場合があります。事業者の料金の条件で確認します
5. 一部を試して検証する: 全量を移す前に、一部のデータを書き出して移行先に取り込み、内容が欠けていないかを確かめます
6. 全量を移し、旧環境は検証が終わるまで残す: 検証が終わってから、旧環境を解約します。契約の終了日と、データの保管期間も確認します

移す先	考え方	確認すること
パソコン(手元の端末)	各サービスの書き出し、ダウンロードの機能で保存する	保存先の容量、暗号化、持ち出しの社内ルール。個人情報や機密情報を含む場合は、取り扱いを社内の規程に従う
別のクラウド	書き出しと取り込みの機能、または事業者の移行ツールを使う	形式の互換性、転送の条件、移行中の旧環境の扱い
自社のオンプレミス	書き出したデータを、自社のサーバーに取り込む	受け入れ先の容量と、アクセス権の設計

クラウドから取り出したデータを、社内のパソコンや自社の環境で扱うことが増えると、端末やネットワークの管理の手間も増えます。移行後の手元の環境の不調に備えて、相談先を持っておきたい会社には、前の節で紹介した選択肢の資料が参考になります。

よくある質問(FAQ)

Q1. クラウド移行とは何ですか？

A. クラウド移行とは、オンプレミスなど自社で運用しているサーバー、アプリケーション、データを、クラウドサービスの環境へ移すことです。あるクラウドから別のクラウドへ移す場合も、クラウド移行と呼ばれます。移し方は、AWS規範ガイダンスの7R(リタイア、リテイン、リホスト、リロケート、再購入、リプラットフォーム、リファクタリング)のように、複数の方式に分けられます。

Q2. クラウド移行の手順は？

A. 目的と範囲を決める、棚卸しをする、7Rなどの方式でシステムごとに仕分ける、移行先と事業者を選ぶ、計画と体制を決める、テスト移行をする、本番に切り替える、運用して見直す、の順で進めます。AWS規範ガイダンスでは、評価、準備、移行とモダナイズの3フェーズに分けて、順番に実行することを推奨しています。

Q3. クラウド移行の注意点は？

A. 目的が曖昧なまま移すこと、設定ミス、移行中のデータ損失とダウンタイム、既存システムとの連携やライセンス、サポート期限の見落とし、人材と周知の不足、出るときの条件を決めていないことに注意が必要です。データ、ID、設定の責任は、クラウドに移しても利用者に残ります。

Q4. クラウドからデータを移行するにはどうすればいいですか？

A. まず、そのサービスにデータの書き出し(エクスポート)の機能や方法があるかを確認し、形式、容量、転送の条件を確かめます。一部を試して移行先で開けることを検証してから全量を移し、旧環境は検証が終わるまで残します。契約前に、データの取り出し方を確認しておくことが、公正取引委員会の報告書でも推奨されています。

Q5. クラウドのデータをパソコンに移す方法はありますか？

A. 多くのサービスには、データをダウンロードしたり、書き出したりする機能があります。サービスごとに操作や制限が異なるため、公式のヘルプで確認してください。パソコンに保存した後は、保存先の容量や暗号化、持ち出しに関する社内ルールに従い、個人情報や機密情報の扱いに注意が必要です。

Q6. クラウド移行をすると、費用は安くなりますか？

A. 安くなるとは限りません。総務省の令和7年通信利用動向調査では、クラウドを利用する理由として「既存システムよりもコストが安いから」を挙げた企業は19.4%で、「資産、保守体制を社内に持つ必要がないから」の42.8%を下回りました。移行時の費用と、利用料、運用、データ転送などの移行後の費用に分けて見積もることが大切です。

まとめ｜クラウド移行で押さえたい7つのこと

クラウド移行は、システムごとに方式を選び、移行時と移行後の費用、運用、出るときの条件まで含めて決めることが大切です。移して終わりではなく、移したあとの責任範囲と体制を、移行前に決めておきます。

1. クラウド移行とは、オンプレミスなどのサーバー、アプリケーション、データを、クラウドの環境へ移すこと。クラウドから別のクラウドへ移す場合も含まれる
2. 方式は、AWS規範ガイダンスの7R(リタイア、リテイン、リホスト、リロケート、再購入、リプラットフォーム、リファクタリング)で、システムごとに仕分ける
3. メリットは、保守体制を持たなくてよいことや、場所を選ばず使えること。デメリットは、設定や運用の責任が利用者に残ること、利用料が従量で変わること
4. 手順は、目的の設定、棚卸し、仕分け、移行先の選定、計画、テスト移行、本番切替え、運用と見直しの8ステップで進める
5. 費用は、移行時と移行後に分けて見積もる。総務省の調査でも、「コストが安い」を理由に挙げた企業は19.4%にとどまる
6. 契約前に、退出の条件とデータの取り出し方を確認しておく(公正取引委員会の報告書が推奨している事項)
7. 移したあとの監視、利用料の管理、端末とネットワークの相談先を、外部に任せる選択肢も含めて資料で比べ、体制を決める

まずは、いま動いているサーバー、アプリケーション、データを、保守期限つきの一覧にするところから始められます。

参考文献

• 総務省「令和7年通信利用動向調査の結果」https://www.soumu.go.jp/johotsusintokei/statistics/data/260529_1.pdf
• 公正取引委員会「クラウドサービス分野の取引実態に関する報告書(概要)」令和4年6月https://cms03.jftc.go.jp/houdou/pressrelease/2022/jun/digital/gaiyou25.pdf
• 公正取引委員会「実態調査関係」https://www.jftc.go.jp/dk/digital/survey.html
• IPA「中小企業のためのクラウドサービス安全利用の手引き」https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_7.pdf
• 総務省「クラウドサービス利用・提供における適切な設定のためのガイドライン」https://www.soumu.go.jp/main_content/000843318.pdf
• AWS規範ガイダンス「移行戦略について」https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• AWS規範ガイダンス「大規模な移行のフェーズ」https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-guide/phases.html
• AWS Application Migration Servicehttps://aws.amazon.com/jp/application-migration-service/
• AWS Database Migration Servicehttps://aws.amazon.com/jp/dms/
• Microsoft Learn「クラウドにおける共同責任」https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
• Microsoft Lifecycle「Windows Server 2016」https://learn.microsoft.com/ja-jp/lifecycle/products/windows-server-2016
• ARI「クラウド移行とは？種類やメリット・デメリット」https://ari-jp.blog/posts/cloud-migration
• AWS事例「ジャスネットコミュニケーションズ株式会社」https://managed.gmocloud.com/case/case-jusnet.html
• AWS事例「株式会社パム」https://managed.gmocloud.com/case/pam.html
• Dr.オフィスSystan 導入事例「有限会社ヒアリングテクノ」https://www.koushin.co.jp/archives/works/it_health_management