「マイグレーション」とは?意味や実施手法、プロセスを解説

最終更新日時:2022.05.09 (公開日:2022.04.05)
「マイグレーション」とは?意味や実施手法、プロセスを解説

「マイグレーション(Migration)」とは、ソフトウェアやデータ、システムを移転することです。2018年、経済産業省は『DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~』で『デジタルトランスフォーメーションを推進するにはITシステムの「2025年の崖」を克服する必要がある』と指摘しました。この"崖"を攻略できなければ、年間最大12兆円の経済損失が生じると予測しています。このDXを阻む"崖"を生じさせる原因の一つが"レガシーシステム"です。そして、このレガシーシステム問題を解決する切り札がマイグレーションだといわれています。そこで今回はマイグレーションについてまとめました。

もくじ

1. マイグレーション(Migration)とは?

マイグレーションの意味

日本では一部で「マイグレ」と略されている「マイグレーション(Migration)」。「移動」「移転」「移行」といった意味の英単語で、IT業界では、既存のソフトウェアやデータ、システムを別の新たな環境に移転することです。基本的に、既存システムの要件を変更せずにソフトウェアやデータを別の環境に移動したり、基幹システムを変更したりして新たな環境を構築し、新しいシステムに乗り換えることを指します。「システム刷新」と記されることもあります。

一例ですが、開発言語をCOBOLからJava、VB6.0からVB.NET、AS400/RPGからCOBOLオープンシステムへ移行するなど、古い開発言語を現代的な開発言語に移行することがマイグレーションです。また、自社運用のオンプレミスのシステムをクラウド環境へ移行することもマイグレーションといいます。その他さまざまな場面でマイグレーションという言葉が使われますが、次に述べるような背景もあって、長年使われてきたオンプレミスのシステム(レガシーシステム)からクラウド環境への移行を指すことが増えてきているようです。

マイグレーションが注目を集めた背景

2018年、経済産業省が公開したレポート『DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~』内で、『ITシステムの「2025年の崖」を克服することができなければ、日本のデジタルトランスフォーメーション(DX)は進展せず、年間最大12兆円の経済損失が生じていく』と指摘しています。この"崖"を生じさせる原因の一つが「レガシーシステム」で、問題解決の鍵となるのがマイグレーションであることから、大きく注目を集めることになりました。

「レガシーシステム問題」を解決する手段として有効

このように、デジタルトランスフォーメーションにとって「足かせ」のような重大課題となっているレガシーシステム問題を解決する最善手がマイグレーションです。

レガシーシステムとは、端的にいうと古くなりすぎたコンピュータシステム、とくに長年使われてきたオンプレミスのシステム、基幹システムのことを指します。先ほどの経済産業省『DXレポート』では、古い(レガシー)システムでは技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化といった問題があると指摘しています。なお、レガシーシステムを「過去にメインフレーム向けにCOBOLでプログラミングされた基幹系システム(「失敗しないレガシーマイグレーションとは」IBM、外部リンク)と定義している文書もあります。

先ほどの『DXレポート』では、一般社団法人日本情報システム・ユーザー協会(JUAS)による2017年度の調査を引用して、日本の約8割の企業が「レガシーシステム」を保有しており、約7割が「レガシーシステム」が自社のデジタル化の足かせになっていると回答したと記しています。そしてレガシーシステム問題を解決するには「システム刷新」つまり、マイグレーションが必要だとしています。

マイグレーションは次のようにレガシーシステム問題の解決を目的に実施され、「レガシーマイグレーション」といわれることもあります。

  • ハードウェアが古くなり老朽化、陳腐化して発生する故障リスク回避
  • システムやソフトウェアの保守期限を越えた際のリスク回避
  • OS、ミドルウェア、ソフトウェアのサポート終了後に放置されるシステム脆弱性によるトラブル回避

長年使われてきたオンプレミスのシステムでは、利用者が増えたり、扱うデータが増加したりすることで性能が低下することも予測できます。また、古くなることでシステムを熟知したエンジニアの確保が困難になるなど、運用コストが膨張してしまうことも考えられます。

こういった問題をマイグレーションで解決できれば、保守性が向上します。さらに生産性を向上させ、DXを実現することができます。近年では、長年に亘って使われてきた古いオンプレミス環境からクラウド環境に移行させるのが主流のようです。クラウド環境を活用し、社内にサーバなどを設置しないサーバレス・コンピューティングも広まりを見せています。調達がしやすいことから、SaaSサービスの利用を検討する企業も多いようです。

データ環境の最適化にも用いられる

また、データフォーマットなどデータをシステムやストレージ間で移行させる、データマイグレーション(データ移行)も行われます。データベースを移行したり、古くなった記憶媒体から新しい記憶媒体へ移行(ストレージ移行)したりしてデータを異なる環境へ移行します。データベース、ストレージに関する技術も日進月歩で進化していますので、データマイグレーションによって劇的な効率向上が図れることもあります。

2. マイグレーションを実施する手法

