クラウドに移行する主な理由には、費用の削減とインフラストラクチャの最適化があります。クラウドに移行することで、組織は資本支出モデルから運用支出モデルに支出を移行することができ、オンプレミスのデータセンターにある高価な機器を所有、運用、保守、更新する必要性を低減できます。

クラウドへの移行は、企業のパフォーマンスの向上と稼働時間の増加に役立ちます。また、クラウドは企業がワークロードをモダナイズし、レガシー アプリケーションによる負担の大きいライセンス料を回避するのにも役立ちます。クラウドは、世界中の規制機関のガバナンスとコンプライアンスを強化しながら、組織がデータを保護するうえで役立ちます。

また、組織は以下の目的でクラウドに移行しています。

データ分析を活用する

既存のアプリをクラウドに移行することで、企業は CRM、SAP、マーケティング データベースなどの既存のツールからより多くの価値を生み出すことができます。これらのシステムをクラウドでモダナイズすることで、企業はデータを活用し、新しいビジネス チャンスを見いだしながら、問題に対処するための組織のアジリティを高めることができます。

アジリティの向上

クラウドはオンデマンドの IT リソースを提供するため、組織はアプリの構築やオンプレミスのハードウェアのインストールに数週間から数か月待つ必要がありません。クラウドにより、組織は市場の変化や競合他社の行動により素早く適応し、市場開拓戦略の柔軟性を高めることができます。

データの統合とモダナイズ

オンプレミスのデータセンターから移行することで、企業はデータを統合し、ユニバーサル データ プラットフォームに整理する機会が得られます。これにより、より堅牢で高度なデジタル トランスフォーメーションの機会が開かれます。

組織は目標と目的に応じて、さまざまなタイプのクラウド移行から選択できます。

データセンターの完全な終了の移行とは、すべてのアプリケーション、サービス、データセットを 1 つ以上のデータセンターからパブリック クラウドに移行するプロセスです。組織の規模によっては、データセンターの完全な終了は、1 年以上の計画、テスト、実行を必要とする長いプロセスになる可能性があります。

組織は、サービスレベル契約の変更、セキュリティ対策の改善、より高度な人工知能や ML ツールの利用など、さまざまな理由でクラウド ベンダー間の移行が必要になることがあります。大手ベンダーは通常、あるパブリック・クラウド・プロバイダから別のパブリック・クラウド・プロバイダへの移行を支援できるツールセット、サービス、サードパーティ・ベンダーのリストを用意しています。

データセンターを完全に終了するのではなく、組織は、ソフトウェア、サービス、データセットの一部をオンプレミス サーバーから移行して、より効率的で管理しやすいクラウドに移行したいと考えるかもしれません。ビジネス インテリジェンス、データ分析、顧客リソース管理（CRM）、ML および AI のアプリ、データセットは、パブリック クラウドに移行する一般的な種類のアプリケーションです。

より的を絞った移行では、クラウドで実行されるリソースで、コンピューティング能力やストレージ容量などなんらかのリソースを消費する特定のタイプのワークロードのみで構成することもできます。たとえば、開発環境、ドキュメントの作成と管理、分散データベース、3D モデリング、動画のエンコードなどが挙げられます。

クラウドへの移行は、評価、計画、移行、最適化 / モダナイゼーションを含む複数のフェーズからなるプロセスです。包括的なエンドツーエンドの移行プログラムにより、組織はリスクを軽減し、費用を管理し、クラウドの成功への道筋を簡素化できます。

クラウド移行プロセスを開始する際、組織にはいくつかの選択肢があります。既存の従業員を使って自分で試すこともできます。パブリック クラウド ベンダーと提携して、その一連の移行ツールを利用できます。また、技術的な専門知識とサポートを提供するサードパーティの移行パートナーを利用することもできます。

徹底したチェックリストは、組織がクラウドへの移行を容易にするためのロードマップとなります。チェックリストには次の項目などを含めることができます。

• アプリケーションのリソースと容量を定義する
• アプリケーションとその使用者、使用頻度のリストを作成する
• プロセスの早い段階で主要な関係者を特定する
• クラウド移行の対象となりうるアプリケーションを決定する
• セキュリティとコンプライアンスに関する要件を指定する

