公開2026.07.10更新2026.09.22 Webシステム

クラウド移行の進め方｜7Rの選び方から費用試算・切り替えまでの手順を発注者視点で解説

オンプレミスのサーバーやシステムをクラウドへ移す作業は、機材を載せ替えるだけでは終わりません。移行目的の設定、対象システムの棚卸し、リホストやリファクタリングといった移行方式の選び方、初期費用と月額料金を分けた費用試算、責任共有モデルを踏まえたセキュリティ設計まで、判断のポイントが工程ごとに変わります。この記事では、クラウド移行の進め方を計画立案から本番切り替えまでの7つのステップに沿って整理し、AWS・Azure・Google Cloudの公式ドキュメントで確認できる基準と、現場で叩くコマンドを添えて解説します。あわせて移行を急ぐべきでない場面と、自社と外部委託先の役割分担の考え方まで、発注する側の視点でまとめました。

まとめ：クラウド移行の進め方で先に押さえる結論

クラウド移行は「全システムを一度に移す」プロジェクトではなく、目的と対象を絞って優先度の高いものから移す段階的な取り組みです。最初に決めるのは移行のゴール、つまりコスト削減なのか拡張性の確保なのか運用負荷の軽減なのかで、この目的が後工程の移行方式やサービス選定をすべて左右します。

移行方式は、AWSが公式ドキュメントで整理している7つの移行戦略（7 Rs）から対象システムごとに選びます。リタイア・リテイン・リホスト・リロケート・リパーチェス・リプラットフォーム・リファクタリングの7つで、以前よく使われた「6R」にリロケートを加えた構成です。まずは改修の少ないリホストで実績を作り、効果の大きいものだけをリファクタリングへ進めるのが現実的な進め方になります。

費用は初期の移行作業費と移行後の月額利用料を分けて試算し、データ転送量や予約割引まで含めて見積もります。セキュリティは責任共有モデルの守備範囲を利用者と事業者で線引きし、権限設計とログ監視の設定不備を移行のタイミングでまとめて直しておくと安全です。探索と評価を助ける無料ツールは3大クラウドすべてが用意しているので、勘で見積もる前に一度回しておきます。手順の詳細と、あえて移行しない判断の基準は本文で順に見ていきましょう。

クラウド移行を始める前に固める移行目的と対象システムの棚卸し

移行の失敗は、技術ではなく目的の曖昧さから生まれます。「他社が移しているから」という理由で着手すると、移行後に何を評価すればよいか分からず、コストだけが増える結果になりがちです。まずゴールと対象範囲を言語化するところから始めます。クラウドの料金体系やIaaS・PaaS・SaaSの種類といった前提知識は、クラウドとは何かをAWSの料金や仕組みから整理した記事で確認しておくと、この後の判断が進めやすくなります。

移行のゴールをコスト削減か拡張性かに絞り込む目的設定の考え方

移行目的は、大きくコスト削減・拡張性（スケーラビリティ）の確保・運用負荷の軽減・事業継続性（BCP）の強化に分かれます。目的が定まれば、測るべき指標も自ずと決まる。コスト削減が目的なら移行前後の月額インフラ費を、拡張性が目的なら繁忙期のリソース増減にかかる時間を、それぞれ移行前に基準値として記録しておきます。

目的は1つに絞り込む必要はありません。ただし優先順位はつけます。第一目的がコスト削減で、第二目的が運用負荷の軽減、というように重み付けしておくと、移行方式やサービスの選択で迷ったときの判断軸になる。目的を数値の基準とセットで持つことが、移行後に成果を説明できるかどうかの分かれ目です。

公共調達に関わる案件では、デジタル庁が公開しているデジタル・ガバメント推進標準ガイドライン群が、クラウドを第一候補として検討する原則や調達手続きの考え方を示しています。民間の案件でも、目的設定と評価指標の書き方を組み立てる際の下敷きとして参照できます。

サーバー・データ・アプリを洗い出す資産棚卸しと移行可否の分類

次に、移行対象になりうるシステムをすべて洗い出します。物理・仮想サーバー、データベース、アプリケーション、ネットワーク構成、外部連携、ライセンスまでを一覧化し、それぞれについて「クラウドに向くか」「移せるか」を一覧の上で仕分けていく。EOL（サポート終了）が近いOSやミドルウェアは、移行を機に更新する対象として印をつけます。時刻を32ビットで持つ古い基盤が抱える2038年問題とは？Unix時間のオーバーフローの仕組みと対策を実装者向けに解説も、移行を機に解消できる論点です。