マイグレーションを実施する主な手法を紹介します。それぞれ目的や難易度が異なり、ここで紹介するものでは、「リホスト」「リライト」「リビルド」の順に難しさが増すとされています。

リホスト(Rehost)/リホスティング(Rehosting)

「リホスト(Rehost)/リホスティング(Rehosting)」は、インフラ刷新ともいいます。使用言語やプログラムのロジックを変えずに現在のプラットフォームだけをIaaSのクラウド環境などのインフラに移行する手法です。既存のプログラムの仕様を継承することで、移行の負荷も少ない手法とされています。しかし、ソフトウェア(アプリケーション)内のレガシーな要素が残ってしまうことが多く、内部に蓄積されたコードクローン問題(既存コードのコピーを繰り返すことでバグ等が内包されてしまう問題)を受け継いでしまう可能性があると指摘されています。

リライト(Rewrite)/リライティング(Rewriting)

リライト(Rewrite)/リライティング(Rewriting)は、プログラムのロジックを変更しないで、使用言語とプラットフォームを新たなものに移行する手法です。使用言語とプラットフォームがモダンなものに移行されるため、最新のテクノロジーを利用しやすくなり、さらにデジタルトランスフォーメーションを推進しやすくなるメリットがあります。ただし、リライトもリホストと同じく、プログラムロジック上のレガシー問題を継承してしまう可能性があります。

リビルド(Rebuild)

レガシーシステムに起因する問題を受け継がないようにするため、全てを作り直す手法がリビルド(Rebuild)です。システム再構築といわれることもあります。レガシーシステム問題を解決するためには最適な手法の一つです。

他の手法

マイグレーションの手法には、他に既存システムのアーキテクチャやプログラムの仕様に変更をくわえず、プログラムの内部構造を解析してソースコードの可読性を高め、修正更新を実施しやすい状況へと改善する「リファクタリング(スリム化)」や、既存システムの一部、または全てを破棄してしまって、外部ベンダーが提供するSaaSサービスに移行する「SaaS移行」といったものがあります。

3. マイグレーションと似ている他の用語との違い

マイグレーションと混同しやすいのが「コンバージョン」と「リプレース」です。違いはどこにあるかまとめてみます。

コンバージョン(Conversion)とマイグレーションとの違い

コンバージョンとは、英語で「変換」「転換」という意味で、データやファイルを別の形式に変換することです。例えば、文字コードShift-JISをUTF-8に変換するとき「文字コードをShift-JISからUTF-8にコンバージョンする(コンバートする)」というように使われます。

マイグレーションは新しい環境への移行を示すのに対し、コンバージョンは異なるものへ文字通り変換することを示しています。「古いものから新しくする」か「あるものを別のものに変える」かが異なります。

リプレース(replace)とマイグレーションとの違い

リプレースは、既存のシステムやデータベース、ソフトウェアといった資産を同等の基盤へと移すことをいいます。老朽化したり、故障・破損したりした機器の入れ替えを指す言葉です。マイグレーションと比べて異なるのは、"既存のものと同等"であることです。マイグレーションのようにシステムや言語、プラットフォームなどは変更しません。故障や破損はリプレースで対応可能ですが、サポート切れなどで旧式のシステムを最新版に移行する場合はマイグレーションということになります。

4. マイグレーションはどんなプロセスで実施するのか

マイグレーションの作業プロセスは、一般的に大きく4つに分けられます。(1)検証・分析、(2)設計、(3)移行、(4)テストです。

検証・分析段階

検証・分析段階では、実際に行われている業務状況を把握することや、資産の詳細な確認、そして移行する資産(捨てる資産)の選定をしてマイグレーション手法を決めていくことが多くなっています。どのような資産があり、どれが必要なのか見極めることが重要になってきます。移行後に予想される投資効果と対比して決めていくことになります。プロトタイプの準備を始めるのもこの段階です。

設計段階

設計段階では、検証・分析して決めたマイグレーション手法に最適なツール類を決め、ツールの設計(開発)カスタマイズをしていきます。綿密なデータクレンジングを行うと同時にテストデータなどを用いて、設計が適切か評価します。

移行段階・テスト

移行段階では、何度かのリハーサルと正確性を確認した後に実際の移行作業を実施します。移行後は、それが正確に実施できたかをテストします。抜け漏れなく進めるためには、詳細なテスト、確認が必要となります。検証段階から、しっかり計画を立てるのがマイグレーションを成功させるポイントです。

5. まとめ

デジタルトランスフォーメーション(DX)を推進するには、レガシーシステムのオープン化が必要です。そのためには、マイグレーションプロジェクトの成功がカギとなります。本記事でも説明してきたレガシーマイグレーション、データマイグレーション、アプリケーション(ソフトウェア)移行、ストレージ・データベースの移行などやるべきことは多々あります。「何がまず必要なのか?」「次は?」と長期的なロードマップにしたがって、着実にマイグレーションを進めていくことが、DX成功の近道といえるかもしれません。

執筆者:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。