• アプリケーションごとに戦略を選ぶ
• コンピューティング、ネットワーキング、セキュリティ、ストレージなどのクラウド インフラストラクチャを設計する
• 移行するワークロードの機能を特定
• アプリとそのデータの移行計画を作成する

• 移行開始前にテスト戦略を策定する
• データの移行と同期をテストする
• セキュリティ管理を検証する
• 実際の移行の一環として必要な変更をドキュメント化する
• アプリケーションのカットオーバーの時間を計画する

• 各アプリ、ワークロード、インスタンスの計画に従って移行する
• 段階的に移行し、各 Wave を実行してから、クラウドで検証する
• ある方法で学んだ教訓を次の Wave に応用する

• アプリケーションとクラウドの使用をモニタリングする
• ユーザー エクスペリエンスを最適化する
• クラウド費用をモニタリングし、必要に応じて調整する
• アプリとシステムを PaaS や SaaS などの最新のソリューションにアップグレードする

最も一般的な移行戦略は、アプリや仮想マシンにほとんど、またはまったく変更を加えない直接的な移行（再ホスト）から、デジタル インフラストラクチャ全体の完全な再考（再設計またはリプラットフォーム）まで、さまざまなタイプがあります。

• 再ホスト: リフト＆シフト
• 再ホストによるクラウド移行戦略では、移行中に行う変更をできるだけ少なくし、構成を大幅に変更することなくアプリケーションをクラウドに再デプロイします。
• これは、管理者がアプリケーション、ワークロード、仮想マシン、サーバー オペレーティング システムを「リフト」して、パブリック クラウドの新しいオペレーティング モデルに「シフト」するだけの、最もわかりやすいクラウド移行戦略です。データセンターで実行されていたソフトウェアと同じソフトウェアが、現在クラウドでも実行されています。
• 再ホスト戦略の欠点は、パブリック クラウドを強力かつ有用なものにするクラウドネイティブの機能と効率性のすべてが活用されていないことが多いという点です。
• 再ホストの移行戦略は、（税業界やフード デリバリーなど）使用パターンが予測可能な組織に最適です。また、一般的に大規模なデジタル トランスフォーメーション プロジェクトの「最初のステップ」にもなります。
• 再プラットフォーム化: リフト＆最適化
• リプラットフォーム戦略は、再ホスト戦略の次のステップです。既存のアプリケーション、ワークロード、仮想マシンをリフトして、新しいクラウド環境に合わせて最適化します。たとえば、クラウドベースのマイクロサービス アーキテクチャや Kubernetes のようなコンテナを活用するために、ワークロードをサービスによってクラウドにリプラットフォームできます。
• リプラットフォーム クラウド移行戦略のメリットは、クラウドで実行されるアプリケーションのパフォーマンスと効率性が高いことです。デメリットは、リプラットフォームは、単純なリフト＆シフトよりも多くの作業が必要になることです。新しい Cloud Platform は基盤となるコードベースが異なるため、すべてが最適なレベルで実行されていることを確認するために、テストを数回行う必要があります。
• リプラットフォーム クラウド移行戦略は、弾力性のあるコンピューティング、冗長性、パフォーマンスの向上、セキュリティなど、クラウドのコア コンピテンシーをすべて利用したいと考えている組織に最適です。
• リファクタリング: 移行＆改善
• リファクタリングによるクラウド移行戦略とは、アプリケーションをクラウドネイティブに再設計することです。
• リファクタリングとは、多くの場合、フロントエンドの動作やエクスペリエンスを変更することなく、アプリケーションのコードを変更することを意味します。たとえば、リファクタリングされたアプリケーションでは、コードの長い文字列が、クラウド機能をより有効に活用できるモジュール式に細分化され、コードのパフォーマンスが向上します。
• リファクタリング戦略で推進力となるのは多くの場合、拡張性の向上、ML や AI 機能の追加、より高速で直感的なデータ分析など、既存のアプリケーションに新しい機能を提供する必要性です。
• リファクタリングは再ホストよりも複雑になることもありますが、組織はビジネスニーズに基づいてアプリケーションを移行する優先順位を設定できるため、柔軟性が高まり、競争の激しいエコシステムに遅れずについていけるようになります。
• 再設計
• クラウド移行戦略の再設計はリファクタリングに似ていますが、アプリケーションのコードの仕組みを再構築するのではなく、アプリケーションを最適化し、スケーラビリティ、セキュリティ、アジリティなどのクラウドネイティブな特性を活用するためにコードの機能を変更します。
• アプリケーションの再設計の一例としては、1 つの大規模なモノリシック アプリケーションを複数の独立したマイクロサービスに分割することが挙げられます。
• 再構築はリファクタリングよりも時間と労力を要し、複雑さが増す一方で、新しいアプリケーションにバグやセキュリティ問題が発生する可能性があります。
• 再ビルド
• クラウド移行再構築戦略とは、組織がアプリケーションをクラウド用に完全に書き換えることです。多くの場合、アプリケーションをゼロから構築する方が、古いコードをクラウド環境で機能するようにリファクタリングするよりも簡単です。
• 再構築戦略を取ることで、どのクラウドネイティブ ツールや機能を最初から使用するかを選択でき、一からのプランニングが可能になります。
• 再構築戦略の欠点は、時間がかかることと、以前のバージョンのアプリではデベロッパーが検出できなかったバグやその他のパフォーマンスの問題を引き起こす可能性があることです。
• 再購入
• クラウド移行戦略の再購入とは、組織が購入したオンプレミス アプリケーションから、クラウドホストの Software as a Service に相当するものに移行することです。たとえば、オンプレミスのコラボレーション ソフトウェアやローカル ストレージから、Google Workspace のクラウドホスト型アプリ（ドキュメント、スプレッドシート、スライド、Google ドライブなど）に移行できます。
• リソースの観点から見ると、再購入戦略は、リファクタリング、再構築、再設計よりもはるかに容易です。
• 再購入戦略の欠点は、非常に費用がかさむ可能性があることと、組織が独自のクラウド環境を制御するきめ細かい機能を利用できないことです。