棚卸しの段階で、移行の優先順位が見えてきます。基準は2つ。クラウド化の目的に合致していること、そして技術的な難易度が低いことです。この2条件を満たすシステムから着手すると、早い段階で成功体験が得られ、社内の合意形成も進みます。逆に、他システムと密結合していて切り離しにくいものは、単独で移さず後半のまとまった工程に回す。棚卸しの前提として、そもそもオンプレミスとクラウドをどの軸で比べ、どちらに残すべきかは、オンプレミスとクラウドの違いをコストや拡張性で比較し選び方まで整理した記事で確認できます。

稼働率とインバウンド接続から廃止候補を切り分ける棚卸しの実務手順

棚卸しで手が止まりやすいのが、「このサーバーは本当に使われているのか」の判断です。AWSの移行ガイドは、廃止（リタイア）候補を見分ける目安を数値で示しています。平均CPU使用率とメモリ使用率が5%を下回るものをゾンビアプリケーション、90日間の平均が5〜20%にとどまるものをアイドルアプリケーションと呼び、直近90日間にインバウンド接続がないものもあわせて廃止候補に挙げています（出典：AWS Prescriptive Guidance「About the migration strategies」）。感覚ではなく、この数値で仕分けると社内の議論が短くなります。

Linuxサーバーであれば、sysstatのログから日次の使用率を取り出せます。棚卸しシートに貼る数字は、次のような集計で機械的にそろえていきます。

# sysstat の日次ログから平均CPU使用率（アイドルの裏返し）を出す
sadf -d /var/log/sa/sa15 -- -u | awk -F';' 'NR!=1 {busy+=100-$NF; n++} END {print "avg_busy_percent:", busy/n}'

# 現在確立しているインバウンド接続の接続先ポートを重複なく並べる
ss -tan state established | awk 'NR!=1 {print $4}' | sort -u | head -n 50

ここで「誰も使っていない」と判明したサーバーは、移行せず廃止に回します。移行対象が1台減れば、設計・移送・試験・切り替えの4工程がまるごと消える。棚卸しの目的は移行計画を作ることだけでなく、移す必要のないものを外して母数を削ることにもあります。

オンプレミスからの移行方式7Rの違いと対象システム別の選定基準

クラウド移行の方式は、AWSの公式ドキュメントでは「7 Rs」として7つに整理されています。日本語の解説では「6R」という呼び方も残っていますが、これはハイパーバイザー単位でまとめて移すリロケートを含めない旧来の分類です。同じシステム群でも、1つの方式に統一する必要はありません。サーバー単位・アプリ単位で適した方式が異なるため、棚卸しした資産ごとに割り当てていきます。

リホスト・リプラットフォームなど7R各方式の特徴と向くケース

7Rは、既存の資産をどこまで作り替えるかで難易度と得られる効果が変わります。改修が少ない順に整理すると、次のようになります。

方式	概要	向くケース
リタイア	使わず廃止する	役目を終えたシステム
リテイン	当面オンプレに残す	移行効果が薄い資産
リホスト	構成を変えずそのまま移設	まず移して実績を作る
リロケート	基盤ごとまとめて移す	仮想化基盤を一括で移す
リパーチェス	SaaSに乗り換える	自社保守をやめたい
リプラットフォーム	一部をマネージド化	DBの運用を軽くしたい
リファクタリング	クラウド前提で再設計	拡張性を根本から直す

初めてクラウドに移す企業は、改修範囲が狭いリホストから入るのが定石です。信頼を積んだうえで、効果の大きいシステムだけをリプラットフォームやリファクタリングへ段階的に引き上げます。AWSの移行ガイドも、大規模移行ではリファクタリングを勧めておらず、リホスト・リロケート・リプラットフォームで移してから移行後にモダナイズする順序を推奨しています。作り替えと移送を同時にやると、問題が起きたときに原因の切り分けができなくなるためです。移行先をAWSに決めている場合は、方式ごとの割り当て方と移行ツールの選び方を扱ったAWS移行の7R戦略と移行ツールの選び方もあわせて確認してください。

移行難易度と運用コストで見る方式選定の判断基準と優先順位付け

