アプリケーションの移行とは、1 つのコンピューティング環境から別の環境へ、ソフトウェア・アプリケーションを移動するプロセスを指します。 例えば、あるデータセンターから別のデータセンターへ、または、オンプレミスのサーバーからクラウド・プロバイダーの環境へ、あるいは、パブリッククラウド環境から、プライベートクラウド環境へアプリケーションを移動することなどが挙げられます。

アプリケーションは、一般的に固有の ネットワーク・アーキテクチャー 上の特定のオペレーティング・システムで稼働するよう構築されていたり、単独のクラウド・プラットフォーム向けに開発されていたりするため、アプリケーションを新しい環境へ移動することで、複数の課題に直面する可能性があります。 通常、ベアメタル・ハードウェア上で稼働するアプリケーションを移行するより、仮想化されたアーキテクチャーやサービス・ベースのアーキテクチャーからアプリケーションを移動する方が簡単です。

全体的なアプリケーションの移行戦略を決定するには、個別のアプリケーションの依存関係や、技術的な要件を考慮するとともに、組織のセキュリティー、整合性、およびコストなどの制約についても考慮する必要があります。

アプリケーションによっては、同じテクノロジー環境であっても、クラウドへのパスが異なることがあります。  クラウド・コンピューティングの初期の時代から、開発者はこうしたアプリケーションの移行のパターンに、「R」で始まる名前を付けてきました。

Rehost（リホスト）： 別名 リフト・アンド・シフト（lift-and-shift）とも呼ばれるこのパターンは、企業が大きな変更を加えずに、オンプレミスのサーバーから、クラウドの 仮想マシン にアプリケーションを移行する際の一般的な手法といえます。 アプリケーションのリホストは、他の移行方法より迅速で、移行にかかるコストを大幅に削減できる可能性があります。 マイナス面は、大きな変更を加えないことで、アプリケーションが クラウドネイティブ のコンピューティング機能のメリットを得ることができなくて、クラウドでの長期的なランニング・コストが高額になる可能性があることです。

Refactor（リファクタリング）またはRe-architect（リアーキテクト）： リファクタリングとは、アプリケーションに大規模な変更を加えることで、アプリケーション拡張、クラウド環境での性能改善などを可能にします。 この手法では、アプリケーションの主要部分の再コーディングを伴うことがあり、それによってクラウドネイティブの機能を活用する幅が広がります。例えば、モノリシック・アプリケーションを一連の マイクロサービス に再編成する、あるいは、データ・ストアをSQLからのNoSQLへモダナイズすることなどが挙げられます。

Replatform（リプラットフォーム）： これは、リフト・アンド・シフトとリアーキテクトの中間に位置づけられます。アプリケーションのリプラットフォームによりアプリケーションへの変更を最小限に抑えられるため、クラウド・アーキテクチャーのメリットをより多く活用できます。 例としては、クラウドネイティブのマネージド・データベースで機能するようアプリケーションをアップグレードしたり、アプリケーションが稼働するオペレーティング・システムやミドルウェアを変更したり、アプリケーションをコンテナ化したりする方法が挙げられます。

Retire/Replace（リタイア/リプレース）： 一部のケースでは、そのアプリケーション自体を廃止することが最も現実的であることもあります。 例えば、アプリケーションの価値が限られている、アプリケーションの機能が自社の環境内にある別のものと重複している、または、アプリケーションを移行するよりも、 SaaS（ソフトウェア・アズ・ア・サービス） プラットフォームなど、新しい機能に置き換える方が、コスト効率が良くなることなどが主な理由です。

企業に固有のIT環境やビジネス・ニーズに最適なアプリケーションの移行戦略を作成するには、自社のアプリケーション・ポートフォリオの内容、セキュリティー仕様とコンプライアンス要件、現在使用中のクラウド・リソース、自社のオンプレミス・ストレージ、コンピューティング、およびネットワーク・インフラストラクチャーの実状などを細かく理解する必要があります。

 クラウド・マイグレーション を成功させるために、クラウド・マイグレーションを進めようとしている主要なビジネス推進要因を明確にし、こうしたビジネス推進要因に戦略を整合させる必要があります。 クラウド・マイグレーションの理由、そしてこの移行とともに何を成し遂げたいかということを意識しましょう。

次の動画（英語）では、Andrea Crawfordがクラウド・マイグレーションについて詳しく解説します。

アプリケーションの移行により、ビジネスに混乱が生じたり、想定外のコストが発生するのではないかと不安を抱く人も出てくる可能性があります。 最も一般的なリスクは以下のとおりです。