クラウドへの本格的な移行は、数年にわたる複雑なオペレーションになる可能性があります。クラウドへの移行を進める組織には、移行中に目指すべき明確な目標と達成可能なビジネス目標が必要となります。組織は、移行終了時に自社のクラウド環境がどのようになるのか（たとえば、パブリック、プライベート、ハイブリッド、マルチクラウドのエコシステムのどれになるのか）を理解しておく必要があります。移行には、サードパーティ ベンダーやクラウド プロバイダからの多大な支援が必要なのか？どのようなアプリが SaaS モデルで実行されるのか？新しい環境でデータはどのように整理されるのか？このような戦略に関する疑問に答えを出すことが、クラウド移行における最初の課題です。

クラウドにおける IT 運用の編成は、オンプレミス環境で同じプロセスを実行するのとは異なります。クラウドでは、DevOps、自動化、Infrastructure as Code などの運用モデルの使用が簡素になります。組織は、クラウド環境で必要な機能を実行するために、従業員を雇用するか再教育する必要があります。移行中、組織は従業員にクラウド環境に関するトレーニングや新しい認定資格取得のための時間を確保する必要があります。

オンプレミス環境とクラウド間で移行すると、セキュリティ対策が変更されます。クラウドでの Identity and Access Management の重要性は高まり、IT 管理者にとっては複雑さを増す要因となっています。組織は、データ損失防止（DLP）やゼロトラスト アーキテクチャの導入など、新しいセキュリティ ツールやベスト プラクティスを理解する必要があります。強固なセキュリティ ツールがあったとしても、データをある環境から別の環境に移行する際に、データ ガバナンスとコンプライアンス ポリシーに関する課題に取り組むのは組織の責任です。

クラウドに移行すると、組織の運用モデルが変化します。流動的な要素が多いため、新たな費用や支出をすべて把握するのは大変な作業です。クラウド移行における費用管理は、新しい料金体系、請求サイクル、リソース消費、ソフトウェア サブスクリプションの理解や、追加のサポートとトレーニングの計算など、継続的な課題になります。クラウドに移行する際に、企業はリソースを過剰にプロビジョニングして、最初にクラウド リソースを過剰に消費することがあります。クラウド・プロバイダの中には、組織がクラウドの費用と予算を調整できるよう、積極的な提案を行うところもあります。