LASSIC Media らしくメディア
オンプレミスのクラウド移行手順・進め方を外注で解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- オンプレミスからクラウド移行を進める手順は、現状把握から移行後の運用最適化まで複数の工程に分かれます。
- AWS・Azure・Google Cloudは、それぞれの移行フェーズモデルを公式に示しています*1*2*3。
- 内製と外注のどちらで進めるかは、工程ごとに必要な知見や体制によって判断が分かれます。
目次
オンプレミスからクラウド移行の進め方とは、5つの節目工程からなる全体設計
オンプレミスからクラウド移行の進め方とは、現状把握から本番切替までを段階的に進める一連の工程を指します。AWSは移行支援プログラムを3つのフェーズで構成し*1、Microsoftは移行工程を5つのステップで定義しています*2。
3社の移行フレームワークは、フェーズの数え方こそ異なるものの、評価・計画・実行・最適化という骨格を共有しています。本稿ではこの共通する骨格を踏まえ、現状把握・方式選定・設計・検証・移行実行・本番切替という5つの節目工程に整理し、実務で押さえるべき流れとして解説します。
各工程の詳しい進め方は、それぞれ専門性が異なる点に注意が必要です。本稿では全体の見取り図を示すことに重点を置き、個別の工程についてはより詳しい解説記事に譲ります。
AWS・Azure・Google Cloudが示す移行フェーズの共通点
AWSのMigration Acceleration Program(MAP。AWSが提供する移行支援プログラム)は、移行をAssess(評価)・Mobilize(準備)・Migrate and Modernize(移行・最適化)という3つのフェーズで構成しています*1。評価フェーズでは、ビジネス・プロセス・人材・プラットフォーム・運用・セキュリティの6つの観点から組織のクラウド対応力を診断し、現実的な総所有コスト(TCO)モデルを組み立てることを目指します*1。
Microsoft Azureのクラウド導入フレームワーク(Cloud Adoption Framework)は、移行工程をPlan migration(移行計画)・Prepare workloads(ワークロード準備)・Execute migration(移行実行)・Optimize in cloud(クラウド上での最適化)・Decommission source(移行元の廃止)という5つのステップで示しています*2。
Google Cloudは、移行の流れをAssess(評価)・Plan(計画)・Deploy(展開)・Optimize(最適化)という4つのフェーズで説明しています*3。評価フェーズではアプリケーションとインフラの棚卸しや依存関係の特定を行い、最適化フェーズではクラウド固有の機能を生かした性能・コストの改善を進めます*3。
3社のフェーズ数は3つから5つまで異なりますが、いずれも評価してから計画・実行し、最後に最適化するという順序は共通しています。本稿ではこの共通点を踏まえ、現状把握・方式選定・設計・検証・移行実行・本番切替という節目で工程を整理します。
現状把握と6R(7R)による移行方式の選定——最初に握る2つの工程
①現状把握——業務要件とシステム構成の棚卸し
最初の工程は、移行対象システムの構成・依存関係・利用状況を洗い出す現状把握です。AWSのMAPでも、評価フェーズの目的は現実的なTCOモデルを組み立てることだと説明されています*1。
現状把握の精度が低いと、後続の方式選定や設計の判断材料が不足します。対象システムが多い企業ほど、この工程には相応の工数がかかります。
②6R(7R)——移行方式を仕分けるAWSのフレームワーク
現状把握の結果をもとに、システムごとの移行方式を決めるのが次の工程です。AWSはRetire・Retain・Rehost・Relocate・Repurchase・Replatform・Refactorという7つの移行戦略(7R)を公式に示しています*4。
大規模な移行では、比較的シンプルなRehost・Relocate・Replatform・Retireが選ばれやすいとされています*4。アプリケーションを刷新するRefactorは、移行時ではなく移行完了後に着手する進め方が推奨されています*4。どの方式を選ぶかによって、後続の設計・移行実行の難度は大きく変わってきます。
クラウド環境設計とPoCによる検証——本番前に不確実性を減らす2つの工程
③クラウド環境設計——ネットワーク・IAM・可用性の設計
移行方式が決まったら、受け入れ先となるクラウド環境を設計します。ネットワーク構成、IAM(Identity and Access Management。クラウド上の権限を管理する仕組み)の権限設計、可用性の確保方法などが主な検討項目です。
Azureのガイドでは、依存関係を洗い出したうえでワークロードをグループ化し、まとめて移行する範囲を決める進め方が示されています*2。設計段階で依存関係を見落とすと、後続の移行実行でサービス断につながるおそれがあります。
④PoC/検証——本番前に非本番環境で確認する
PoC(Proof of Concept。本番導入前に効果や実現性を確かめる試行)は、設計した環境が想定どおりに機能するかを確認する工程です。Azureのガイドでも、開発・ステージング・QA環境を先に移行し、本番環境は後回しにする進め方が推奨されています*2。
複雑な構成を持つシステムを含めて検証すれば、本番移行時に起こり得る課題を事前につかみやすくなります*2。この段階で問題を洗い出せるかどうかが、後続工程の負荷を左右します。
データ・アプリの移行実行から本番切替(カットオーバー)まで
⑤移行実行——データ移行とアプリケーション移行
検証を終えたら、データとアプリケーションの本番移行に進みます。データの移行経路には、専用線接続、VPN(Virtual Private Network。拠点間を暗号化して接続する仕組み)、物理媒体による搬送、公衆インターネットなど複数の選択肢があります*2。
移行させるワークロードの順序は、依存関係の少ないシステムから着手し、業務影響の大きいシステムほど後段に回す進め方が実務的だとされています*2。
⑥カットオーバー——本番トラフィックの切替
カットオーバーとは、既存の接続先から新しいクラウド環境へ本番トラフィックを切り替える工程です*5。DNS(Domain Name System。ドメイン名とIPアドレスを対応させる仕組み)の切替などが代表例です*5。
ダウンタイムの許容時間が短い業務システムほど、切替の複雑さは増す傾向があります*5。停止時間を最小限に抑えたい基幹システムでは、計画と体制づくりに相応の時間を要します。
移行後の運用最適化——移行はゴールではなく起点
本番切替が完了しても、移行工程はそこで終わりません。Google Cloudの最適化フェーズでは、性能・スケーラビリティ・ディザスタリカバリ・コストの改善を継続的に進めることが示されています*3。
Azureのガイドでも、クラウド上での最適化と移行元の廃止は、移行実行の後に続く工程として位置づけられています*2。稼働開始後にリソースの使用状況を確認し、無駄な費用が発生していないかを見直す取り組みが欠かせません。
移行後の運用体制を移行実行の担当者がそのまま引き継げると、障害対応の初動を早めやすくなります。移行の実行と運用の設計は、切り離さずに検討することが大切です。
内製と外注、どちらで進めるべきか——体制と工数で判断する
ここまでの5つの節目工程を自社だけで完結させるには、複数の専門性を同時に確保する必要があります。ネットワーク設計、IAM権限設計、データ移行、監視ツールの運用など、領域ごとに異なる知識が求められます。
必要な知識が一部門に偏っている場合、通常業務と並行して対応する現場の負担は小さくありません。特に現状把握とカットオーバーの2工程は、対象システム数が多いほど確認作業に時間がかかります。
本番切替の判断を誤ると、業務システムの停止時間が想定より延びるおそれがあります*5。基幹システムであれば、その影響は一部門の業務停止にとどまらない場合もあります。
専門パートナーに委託する場合は、現状把握から移行後の運用最適化までを一括して依頼できるかどうかが選定の分かれ目です。工程ごとに担当者が変わる体制では、引き継ぎのたびに情報が欠落するリスクが生じます。
。対象システムの数や依存関係の複雑さによって、必要な工数は変わってきます。現状の構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：オンプレミスからクラウド移行を進めるための3つの判断軸
本稿ではオンプレミスからクラウド移行の進め方を、AWS・Azure・Google Cloud公式の移行フレームワークをもとに整理しました。要点は3つに集約できます。第一に、3社のフェーズモデルは数え方こそ異なりますが、評価・計画・実行・最適化という骨格を共有しています*1*2*3。第二に、現状把握・方式選定・設計・検証・移行実行・本番切替という節目工程を踏まえたうえで、移行後の運用最適化まで見据える必要があります*2*3。第三に、工程ごとに必要な専門性と工数は異なり、内製と外注の判断材料になります。
よくある質問
オンプレミスからクラウド移行の進め方は、AWS・Azure・Google Cloudで違いますか。
各社のフェーズの数え方は異なりますが、評価してから計画・実行し、最後に最適化するという流れは共通しています*1*2*3。どのクラウドを選んでも、現状把握から始める点は変わりません。
移行の各工程には、どのくらいの期間を見込めばよいですか。
対象システムの数や依存関係の複雑さによって必要な期間は変わるため、一律の目安を示すことは難しいです。Azureのガイドでも、システムごとに開始日と終了日を設定し、検証や課題対応の余裕を持たせる進め方が推奨されています*2。
6R(7R)による移行方式の選定は、進め方のどの段階で行いますか。
現状把握で対象システムの構成や依存関係を洗い出した後、方式選定の工程で7つの移行戦略のいずれかを割り当てます*4。この判断が、後続の設計・移行実行の難度を左右します。
クラウド移行を内製と外注のどちらで進めるべきか、判断基準はありますか。
現状把握からカットオーバー、運用最適化までを担える専門性が社内に揃っているかどうかが判断基準になります。工程ごとに必要な知識が異なるため、一部の工程だけを外部に委託する進め方も選択肢になるでしょう。
カットオーバー(本番切替)で特に注意すべき点は何ですか。
ダウンタイムの許容時間が短い業務システムほど、切替の複雑さは増す傾向があります*5。停止時間の許容範囲を事前に業務側と合意したうえで、切替計画を立てることが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AWS「Migration Acceleration Program」（https://aws.amazon.com/migration-acceleration-program/）
- *2 出典：Microsoft「Plan your migration」（Cloud Adoption Framework for Azure、Microsoft Learn）（https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migration）
- *3 出典：Google Cloud「Migrate to Google Cloud: Getting started」（https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started）
- *4 出典：AWS「About the migration strategies」（AWS Prescriptive Guidance, Large migration guide）（https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html）
- *5 出典：AWS「Overview of the cutover phase」（AWS Prescriptive Guidance）（https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/overview-cutover-phase.html）