• 予測できない技術的な課題： 例えば、アプリケーションには元々の想定より、リファクタリングやリプラットフォームを実施したことではるかに複雑化したり、時間を要する依存関係が存在する可能性があります。
  
  
• 想定外のコスト： 適切な計画がなければ、新しいライセンス交付料金や、従業員が新しいツールをすぐに使いこなせるようにするためのトレーニング・コストなど、予算化していなかった費用が発生する場合があります。
  
  
• 想定外のダウンタイム： アプリケーションへの大規模な変更は、予想外のダウンタイムにつながる不一致や問題などの原因になることがあります。
  
  
• 文化的な問題または変更管理の難しさ： さまざまな組織が、異なるアプリケーションを使用し、その違いが移行プロジェクトを遅らせる摩擦を生む可能性があります。

ポートフォリオで各アプリケーションのリホスティング、リアーキテクティング/リプラットフォーミング、リタイアに関連するリスクとメリットを慎重かつ詳細に評価することで、アプリケーションの移行に関連するリスク全体の軽減に役立つ場合があります。 特に、部門レベルでのコストを企業全体でかかる合計コストと比較し、アプリケーションをオンプレミスに保持するために必要なハードウェアのTCO（総所有コスト）を評価することが重要です。

この数年、企業には、クラウド・プロバイダーが提供する柔軟性、拡張性、または予測可能な従量制コスト構造を求めて、アプリケーションをクラウドに移行しようとする動きが多く見られました。

しかし、今日、企業はイノベーションを実現する環境も求めています。 それが、ディープ・ラーニングのアルゴリズムを強化するために必要な高性能のプロセッサーを利用することになるのか、開発チームが迅速に変更を実行することで、顧客のデジタル体験を迅速に実装できるコンテナ化されたアプリケーションを利用することになるのかに関わらず、クラウド・テクノロジーは、企業が新しいアイディアを試し、「速く失敗する」ことを可能にします。 多くの場合、 コンテナ化 など、クラウドで利用しやすいテクノロジーは、代替手段となる仮想マシンに比べて、エンド・ユーザーにより良い体験を提供できます。

一般的に、アプリケーションの移行の計画手順は、3段階に分けることができます。 各段階で、一部オンプレミスのワークロードをあえて残すことを含め、すべての可能性を含めたオプションのコストを比較することが重要です。

アプリケーションの特定とアセスメント。 この初期ディスカバリー段階での作業は、ポートフォリオのすべてのアプリケーションの総合カタログがあることを確認することから始めます。 その後、その中でそうしたアプリケーションがビジネス上不可欠かどうか、アプリケーションの価値が戦略的かどうか、クラウドへの移行を阻むものは何かなど、条件ごとにアプリケーションを分類します。 以下に挙げる特性から、アプリケーションの価値を理解するように努める必要があります。

• ビジネスへの影響
  
  
• 非常に重要なビジネスのニーズに対応する能力
  
  
• データの適時性と重要性
  
  
• サイズ、複雑性、管理の容易性
  
  
• 保守・開発のコスト
  
  
• クラウド・マイグレーションによって増大する価値

その後、移行を考えている各アプリケーションのクラウド・アフィニティー・アセスメントを実行します。 このプロセス中に、どのアプリケーションがそのままでクラウドに移行できるか、クラウド対応となるまでに大規模な変更が必要なのはどれかを判別します。

また、アプリケーション依存関係ディスカバリー・ツールを使用することで、現在の環境から特定のワークロードを移行する際の実現可能性を判別する参考にできます。

総所有コスト（TCO）アセスメント クラウド・マイグレーション・プロジェクトの総コストを決めるのは、複雑な作業になることがあります。 アプリケーションとインフラストラクチャーを、これに関連するものとともにオンプレミスに留めた場合と、クラウドに移行した場合の2通りで「what-if」シナリオを用いて比較する必要があります。 つまり、いずれのシナリオでも、オンプレミスで維持するハードウェアの購入、運用、保守に必要なコストと、ソフトウェアをライセンス交付で利用するコストを計算する必要があります。

両方のシナリオで、クラウド・プロバイダーの月額請求想定額と、新しいインフラストラクチャーをテストし、更新されたソフトウェアを使用するために従業員をトレーニングするコストを含め移行自体にかかるコストを比較してみましょう。 オンプレミスに残る既存アプリケーションの保守コストを考慮することを忘れないでください。

全体のリスクとプロジェクトの所要時間の評価 移行計画の最終段階で、プロジェクトのタイムラインを設定し、特に遭遇する可能性のあるリスクや障害を特定します。

一般的に、アプリケーションが古くなれば古くなるほど、クラウドへ移行する際の課題は多くなります（その結果として、時間と労力をかけて移行するだけの価値も小さくなります）。 古いソフトウェアは保守費用が高価で、修正用のパッチが提供されない場合にセキュリティーの懸念が生じたり、最新のコンピューティング環境では性能が落ちるなど、さまざまな面で問題となることがあります。 レガシー・アプリケーションの移行を決定する前に、アセスメントを慎重に実行してください。

