【AI活用】マイグレーションとは？種類とモダナイゼーションとの違い

マイグレーション（migration）とは、一般的には英語で「移住・移動」を意味する言葉ですが、IT分野では「システム・データ・ソフトウェアなどを、既存の環境から新しい環境へ移し替えること」を指します。

代表的な例には、既存のシステムが持つ機能や業務の流れは基本的に変えず、稼働する場所や土台（サーバ、OS、データベース、クラウド環境など）を新しくするケースが挙げられます。移行手法によっては、コードや構造の変更を伴う場合もあります。実務では「マイグレーション作業」「マイグレーション案件」「マイグレーション対応」のような形で使われます。

図1　A社の受発注システムのマイグレーション（イメージ） 

マイグレーションとよくあわせて使われる言葉に「モダナイゼーション」があります。どちらも既存システムを見直す取り組みですが、主な目的が異なります。マイグレーションは、システムやデータ、アプリケーションなどを別の環境や製品、基盤へ「移行すること」に主眼を置いた取り組みです。一方、モダナイゼーションは、既存システムが抱える技術的な古さや課題を解消し、現在の業務や技術要件に適した形へ「刷新すること」に主眼を置きます。 

両者の違いを整理すると、次のようになります。 

ただし、マイグレーションとモダナイゼーションは明確に切り分けられるものではなく、実際のプロジェクトでは両方を組み合わせることもあります。たとえば、まず既存システムをクラウド環境へマイグレーションし、その後、アプリケーションの構造や利用技術を段階的に見直してモダナイゼーションを進める、といった方法があります。 

図2　A社の進め方の例（マイグレーション → モダナイゼーション）

▷移行・刷新の前提となる「既存システムの可視化」をAIでどう進めるかは、「LaKeel Blu」製品資料でまとめてご確認いただけます

マイグレーションは、移行対象や移行の目的、移行手法などによっていくつかの種類に分けられます。ここでは、まず「何を移すのか」という移行対象に着目して整理します。

• データマイグレーション（データ移行）：旧システムのデータを新システムへ移し替えることを指します。例えば、販売管理システムの入れ替えに合わせて、顧客や取引のデータを新システムへ移すケースなどがあります。単純にデータをコピーするだけでなく、データ形式の変換や重複・不要データの整理、欠損データへの対応などを伴うこともあります。データが正しく移行されなければ、新システムが正常に動作していても業務に支障が生じるため、移行プロジェクトの中でも特に慎重な対応が求められる工程です。
  
  
• サーバ・インフラのマイグレーション：システムが稼働するサーバやネットワークなどの基盤を、新しい環境へ移すことを指します。例えば、老朽化した物理サーバから新しいサーバへの移行や、オンプレミス環境からクラウド環境への移行などがあります。移行時には、性能や可用性、ネットワーク構成、セキュリティ、運用方法などを確認する必要があります。
  
  
• データベースマイグレーション：データベース製品やバージョン、スキーマなどを新しい環境へ移行・変更することを指します。例えば、商用データベースからオープンソースデータベースへ移行するケースや、データベース製品のバージョンアップなどがあります。データそのものの移行に加え、SQLやデータ型、ストアドプロシージャ、各種機能の互換性などが主な論点になります。
  
  
• アプリケーションマイグレーション：業務アプリケーションを新しい環境やプラットフォームへ移行することを指します。例えば、アプリケーションをそのまま別のサーバへ移すケースのほか、OSやミドルウェア、Javaなどのランタイムのバージョンアップに合わせてアプリケーションを改修し、新しい実行環境へ適合させるケースもあります。

図3　A社の受発注システムの中身と、移行対象の4つの部分

また、マイグレーションには、移行対象ではなく、移行先や目的・背景に着目した呼び方もあります。代表的なものが「クラウドマイグレーション」と「レガシーマイグレーション」です。

クラウドマイグレーション（クラウド移行）は、オンプレミスなどで稼働しているシステムをクラウド環境へ移行することを指します。インフラだけを移行する場合もあれば、アプリケーションやデータベース、データまで含めて移行する場合もあります。

レガシーマイグレーションは、老朽化・ブラックボックス化したレガシーシステムを、現在の業務や技術要件に適した環境へ移行・刷新する取り組みを指します。そのため、特定の移行対象だけを表すものではなく、アプリケーション、データベース、インフラ、データなど複数の領域にまたがるプロジェクトになることがあります。企業のDX推進においても重要なテーマの一つであり、具体的な手法やメリット・デメリット、進め方については、別の記事「レガシーマイグレーションとは？目的・メリット・進め方をまとめて解説」で詳しく解説しています。

このように、マイグレーションは「何を移すのか」だけでなく、「どこへ移すのか」「なぜ移すのか」によっても呼び方や注意点が変わります。まず自社で検討しているマイグレーションが、どの領域を対象とし、何を目的としているのかを整理しておくと、その後の情報収集や計画を進めやすくなります。

マイグレーションは、自社のIT戦略や業務上の判断から計画的に進める場合もあれば、製品のサポート終了など、外部の事情によって対応時期が決まる場合もあります。代表的なきっかけとして、次のようなものがあります。

