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

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

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

データ分析を活用

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

アジリティの向上

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

データの統合とモダナイゼーション

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

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

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

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

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

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

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

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

詳細なチェックリストは、組織がクラウドへの移行を容易にするために従うことができるロードマップを提供します。チェックリストには、次のような項目を含めることができます。

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

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

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

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

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

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

• 再ホスト: リフト＆シフト
  • クラウド移行の再ホスト戦略は、移行中の変更をできるだけ少なくし、アプリケーションの構成を大幅に変更せずにクラウドにアプリケーションを再デプロイすることを目的としています。
  • これは、管理者がアプリケーション、ワークロード、仮想マシン、サーバー オペレーティング システムを「リフト」して、パブリック クラウドの新しいオペレーティング モデルに「シフト」するだけの、最もわかりやすいクラウド移行戦略です。データセンターで実行されていたソフトウェアが、今ではクラウドでも実行されています。
  • 再ホスト戦略の欠点は、パブリック クラウドを強力かつ有用なものにしているクラウドネイティブの機能と効率のすべてを活用できないことがよくあることです。
  • 移行の再ホスト戦略は、ピークの使用パターンが予測可能な組織（税務業界やフード デリバリーなど）に最適です。一般的に、大規模なデジタル トランスフォーメーション プロジェクトの「最初のステップ」でもあります。
• リプラットフォーム: リフト＆最適化
  • リプラットフォーム戦略は、再ホスト戦略の次のステップです。既存のアプリケーション、ワークロード、仮想マシンをリフトして、新しいクラウド環境に合わせて最適化します。たとえば、クラウドベースのマイクロサービス アーキテクチャや Kubernetes のようなコンテナを活用するために、ワークロードをサービスによってクラウドにリプラットフォームできます。
  • リプラットフォーム クラウド移行戦略のメリットは、クラウドで実行されるアプリケーションのパフォーマンスと効率性が高いことです。デメリットは、リプラットフォームは、単純なリフト＆シフトよりも多くの作業が必要になることです。新しいクラウド プラットフォームは、基盤となるコードベースが異なるため、すべてが最適なレベルで実行されていることを確認するために、複数回のテストが必要になります。
  • リプラットフォーム クラウド移行戦略は、弾力性のあるコンピューティング、冗長性、パフォーマンスの向上、セキュリティなど、クラウドのコア コンピテンシーをすべて利用したいと考えている組織に最適です。

• リファクタリング: 移行＆改善
  • クラウド移行戦略のリファクタリングとは、アプリケーションをクラウドネイティブに再構築することです。
  • リファクタリングとは、多くの場合、フロントエンドの動作やエクスペリエンスを変更せずにアプリケーションのコードを変更することを意味します。たとえば、リファクタリングされたアプリケーションでは、コードの長い文字列が、クラウド機能をより有効に活用できるモジュール式に細分化され、コードのパフォーマンスが向上します。
  • リファクタリング戦略で推進力となるのは多くの場合、拡張性の向上、ML や AI 機能の追加、より高速で直感的なデータ分析など、既存のアプリケーションに新しい機能を提供する必要性です。
  • リファクタリングは再ホストよりも複雑ですが、組織はビジネスニーズに基づいてどのアプリケーションを移行するかに優先順位を設定できるため、柔軟性が向上し、競争の激しいエコシステムに遅れずに対応できるようになります。
• 再設計
  • クラウド移行戦略の再設計はリファクタリングに似ていますが、アプリケーションのコードの仕組みを再構築するのではなく、アプリケーションを最適化し、スケーラビリティ、セキュリティ、アジリティなどのクラウドネイティブな特性を活用するために、そのコードの機能を変更します。
  • アプリケーションの再設計の一例としては、1 つの大規模なモノリシック アプリケーションを複数の独立したマイクロサービスに分割することが挙げられます。
  • 再設計はリファクタリングよりも時間と労力がかかるため、複雑さが増します。また、新しいアプリケーションにバグやセキュリティの問題をもたらす可能性もあります。
• 再構築
  • クラウド移行再構築戦略とは、組織がアプリケーションをクラウド用に完全に書き換えることです。多くの場合、アプリケーションをゼロから構築する方が、古いコードをクラウド環境で機能するようにリファクタリングするよりも簡単です。
  • 再構築戦略を取ることで、どのクラウドネイティブ ツールや機能を最初から使用するかを選択でき、一からのプランニングが可能になります。
  • 再構築戦略の欠点は、時間がかかり、デベロッパーが以前のバージョンのアプリでは遭遇していないバグやその他のパフォーマンスの問題を引き起こす可能性があることです。

• 再購入
  • クラウド移行戦略の再購入とは、購入したオンプレミス アプリケーションから、クラウドでホストされた同等の Software as a Service に移行する戦略です。たとえば、オンプレミスのコラボレーション ソフトウェアやローカル ストレージから、ドキュメント、スプレッドシート、スライド、Google ドライブといった Google Workspace のクラウドホスト型アプリに移行できます。
  • リソースの観点から見ると、再購入戦略は、リファクタリング、再構築、再設計よりもはるかに容易です。
  • 再購入戦略の欠点は、費用がかなり高くなる可能性があり、組織が独自のクラウド環境を管理するきめ細かい機能が得られないことです。

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

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

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

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