企業がアプリケーションの移行の実現可能性と優先度を評価するときは、以下の問題について検討します。

複雑性： このアプリケーションはどこで開発されたか。 社内で開発された場合は、開発者は引き続き社内で働いているか。 アプリケーションの資料は利用可能であるか。 アプリケーションの開発からどれだけの年月が経過しているか。 アプリケーションの使用期間はどのくらいか。 社内で他にいくつのアプリケーションまたはワークフローが、このアプリケーションに何らかの形で依存しているか。

重要性： 毎日このアプリケーションに依存しているユーザーの数はどのくらいか。 1週間単位で見るとどうなるか。 このアプリケーションの使用者が、このアプリケーションを使用しなくても支障なく業務を行えるダウンタイムはどの程度か。 このアプリケーションは、本番、開発、テスト、あるいはこの3つのすべての環境で使用されているか。 このアプリケーションを管理しているのは社内のITチームか、社外の取引先か。 このアプリケーションと同期する必要のあるアップタイム/ダウンタイム要件のあるアプリケーションは他にあるか。

コンプライアンス： このアプリケーションが準拠しなければならない規制要件はどれか。

可用性： このアプリケーションが準拠しなければならないアップタイム基準は何か。 例えば、その基準は99.99%のアップタイムを求めるSLAの対象となるか。

テスト

アプリケーションの移行プロセス中、データや機能が破損することのないよう、移行中にすべてのデータが存在すること、データの整合性が保たれていること、データが現在、正しいストレージ・ロケーションにあることを検証するため、テストを実施する必要があります。

また、移行が完了したあと、アプリケーションのパフォーマンスのベンチマーキングを実行し、セキュリティーの管理が適切に設定されていることを確認するために、フォローアップ・テストを実施することが絶対に必要です。

仮想化 はクラウドへの移行戦略の多くで基礎となるコンポーネントです。仮想マシンは新しい物理ハードウェア環境ですぐに実行できるためです。 エンド・ユーザーの利用環境を中断することなく、仮想マシン上で実行中のライブ・アプリケーションを物理ホスト・マシン間で移動することも可能になります。 仮想化コンピューティング環境における柔軟性と多様性により、アプリケーションの移行プロセスは劇的に簡素化されます。

ハイパーバイザーのタイプと移行のオプション

現在選択可能なレプリケーションといくつかの移行ソリューションを使用することで、 ベアメタル・サーバー、クラウドの仮想サーバー、さらには ハイパーバイザー間で、仮想マシンを移行できるようになります。

• VMWareアプリケーションの移行： 業務の中断、ダウンタイムの発生、アプリケーションの再構成の必要は無く、オンプレミスの VMware インスタンスで実行中の仮想マシンを、プライベートクラウドで実行中のVMware vCenter Serverにリフト・アンド・シフトすることが可能です。
  
  
• Red Hatアプリケーションの移行： Red Hatは、アプリケーションの移行ツールキットを提供しています。このツールキットは、アプリケーションの相互依存関係を特定するためにIT環境を分析する、カスタマイズ可能で拡張可能なソリューションです。 移行中に問題に直面する可能性のあるアプリケーションをハイライトするダッシュボード式の分析レポートを提供します。

企業がクラウドへの移行を正常に実行できるよう戦略や計画を立てて実施するのに役立つサービスが多数用意されています。

移行の計画立案： 総合的な計画のサービス・オファリングでは、ベンダーが移行の戦略と目的を明確化し、アプリケーションと環境に関する情報を集め、ユーザーのニーズとビジネス要件を特定し、移行に必要なアクションの詳細な計画を提供します。

移行の導入： マネージド・デプロイメント・オプションを選択した場合、ベンダーは移行の戦略および計画の立案だけでなく、移行そのもの、関連するテスト、そして障害追及についても管理します。 これは通常、すぐに使用可能なサービス・オファリングで、フルスケールのエンドツーエンド・サポートが含まれています。

クラウド・マネージド・サービス： マネージド・クラウドのサービス・オファリングには一般的に、クラウドを活用したIT環境の監視と保守が含まれます。 マネージド・クラウド・サービス・プロバイダーは、お客様に変わりベンダーから提供されるクラウドのセキュリティー管理からサービスとしてのオファリングの購入まで、複数の機能に対し責任を持つことを想定しています。 アプリケーションの移行は、パッケージ化されたサービス・オファリングに含められるか、アラカルト・ベースで追加されます。

アプリケーションのモダナイゼーション： アプリケーションのモダナイゼーション ・サービスには、既存のアプリケーションを変更することで、クラウドを使用するための準備ができるカスタム開発オファリングが含まれ、これにより、 コンテナ または仮想化環境で既存のアプリケーションを実行できるようになります。