方式選びで迷ったら、2つの軸で並べます。1つは移行の難易度、もう1つは移行後の運用コストと得られる効果です。難易度が低く効果も見込めるものを最優先にし、難易度が高いものは後半に回す。最初からリファクタリングで理想形を目指すと、期間もコストも膨らみ、途中で頓挫しやすくなります。

現実的な優先順位は、リタイア（廃止できるものを先に消す）とリホスト（すぐ移せるものを移す）を前半に、リファクタリング（作り替えが必要なもの）を後半に置く形です。廃止を先にやると、移行対象そのものが減り、後工程が軽くなります。すべてを移そうとしないことが、結果的に総コストを抑えました。

リテインを選ぶ条件も、公式ガイドが具体的に挙げています。データ保存場所の規制に従う必要がある、詳細な調査なしには移せない高リスク、先に移すべき依存システムがある、直前に大きな投資をして更新したばかり、社内の数名しか使わず移す意味がない、ベンダーのSaaS版の提供を待っている、クラウドに同等品のない専用ハードウェアに依存している、メインフレームや非x86のUnix環境である。この8条件のどれかに当たるなら、今回は見送って次の更新期に回す判断が妥当です。

クラウド移行でかかる費用の内訳と試算で見落としやすい継続コスト

クラウドは「使った分だけ払う」料金体系のため、移行後にコストが想定を超える例が起きます。原因の多くは、初期費用だけを見て継続費用を試算していないことです。費用は初期と月額に分けて捉えます。

初期の移行費用と月額利用料に分けて捉えるクラウド費用の全体像

初期費用には、移行設計・データ移送・テスト・切り替え作業といった一時的な工数が含まれます。月額費用は、仮想サーバーやストレージ、データベース、通信の従量料金です。この2つを混ぜて見積もると、移行直後は安く見えても運用が始まってから予算を超える、という食い違いが生じる。

試算では、移行前のオンプレミス総保有コスト（TCO）を基準に置きます。ハードウェア償却・保守・電気代・運用人件費まで含めた現行コストと、移行後の月額見込みを並べて初めて、削減効果を判断できる材料がそろう。AWSであればAWS Pricing Calculatorで構成を組み立てて月額の概算を出せます。その使い方と費用が変わる要因は、AWSの見積もりの取り方を発注視点でまとめた記事で具体的に解説しています。

データ転送量と予約割引で変わる移行後のランニングコストの試算

月額費用のうち、見落とされやすいのがデータ転送料（下り通信）です。クラウドからインターネットやオンプレミスへデータを出す通信は課金対象で、システム間の連携が多いと積み上がります。AWSの場合、インターネットへのデータ転送（アウト）は月100GBまで無料で、それを超えた分に従量課金がかかるとAmazon EC2 オンデマンド料金に明記されています。日次バッチで数十GBを社内へ戻す構成だと、この枠は初月で超える。移行設計の段階で、どのデータがどれだけ外へ出るかを想定しておきます。オンプレミスを残して併用するハイブリッド構成を取る場合の回線選定やアドレス設計は、ハイブリッドクラウド移行の接続方式・ネットワーク設計の解説で実装者向けに整理しています。

一方で、コストを下げる仕組みもあります。1年または3年の利用を約束するAWS Savings Plansは、公式ページでオンデマンド料金より最大72%低い水準になると説明されています。常時稼働するサーバーほど効果が大きい仕組みです。移行直後は従量のまま様子を見て、稼働が安定した本番サーバーから予約に切り替える。この2段構えが、無駄なく単価を下げる進め方になります。

クラウド移行前の現状把握を支える探索・評価ツールの選び方と使い分け

棚卸しと費用試算を手作業の表計算だけで進めると、台数が増えた時点で精度が落ちます。3大クラウドはいずれも、現状の構成と使用状況を集めて移行先のサイズと費用を見積もるツールを用意しており、移行先が決まる前の段階から使えます。

AWS・Azure・Google Cloudが無料で出す評価ツールの守備範囲

MicrosoftのAzure Migrateは、公式ドキュメントで無料サービスと明記されています。ワークロードの棚卸し、IaaS／PaaSの移行先候補に対する評価、移行計画の作成までを無償で行えて、課金が発生するのはパートナー製ツールを使う場合です。探索は軽量な仮想アプライアンスを社内に置く方式が推奨され、常時接続できない閉域環境向けにはスナップショットを取るコレクター方式も用意されています。VMware環境はエージェントレスでもエージェントベースでも移せる一方、Hyper-Vはホストに入れるプロバイダーエージェントを使うなど、基盤ごとに方式が分かれます。

