インフラの移行について考える前に、現状のシステム環境について徹底的に理解する必要がある。大半の企業は、現状を調査するとアプリケーションの依存関係（プログラムの実行に別のプログラムが必要となる関係）や要件が想像を上回り、驚くことになる。

　まず、自社のアプリケーションの状況を網羅するインベントリ（目録）を作成する。データベースやアプリケーションサーバのような明白な要素から、定期タスクなどの目立たない要素まで、全てのコンポーネントをドキュメントに記録する。このドキュメントが移行計画の土台になる。

　レガシーアプリケーションには、クラウド移行時にしか表面化しない依存関係が隠れていることがある。時間をかけてさまざまな条件でアプリケーションの動作を観察し、どれほどささいなものであっても、外部システムとのやりとりを全てドキュメントに記録する必要がある。

　コンポーネント同士の依存関係だけでなく、コンポーネント間でデータを転送する時の遅延要件を示すネットワークトポロジー（構成）の図表を作成する。クラウド移行時に隠れた依存関係が表面化することは珍しくなく、早めに特定しないと進行が遅れる恐れがある。

ステップ2．ITインフラの分析

　クラウドサービスは従来のデータセンターとは運用方法が根本的に異なる。その違いは移行後のアプリケーションの運用方法に影響する。

　ITインフラの現状を評価する際には、ネットワークアーキテクチャに特に注意を払う必要がある。レガシーアプリケーションはコンポーネント間の接続の遅延が少ないことを前提とする場合がある。だが、クラウドサービスではその遅延を実現できない場合がある。トラフィック（ネットワークを流れるデータ）のパターンと遅延の要件を把握しておくと、クラウド移行後の転送速度などのパフォーマンスの問題を回避するのに役立つ。

　ストレージに関する考慮事項は、キャパシティープランニング（最適なスペックの見積もり）だけではない。レガシーアプリケーションは特定のファイルシステム機能や共有ストレージに依存する場合があるため、入念に分析する必要がある。クラウドストレージとローカルストレージの違いはアプリケーションの動作にも影響を与える。

ステップ3．移行方針の選択

　選択する移行方針によって、移行の過程と結果の両方が大きく変わる。レガシーアプリケーションに適した基本的なアプローチには次の3つの候補がある。

• ホスト変更（リフト＆シフト）
  • 既存のアプリケーションやOSへの変更を最小限に抑えるアプローチで、もっとも容易な方法だが、クラウドサービスの特性から受けられるメリットは限定的になる。
  • データセンターからの迅速な脱却を目指す場合や、アプリケーションが特に変更の影響を受けやすいことが判明した場合はこのアプローチを検討する。
• ハイブリッド移行
  • クラウド移行時に、コンポーネントを選んで最新化する。
  • 例えば、データベースだけクラウドサービスに変更して、アプリケーションの大半はオンプレミスインフラに維持する。変更を限定的にすることで、運用負荷を削減できる。
• リファクタリング（ソフトウェアの振る舞いや機能を変えずに内部構造を変えること）
  • クラウドサービスのメリットを存分に生かすためにアプリケーションを再構築する。
  • リファクタリングは最も労力を必要とするが、長期的にはスケーラビリティ（拡張性）と保守性の点でメリットが得られる。

ステップ4．技術的な実装計画

　方針を決めたら、技術的側面に重点を移し、主要コンポーネントごとに詳細な計画を立てる。

　クラウド移行時にはレガシーデータベースが最大の課題になることがある。次の点を含めて全ての依存関係をドキュメントに記録する。

• ストアドプロシージャ（複数のSQLによる命令を一つにまとめたプログラム）とトリガー（特定のイベント発生時に動作するプログラム）
• データベース固有の機能
• データ型の互換性の問題
• 参照整合性（テーブル間のデータの整合性を保つためのルール）の要件

　レガシーアプリケーションの認証の仕組みは、クラウドサービスのセキュリティモデルと連携できないことがある。最新のクラウドサービスは、IDベースのセキュリティやきめ細かいアクセス制御に重点を置く。

ステップ5．パフォーマンスのベースライン（基準値）策定とテスト

　明確なパフォーマンス指標を確立しておく。パフォーマンスの主な内容は応答時間、スループット（データ転送時間）、リソース使用率などだ。これらのベースライン（基準値）を作成することで、移行が成功したか否かの検証に役立ち、移行後に最適化が必要かどうかを判断しやすくなる。

　レガシーアプリケーションのクラウド移行で課題となりやすいのは、ネットワークの遅延だ。データセンター内の同じ場所に配置され、適切に連携していたコンポーネントが、クラウドサービスに移行すると遅延の増加によって適切に機能しないことがある。遅延の問題を軽減するため、キャッシュの実装、タイムアウトの調整、通信パターンの変更が必要になることがある。

　リソースのスケーリングも重要な考慮事項になる。クラウドサービスはリソースを動的に割り当てやすいが、そのリソースの変化にレガシーアプリケーションが適切に対処できない場合がある。包括的なテストを実施し、さまざまなスケーリング条件下でアプリケーションの動作を検証する。

ステップ6．実行

　準備が完了したら実際にクラウド移行する。まずは重要度の低いコンポーネントで検証し、潜在的な問題を早期に特定する。段階的なクラウド移行は、業務の混乱を最小限に抑えるのに役立つ。

　通常、移行時に最も注意が必要な機能はデータベースだ。データベースについては複数の計画とテストによって、データの完全性とパフォーマンスを検証するべきだ。この段階では最適化やトラブルシューティングのための時間を十分に見込んでおく必要がある。

　ただし、1つ注意点がある。データ移行の複雑さを過小評価している企業は珍しくない。移行を何度も繰り返すことを想定して、各段階でパフォーマンスを最適化する時間を確保しておく必要がある。クラウドサービスではレガシー監視ツールが十分機能しないことが多いため、クラウド監視ツールの実装を早めに検討する必要がある。

覚えておくべき重要ポイント

　レガシーアプリケーションのクラウド移行には課題が伴う。だが、それに見合う見返りもある。入念な評価、戦略的計画、慎重な実行を含む体系的なアプローチに従うことで、重要なシステムの最新化を成功に導くことができる。

　今回のポイントを以下にまとめた。

• クラウド移行によるメリットと課題のトレードオフを理解する
• 包括的な調査とITインフラ分析を実施する
• 適切な移行方針を選ぶ
• 技術的な観点での移行計画を綿密に立てる
  • 特にデータベースの移行とセキュリティ対策は重要
• パフォーマンスのベースラインを確立し、徹底したテストを実施する
• 重要度の低いコンポーネントから始めて段階的に移行する

　レガシーアプリケーションのクラウド移行は複雑になる恐れがあるが、成功すればスケーラビリティ、効率性、イノベーション（革新）につながる新たな可能性が開く。