レガシーなアプリケーションのアップグレードは、慎重な計画と戦略的な意思決定を必要とする複雑なプロセスだ。IT管理者は、企業の目標、リソース、および長期的なIT戦略に沿った最も適切なアプローチを選択する必要がある。

リプラットフォームオプション：オンプレミスインフラ

　ビジネスクリティカルなアプリケーションが時代遅れのハードウェアやソフトウェア上で実行されている場合、リプラットフォーム戦略が適切である可能性がある。この手法では、アプリケーション機能の中断を最小限に抑えながらインフラをアップグレードすることができ、全面的なリエンジニアリングの取り組みと比較して低いコストで即時的なメリットを得ることができる。

　一般的なシナリオとしては、リフト&シフトが挙げられる。これは、例えば「Windows Server 2008」から「Windows Server 2016」へアプリケーションを移行することが挙げられる。アプリケーションのコードに大きな手を加えることなく、古いプラットフォームの課題を解消できる手法だ。

　移行先のプラットフォームがアプリケーションを標準ではサポートしていない場合は、コンテナの使用を検討するのも手だ。「Docker」は、アプリケーションとその実行に必要なライブラリや設定などを「コンテナ」と呼ばれる単位でまとめる技術だ。これを使ってアプリケーションのコードと依存関係をパッケージ化すれば、基盤となるインフラからアプリケーションを切り離し、異なる環境でも一貫した動作が可能になる。

　例えば、Javaアプリケーションの実行基盤として広く使われている「Apache Tomcat」を使用する場合、コンテナに移行することで、本番環境や開発環境など異なる環境間でも設定の違いによる不具合を防ぎやすくなる。これにより、アプリケーションの機能や挙動の一貫性を保ちやすくなる。

リプラットフォームオプション：クラウド移行

　クラウド移行もプラットフォームを移行する一手段だが、オンプレミスインフラとは異なる前提条件や注意点がある。例えば、データの移動に伴うセキュリティリスクや、従量課金によるコストの変動、アクセス権限や認証の設計見直しなど、検討すべき事項は多岐にわたる。クラウドコンピューティングの3つのタイプに基づいて、考慮すべき例を以下に示す。

• Infrastructure as a Service（IaaS）
  • アプリケーションをクラウドベースの仮想マシン（VM）に移行することは、Windows Serverのワークロードを最小限の変更でクラウドに移行するのと同じくらい簡単な作業となる場合がある。大規模なアプリケーションは、「マイクロサービス」と呼ばれる小さな独立機能の集合体に分解することで、機能ごとの開発や更新、障害対応を個別に実施できるようになる。
  • 特に効果を発揮するのが、機能が多岐にわたる大規模な業務システムの場合だ。例えば、SAPに代表されるERP（基幹業務システム）プラットフォームや、「SharePoint」のような電子文書・記録管理システムなどは、マイクロサービスによるモジュール化によって、各機能の管理やアップデートをより効率的に実施できるようになる。
• Platform as a Service（PaaS）
  • サーバレスコンピューティングに代表されるPaaS（Platform as a Service）の選択肢は、小規模または構造が単純なアプリケーションの最新化に適している。アプリケーションの一部機能やインフラ運用をクラウドベンダーに委ねることで、従来型の複雑なミドルウェアや老朽化したテクノロジーへの依存を排除でき、運用リスクの軽減につながる。
  • エンドユーザーの近くでワークロードを実行できる構成にすることで、パフォーマンス向上やコスト削減の効果も期待できる。具体例としては、「WordPress」や「Drupal」「Joomla」といったCMS（コンテンツマネジメントシステム）にPaaSを活用するケースが挙げられる。
• Software as a Service（SaaS）
  • レガシーなアプリケーションを完全に管理されたSaaSに置き換えることで、将来のメンテナンスやアップグレードの必要性をなくすことができる。

ライブラリアップグレード