AWS側は、リホストの自動化にAWS Application Migration Service（MGN）、データベースの移送にAWS Database Migration Service（DMS）が対応します。Google CloudならMigration Centerが探索から総保有コストの比較までをまとめて担う。どのツールも「探索して評価する」ところまでは無償か低コストで済むので、移行先を決める前に2社分を回して結果を比べると、見積もりの根拠が一段強くなります。

移行中のレプリケーション進捗をコマンドで確認する切り替え前の点検

移行ツールを入れたあと、実際に手を動かす局面で必要になるのが進捗の確認です。管理コンソールの画面を1台ずつ開くのは台数が増えると現実的ではないため、CLIで一覧を取ります。AWS MGNなら、レプリケーション状態を次のコマンドでまとめて確認できます。

# 移行中サーバーのレプリケーション状態を一覧で確認する
aws mgn describe-source-servers --region ap-northeast-1 \
  --query 'items[].[sourceProperties.identificationHints.hostname,dataReplicationInfo.dataReplicationState]' \
  --output table

# 本番切り替えの前にテストインスタンスを起動して動作を確かめる
aws mgn start-test --source-server-id s-1234567890abcdef0 --region ap-northeast-1

ここで見るべきはレプリケーションが完了しているかどうかだけではありません。テストインスタンスを起動して、アプリが上がるか、外部連携先に届くか、性能が落ちていないかを確かめます。レプリケーション完了と移行完了は別の事実で、前者だけを根拠に本番へ進むと切り替え当日に詰まる。テスト起動は何度でもやり直せるので、本番前に2回以上は通しておきます。

責任共有モデルを踏まえたクラウド移行時のセキュリティ設計の勘所

オンプレミスでは自社がすべてを守りますが、クラウドでは事業者と利用者で守る範囲が分かれます。この線引きを誤ると、「事業者が守ってくれている」と思い込んだ領域が無防備なまま残る。移行はセキュリティ設計を見直す好機でもあります。

利用者と事業者の間で分かれる責任共有モデルの守備範囲の線引き

AWSの責任共有モデルは、事業者が「クラウドのセキュリティ」、つまりサービスを動かすハードウェア・ソフトウェア・ネットワーク・施設を守り、利用者が「クラウドにおけるセキュリティ」を担うと定義しています。利用者の守備範囲は選ぶサービスによって変わり、EC2のようなIaaSではゲストOSの更新とセキュリティパッチ、インスタンスに入れたアプリケーションの管理まで利用者側です。S3やDynamoDBのようにAWSがOSとプラットフォームまで運用するサービスでは、利用者はデータの管理（暗号化の選択を含む）と資産の分類に責任を負います。

分担が明確に分かれない領域もあります。公式ページは共有責任の例として、インフラ側の不具合修正はAWS・ゲストOSとアプリのパッチ適用は利用者というパッチ管理、インフラ機器の構成はAWS・ゲストOSとデータベースとアプリの構成は利用者という構成管理、そして自社の従業員教育は自社が行うトレーニングの3つを挙げています。移行前に、この3項目を自社の運用手順書に落とし込んでおくと引き継ぎで揉めません。クラウド特有のリスクと対策の全体像はクラウドセキュリティの守り方を整理した記事で扱っています。移行している最中に穴が空く時点と対策はクラウド移行のセキュリティにまとめました。

移行を機に見直す権限設計とログ監視の徹底でふさぐ設定不備のリスク

クラウドの事故で多いのは、外部からの高度な攻撃よりも、設定不備です。公開設定のままのストレージ、広すぎるアクセス権限、無効のままの監査ログ。いずれも移行時の初期設定で決まります。移行のタイミングで、最小権限の原則に沿って権限を絞り、操作ログと通信ログを取得・監視する仕組みを最初から組み込みましょう。

特に、移行作業中は一時的に強い権限を配りがちで、その権限が移行後も残る例が起きます。移行完了時に権限を棚卸しして、不要なものを削除する工程を計画に組み込む。設定の是正は、稼働後にやるより移行時にまとめて行うほうが手戻りが少なくて済みます。中小企業でチェック項目をゼロから作るのが難しい場合は、IPAが公開している中小企業向けの情報セキュリティガイドにクラウドサービス安全利用の手引きが付録として収録されており、確認項目の下敷きに使えます。