• サポート終了（EOL）：OS・データベース・ミドルウェアなどのサポート終了は、バージョンアップや新しい環境への移行を検討する代表的なきっかけです。サポート終了後も使い続けると、新たに発見された脆弱性に対するセキュリティアップデートを受けられなくなったり、障害発生時にベンダーのサポートを受けられなくなったりする可能性があります。
  
  
• ハードウェアの老朽化・保守終了：サーバなどの機器が老朽化したり、メーカーによる保守期間が終了したりすることで、新しい稼働基盤への移行が必要になるケースです。性能や容量が現在の業務要件に対応できなくなったことをきっかけに、移行を検討する場合もあります。
  
  
• クラウド化・IT戦略の転換：「クラウドファースト」などのIT戦略の変更に伴い、オンプレミス環境からクラウド環境への移行を進めるケースです。インフラだけでなく、アプリケーションやデータベースを含めて見直すこともあります。
  
  
• コスト・運用負荷の削減：古いシステムの維持・保守にかかるコストや、特定の担当者に依存した運用体制を見直すことを目的として、マイグレーションを実施するケースです。
  
  
• 事業・組織の変化：企業の合併・買収（M&A）や事業再編、組織統合などをきっかけに、複数のシステムを統合したり、データや業務基盤を新しい環境へ移行したりするケースです。

特に、製品のサポート終了や機器の保守終了が関係する場合は、対応期限があらかじめ決まっていることが多くあります。そこから移行期間を逆算すると、調査や検討、設計、テストなどに使える時間は想定以上に限られることもあります。

図4　サポート終了から逆算した、A社の移行スケジュール（例）

きっかけが何であれ、まず移行対象や関連するシステムの全体像を把握しておくことが、その後の計画をスムーズに進めるうえで重要です。

▷サポート終了を控えた基幹システムの移行先の選び方については、別の記事「AS/400のサポート終了にどう備える？基幹システムのモダナイゼーションの必要性と選択肢」で、AS/400を例に解説しています

マイグレーションの具体的な進め方は移行対象や方式によって異なりますが、基本的には次のような流れで進めます。

図5　マイグレーションの基本ステップ

1. 現行調査・棚卸し：移行対象となるシステムやデータ、インフラ、関連システムとの依存関係などを洗い出し、現状を把握します。

2. 移行計画の立案：移行範囲や移行方式、スケジュール、実施体制、業務停止の許容範囲などを整理し、移行計画を立てます。あわせて、問題が発生した場合に旧環境へ戻す方法や判断基準についても検討します。

3. 移行設計・事前準備：新しい環境の構成や移行手順、データの変換方法、システム間の切り替え方法などを設計します。データ移行を伴う場合は、重複・不要データの整理や変換ルールの策定なども行います。

4. リハーサル（移行テスト）：本番移行を想定したテストを行い、移行手順や所要時間、システムへの影響、問題発生時の対応などを確認します。必要に応じて、リハーサルの結果をもとに手順や計画を見直します。

5. 本番移行・移行後の検証：計画した手順に沿って本番環境への移行を実施します。移行後は、新しい環境でシステムが正常に稼働していることや、データが正しく移行されていること、業務に問題がないことなどを確認します。

特に重要なのが、最初の現行調査・棚卸しです。現行システムの構成や依存関係を十分に把握できていないと、移行範囲の漏れや想定外の影響が発生し、その後の計画や設計にも影響します。そのため、移行計画を立てる前に、現状をできるだけ正確に把握しておくことが重要です。

移行計画を立てる際の重要な論点の一つが、旧環境から新環境へどのように切り替えるかです。代表的な考え方として、「一括移行」と「段階移行」があります。

• 一括移行方式（ビッグバン方式）：あるタイミングで、対象となるシステムや業務を旧環境から新環境へ一斉に切り替える方式です。切り替えを一度に行えるため、長期間にわたる新旧環境の併存を避けやすい一方、移行時に問題が発生した場合の影響範囲が大きくなりやすいという特徴があります。
  
  
• 段階移行方式：機能や部門、拠点などの単位に分けて、段階的に新環境へ移していく方式です。一度に移行する範囲を限定できるため、問題発生時の影響を抑えやすい一方、移行期間が長くなりやすく、新旧システム間のデータ連携や運用が必要になる場合があります。

このほか、移行時のリスクを抑えるために、これらと組み合わせて使われる方法もあります。

たとえば、並行運用（パラレル）では、新旧システムを一定期間並行して稼働させ、処理結果などを確認したうえで新システムへ切り替えます。新システムの問題を確認しやすい一方、一定期間は両方のシステムを運用する必要があるため、運用負荷やコストが増えることがあります。

また、パイロット移行では、特定の部門や拠点、業務などを先行して新環境へ移行し、そこで得られた課題や知見をその後の移行に反映します。段階移行の一つの進め方として採用されることもあります。

どの方法が適しているかは、システムの重要度や業務停止の許容度、移行対象の規模、体制、システム間の依存関係などによって異なります。