　ライブラリアップグレードは、主に互換性の課題を解決し、特定ベンダーに依存した構成からの脱却（ベンダーロックインの回避）にも貢献する。複雑なアプリケーションの完全な再構築が現実的でない場合、基盤となるライブラリのアップグレードが効果的な代替手段となる可能性がある。

　例えば、古いJavaランタイム上に構築されたアプリケーションをオープンソースのJDK（Java開発キット）である「OpenJDK」の最新バージョンにアップグレードすることで、アプリケーション全体を刷新することなく互換性の問題を解決できる。専有ライブラリをオープンソースの代替品に置き換えることでコストを削減し、ベンダーロックインを軽減できる。

　その一例が、JavaアプリケーションからリレーショナルデータベースにアクセスするためのAPI（アプリケーションプログラミングインタフェース）である「Java Database Connectivity」（JDBC）に対応した、Oracleの専用JDBCドライバから「PostgreSQL」のオープンソースドライバへ切り替えることだ。これはベンダー依存やライセンス制限といった制約を回避するための戦略的な選択肢となる。

リエンジニアリング

　レガシーアプリケーションがビジネスにとって不可欠な存在である一方で、パフォーマンスのボトルネックやスケーラビリティの限界に直面している場合は、そのアプリケーションを最新のアーキテクチャ、あるいはモジュール化された構造へと再設計（リエンジニアリング）する価値がある。

　例えば、ピーク時のトラフィックを処理できないeコマース（電子商取引）のシステムは、マイクロサービスにリエンジニアリングすることで応答性とスケーラビリティを向上させることができる。同様に、あるアプリケーションが、時代遅れのコードやサポートされていないソフトウェアによる重大なセキュリティ脆弱（ぜいじゃく）性に直面しているとする。リエンジニアリングによって、より安全で最新のフレームワーク上にアプリケーションを再構築し、現在のセキュリティ基準を確実に満たすようにし、進化する脅威からアプリケーションを将来的に保護することができる。

データの最新化

　継続的な運用コストの削減を優先する場合、データを多く扱うレガシーなアプリケーションにとってデータの最新化は非常に重要だ。

　例えば、「Microsoft SQL Server」のような商用データベースを対象に、データベース構造の最適化や、より効率的なクラウドストレージへの移行を進めることで、システム全体のパフォーマンスとスケーラビリティを大幅に向上させることができる。これにより、老朽化したインフラの制約を解消し、将来の成長にも対応しやすくなる。この変更により、時代遅れで非効率的なストレージシステムを維持するためのオーバーヘッド（余分な処理による負荷）を合理化し、長期的なコスト削減とシステムの信頼性向上につながる。

セキュリティ強化

　コンプライアンス基準を満たすことや脆弱性に対処することが優先事項の場合、セキュリティ強化に焦点を当てることが不可欠となる。

　例えば、レガシーアプリケーションでは、セキュリティ強化のために多要素認証（MFA）の導入や、機密データの暗号化、監査目的のログ収集と保管が求められることがある。それに加えて、システム全体を監視するツールを統合すれば、脅威をリアルタイムで検出し、対処できる体制を構築できる。これにより、アプリケーションの安全性を高めるとともに、現行のセキュリティ規制への準拠を継続的に維持することが可能になる。

API有効化

　APIの有効化は、既存アプリケーションを全面的に作り直すことなく、最新システムとの相互運用性を実現したい場合に有効な選択肢となる。古いシステムと新しいクラウドサービスや外部ツールをつなぐ手段として、段階的なモダナイゼーションを可能にする。

　例えば、「Salesforce Classic」のようなレガシーなCRM（顧客関係管理）システムにAPI機能を追加すれば、システム全体を一から書き換えることなく、最新のクラウドサービスと連携してデータ交換や機能拡張が可能になる。このアプローチによって、従来のシステムと新しいテクノロジーが共存、連携し、段階的なモダナイゼーションを実現できる。将来的なフルアップグレードに備える基盤を築きながら、短期的にも業務上のメリットを得られる点が特徴だ。

　次回は、レガシーアプリケーション最新化のための現実的な進め方を探る。