計画から本番切り替えまでのクラウド移行を進める7つのステップ

ここまでの検討をふまえ、実際の進行を7ステップに落とし込みます。前半は計画、後半は実行と定着です。順番に進めることで、抜け漏れと切り戻し不能な事故を防ぎます。

現状の課題を洗い出し、移行の目的と評価指標を決める
サーバー・データ・アプリの資産を棚卸しし、移行可否を分類する
移行の優先順位を決め、対象システムを選定する
目的に沿って移行方式（7R）とクラウドサービスを選ぶ
移行計画書を作り、リハーサル環境で移送と切り替えを試す
本番データを移送し、システムを切り替える
移行後の稼働を監視し、運用と費用を継続して見直す

移行計画書とリハーサルで固める本番切り替え前の準備工程の要点

移行計画書には、移行の目的・対象範囲・進め方・スケジュール・切り戻し手順を明記します。とりわけ切り戻し手順は必須です。本番切り替えで問題が起きたとき、元のオンプレミス環境へ戻せる状態を保っておくことで、事業停止を避けられる。

本番の前に、リハーサル環境で一度移送と切り替えを通しで試します。データの移送時間、アプリの動作、性能の劣化の有無をここで確認する。リハーサルで見つかった問題を潰してから本番に臨むことで、切り替え当日の予期せぬ停止を減らせます。準備工程にどれだけ時間を割けるかが、移行の成否を分けました。

本番切り替えと移行後の監視で稼働を安定させる運用体制の立ち上げ

本番切り替えは、利用者への影響が少ない時間帯を選んで実施します。切り替え直後は、性能・エラー・費用の3点を重点的に見る。移行直後は想定外の負荷やコスト増が出やすいため、数日から数週間は集中的に様子を見る体制を組みます。

稼働が安定したら、運用の改善余地を探る段階に入ります。使っていないリソースの停止、予約割引への切り替え、自動スケールの調整で、月額費用を継続的に見直す。クラウド移行は切り替えて終わりではなく、運用しながら費用と構成を整えていく取り組みです。

DNSのTTL短縮と切り戻し判断基準で決める当日の撤退ライン

切り替え当日にいちばん効くのは、事前のTTL短縮です。利用者の端末やキャッシュDNSは、権威DNSが返したTTLの秒数だけ古い向き先を覚え続けます。TTLが3600秒のまま切り替えると、問題が起きて切り戻しても最大1時間は古い環境へ流れ続ける。切り替えの72時間前にTTLを60秒へ下げておけば、切り戻しの反映が分単位に収まります。

# 切り替え72時間前に権威DNSのTTLを60秒へ下げる（Amazon Route 53 の例）
aws route53 change-resource-record-sets --hosted-zone-id Z123EXAMPLE \
  --change-batch file://ttl-60.json

# 実際に外から引けるTTLと向き先を確認する
dig @8.8.8.8 app.example.co.jp A +noall +answer

あわせて決めておくのが撤退ラインです。「切り替え開始から90分で主要機能の疎通が取れなければ切り戻す」「エラー率が5%を超えた時点で判断する」というように、数値と時刻で先に決めます。当日に議論を始めると、投じた工数が惜しくて判断が遅れる。撤退条件を計画書に書き、判断する人を1名決めておくことが、被害を小さく抑える現実的な備えになります。

クラウド移行を急ぐべきでない場面と内製・外注の役割分担の判断

クラウド移行は前提として推奨されがちですが、すべてのシステムを移すことが正解とは限りません。移すべきでない場面を見極め、体制を正しく組むことが、投資を無駄にしないための判断です。ここは一般論を避けて言い切ります。

移行を急がず現行維持を選ぶべきシステムと撤退・廃止の見極め条件

次の3条件に当てはまるシステムは、移行を急がず現行維持（リテイン）を選ぶべきです。第一に、更新が近く数年内に刷新・廃止が決まっているもの。移行費用を投じても回収前に役目を終えます。第二に、法規制や特殊なハードウェア依存でクラウドに載せられないもの。AWSの公式ガイドも、クラウドに同等品のない専用ハードウェアに依存する装置や、メインフレーム・非x86のUnix環境はリテイン側に置いています。第三に、社内でしか使わず負荷変動が小さい小規模システム。従量課金の恩恵が小さく、移行の手間に見合いません。