特にシステム間の依存関係が強い場合は、一部だけを切り離して移行することが難しいケースがあります。そのため、現行調査で依存関係を把握し、どの単位で安全に移行できるかを見極めたうえで、適切な移行方式を選ぶことが重要です。

マイグレーションは、単にシステムやデータを新しい環境へ移せば完了するものではありません。実際に進める際には、次のような課題が生じることがあります。

• 既存システムの全体像を把握できない：設計書が古い、あるいは残っていない、仕様を把握している担当者がいないといった理由から、現在のシステムがどのような構成・仕様になっているのかを十分に把握できないケースがあります。移行対象やシステム間の依存関係が分からなければ、移行範囲の特定や工数の見積もり、移行計画の策定も難しくなります。特に、長期間にわたって改修を重ねてきたレガシーシステムでは注意が必要です。
  
  
• データ移行が複雑になる：長年蓄積されたデータには、重複や欠損、現在は使われていないデータ、独自の形式などが含まれていることがあります。新しいシステムで利用できる形へ整理・変換する必要があり、想定以上の工数がかかる場合があります。
  
  
• 互換性やシステム間の依存関係への対応：OSやミドルウェア、データベース、ライブラリなどを変更すると、既存のアプリケーションがそのまま動作しない場合があります。また、他のシステムや外部サービスとの連携がある場合は、移行による影響範囲を事前に把握しておく必要があります。
  
  
• 業務停止・切り替え時のリスク：本番移行では、一時的にシステムを停止しなければならない場合があります。停止できる時間が限られているシステムでは、決められた時間内に移行を完了させる必要があります。また、切り替え後に問題が発生すると業務に影響するため、事前のリハーサルや切り戻し方法の準備も重要です。
  
  
• 必要な人材を確保しにくい：移行には、既存システムの仕様や業務を理解している人材と、新しい技術や環境に詳しい人材の両方が必要になることがあります。特に古い技術を利用したシステムでは、旧環境に詳しい人材が限られており、体制づくりが難しくなるケースがあります。

中でも、既存システムの全体像を把握できないことは、移行対象の特定や工数の見積もり、その後の設計・テストにも影響します。こうした現行システムの調査や情報整理を支援する手段の一つとして、近年ではAIを活用する方法も考えられます。次章では、マイグレーションにおけるAI活用について見ていきます。

マイグレーションにおける現行システムの調査や棚卸しでは、AIを活用して作業を効率化する方法もあります。

AIで既存システムのソースコードや設計書を解析すれば、システムの構造や機能、データ、依存関係などの整理を支援できます。設計書が残っていない場合でも、ソースコードを手がかりに現在の仕様を読み解いてドキュメント化できるため、移行対象の整理や移行方式の検討、データ移行の設計も進めやすくなります。

ただし、AIの解析結果だけで現行仕様を確定できるわけではありません。ソースコードからは分からない設定や外部システムとの連携、運用状況は実環境と照合し、なぜ現在の仕様になっているのかという業務上の背景は、現行業務を知る担当者に確認する必要があります。そのうえでAIを活用すれば、人がすべてを手作業で調査する場合と比べて、調査工数の削減が期待できます。

図6　現行調査でAIが支援することと、人が行うこと

その一例が、ラキールの製品「LaKeel Blu」です。LaKeel Bluでは、複数のAIエージェントが連携し、現行システムの解析から要件定義・基本設計までの上流工程を支援します。

そのうち現行解析エージェントは、既存システムのソースコードや設計書を解析し、システムの構造や依存関係などを整理します。また、既存の設計書を実際のソースコードに合わせて最新化したり、設計書がない場合には新たに生成したりすることで、移行・刷新の前提となる現行システムの把握を支援します。

▷AIでソースコードを解析し、設計書を作成・最新化する進め方については別の記事「AIによるソースコード解析・設計書の自動生成」で、AIを活用したモダナイゼーション全体の進め方については別の記事「AIで進める業務システムのモダナイゼーション」で詳しく解説しています

マイグレーションというと、システムやデータを新しい環境へ移す作業に目が向きがちです。しかし、本記事で見てきたとおり、移行対象によって注意すべきポイントは異なり、移行方式によっても進め方は変わります。また、実際のプロジェクトでは、マイグレーションとモダナイゼーションを組み合わせて進めることもあります。

重要なのは、移行を始める前に「何を、なぜ、どのように移行するのか」を整理することです。まずは、データ、インフラ、データベース、アプリケーションなど、どの領域が移行対象になるのかを把握します。そのうえで、既存システムの構成や依存関係、設計書などのドキュメントの整備状況、現行仕様を把握している担当者の有無などを確認します。

こうした現行システムの把握が、その後の移行範囲の特定や工数の見積もり、移行方式の選択、移行計画の精度を高めるための第一歩になります。

【関連記事】
・「仕様書がない・ブラックボックス化したシステムを刷新する方法」
・「【AI活用】リバースエンジニアリングとは？現行システム解析の進め方をご紹介」
・「データハブとは？データハブを活用した段階的なシステム移行のメリットや従来の移行方法との違いも解説」