逆に、使われていないシステムはこの機会に廃止（リタイア）します。先に挙げたCPU・メモリ平均5%未満や90日間インバウンド接続なしの基準に当たるものは、移行せず落とす候補です。移行対象を減らすこと自体が、コストと工数の削減につながります。「全部移す」ではなく「移すもの・残すもの・捨てるもの」を仕分けする。この線引きが、移行プロジェクトの規模を適正な水準に収めます。

自社で担う範囲と外部に委託する範囲を切り分ける体制設計の判断

クラウド移行には、現行システムの理解と、AWS・Azure・Google Cloudといった移行先の設計知識の両方が要ります。この2つを自社だけでそろえるのは容易ではありません。現実的な分担は、現行業務とデータの意味を知る自社が要件と優先順位を握り、移行方式の設計・移行先の構築・切り替え作業を外部の専門会社に委ねる形です。

移行の設計や本番切り替えを内製で無理に進めると、切り戻し不能な事故や、費用がかさむ構成のまま固定される事態を招きます。設計と構築を委託する場合は、AWS・Google Cloud・Azureのインフラ構築を受託するサービスのように、移行先の設計から構築・運用までを一貫して任せられる先を選ぶと、判断の抜けを補えます。自社は目的と優先順位の決定に集中し、実装は専門知識のある先に任せる。この分担が、移行を計画どおりに進める体制です。

よくある質問

クラウド移行の進め方について、検討段階で寄せられることの多い質問に答えます。

クラウド移行にはどのくらいの期間がかかりますか？

対象システムの規模と移行方式で大きく変わります。改修の少ないリホストで単一サーバーを移すなら数週間、複数システムをリファクタリングを含めて移すなら数か月から1年規模になる。期間を短くする最大のコツは、対象を一度に広げず、優先度の高いものから段階的に移すことです。まず1システムをリホストで移し、その実績をもとに範囲を広げると、リスクと期間の両方を抑えられます。探索と評価に無料ツールを使えば、計画フェーズだけで数週間を費やす事態も避けられます。

クラウド移行で失敗する典型的な原因は何ですか？

目的が曖昧なまま着手すること、費用を初期分しか試算しないこと、切り戻し手順を用意しないことの3つが代表的です。特に切り戻し手順の欠落は、本番切り替えでの事故を致命的にします。移行前に元の環境へ戻せる状態を保ち、DNSのTTLを事前に短くし、リハーサルで通しの動作を確認しておくことが、失敗を避ける前提になる。つまずきやすい課題の全体像はクラウド移行の課題と失敗パターンで整理しています。

オンプレミスとクラウドはどちらが安いのですか？

一概には言えません。常時フル稼働するシステムはオンプレミスのほうが安くなる場合があり、負荷変動が大きく繁忙期だけリソースが要るシステムはクラウドが有利です。判断には、オンプレミスの総保有コスト（ハード償却・保守・電気・人件費を含む）と、クラウドの月額見込みを並べて比較します。データ転送の無料枠を超える分や、予約割引を使った場合の単価まで織り込んだ試算で、初めて正確な比較ができました。

全システムを一度にクラウドへ移すべきですか？

推奨しません。一括移行は影響範囲が広く、問題が起きたときの切り分けが難しくなります。難易度が低く効果の見込めるシステムから移し、実績と知見を積んでから範囲を広げる段階的な進め方が現実的です。AWSの移行ガイドも、大規模移行ではまずリホストやリロケートで移し、モダナイズは移行完了後に回す順序を勧めています。使われていないシステムは移さず廃止し、クラウドに向かないものは現行維持を選ぶ、という仕分けもあわせて行います。

クラウド移行を外部に依頼する場合、何を基準に選べばよいですか？

現行システムの調査から移行方式の設計、移行先の構築、切り替え後の運用まで一貫して対応できるかを基準にします。移送作業だけを請ける先だと、設計の妥当性や費用の適正化まで踏み込めません。あわせて、AWS・Azure・Google Cloudのうち自社が使う予定のクラウドでの構築実績があるか、切り戻し手順とテスト計画を提案に含めているかも確認しましょう。自社は目的と優先順位の決定を握り、設計と実装を委託する分担が、移行を計画どおりに進めやすくします。あわせて、システム移行についても解説しています。