目次
マイグレーションは、基幹システムを新しいプラットフォームへ移行したり、OSやハードウェアなど環境が異なるシステムへ移行したりするデータ資産の移行作業です。
既存のITシステムが老朽化や肥大化、ブラックボックス化によって使いづらくなり、企業の競争力低下を招く「2025年の崖」が顕在化する中、マイグレーションに取り組む企業も多いのではないでしょうか。
とはいえ、非IT部門の担当者の方を筆頭に、マイグレーションの仕組みがわからない方も少なくありません。
そこで、本記事では、マイグレーションの意味やメリットについて解説します。実行時の注意点についても説明するため、ぜひ参考にしてください。
マイグレーションは、データやソフトウェアなど既存のアプリケーションを再利用して新たなプラットフォームへ移行する手法です。「移動、移住、移転」を意味する英語の「migration」が語源とされます。
IT領域では、古くなったり、破損したりしたデータやアプリケーション、オペレーションシステム(OS)などを、クラウドコンピューターなどの新しく用意した別の環境に移し替えたり、切り替えたりすることを指します。
後ほど詳説しますが、マイグレーションの最大のメリットは、既存アプリケーションを再利用することで、新規の開発量を抑え、短期間かつ安価にシステムを移行できることです。
開発側が既存のビジネスロジックを踏襲できるため、システムの完成度も既存システムと同等に保てるのも魅力の一つとなっています。
なお、マイグレーションの事例には次のようなものがあります。
これらのマイグレーションは、綿密な計画とITインフラの自動化戦略を組み合わせることで、移行が容易になります。
マイグレーションの手法には、大きく分けて「ライブマイグレーション」「データマイグレーション」「レガシーマイグレーション」の3つがあります。
それぞれで目的が異なるため、適切な方法を選ぶことが重要です。
ライブマイグレーションは、仮想環境下で稼働中の仮想マシンを、別の物理サーバーに無停止に等しい状態で移行する技術です。
対象となる仮想マシンのメモリイメージが移動する際はごく短いネットワークの瞬断が生じるものの、移行にかかるダウンタイムはほぼゼロ秒です。これにより、仮想マシンの利用者が仮想マシンの移動を意識せずに利用できます。
ライブマイグレーションが実行例としてあがるのが、稼働中の物理サーバーが重くなった時です。稼働中の物理サーバーの負荷が高まると、サーバーダウンのリスクが上昇しますが、ライブマイグレーションにより、既存の物理サーバーの仮想マシンを、別の物理サーバーに移動させることで、負荷が均一化されます。
データマイグレーションは、異なるデータ形式やアプリケーション間で、データを移動させるプロセスです。主にストレージ容量の拡張やパフォーマンスの向上、データ管理の合理化、コスト削減、新機能の追加を目的としたアップグレードの一部として行われます。
データの移行が十分ではない場合は、不正確なデータを使用することになりかねません。こうしたリスクは、ソースデータが完全に使用可能で適切な場合でも発生する可能性があります。さらに、ソースデータに存在していた問題が、新しいシステムに取り込まれた際に増幅するリスクがあります。そうしたリスクへの対処に役立つのが、データマイグレーションなのです。
データマイグレーションは、計画と実行、検証の3つのフェーズで展開されます。形式はネットワーク経由で大量のデータを転送したり、古いハードウェアから新しいハードウェアへ物理的に移動したりする場合など、多様であり、適切な方法を選ぶとよいでしょう。
レガシーマイグレーションは、1960年代から90年代ごろまで存在した、「メインフレーム」や「オフコン」と呼ばれる古いコンピューターで作られたシステムを新しく作り変えることです。
保守などに多額の費用を要するうえ、特定のメーカーで作られたコンピューターでしか作動しないシステムから、UNIXやWindowsなどオープンな規格で作られたシステムに刷新することで、自由度を高め、ライセンス料の削減などの効果を得る目的で行われます。
ただし、昨今は、ハードウェアをリプレースしようとしても、業務アプリケーションに対応している古いOSが、新しいハードウェアに対応していないケースが少なくありません。そうした中で、仮想化技術を活用したレガシーマイグレーションに注目が集まっています。
マイグレーションのメリットは、次の3つに集約されます。
それぞれ大きな利点であるため、ぜひ留意しておくとよいでしょう。
前述の通り、マイグレーションは既存のアプリケーションを再利用し、新規の開発量を抑えられるため、コスト削減が可能です。
コスト削減効果が発生するのは、マイグレーション時だけではありません。例えば、データサーバーをオンプレミスからクラウドに移行すれば、保守・運用コストの大幅カットが実現されます。
マイグレーションはシステム再構築に必要な上流工程が不要であり、現有資産を有効活用しながら安全に移行できます。
具体的には、現有資産の構造を新しいシステムへと引き継ぎ、新たなプログラミング言語へと変換するため、現有資産の構造を大幅に変更することはありません。
また、ラッパーと呼ばれる部品で言語の違いを吸収すれば、現有資産と大差がない状態のソースコードを作り出せるため、移行後に現行の保守要員を継続して保守業務に当たらせられるでしょう。
この点、既存のソフトウェア資産を捨て、要件定義から実施し、機能要件をもとに一から新しいシステムを構築するスクラッチとは一線を画す手法といえるでしょう。
使用する言語をCOBOLなどのレガシー言語からJavaに切り替えるなど、マイグレーションによりオープンなシステムに移行することで、人工知能(AI)やIoT(モノのインターネット)といった新技術の導入が容易になります。
オンプレミスでは利用状況に合わせたリソースの追加ができないだけに、マイグレーションによる新技術の導入は、革新的なデジタルトランスフォーメーション(DX)かもしれません。
マイグレーションは手順に沿って実行すればよいわけではありません。注意点として次の3つが存在します。
最後にこの3つの注意点を解説します。
ほかのITプロジェクトと同じように、マイグレーションは、現有資産を見える化を行い、現在のステータスを評価することが重要です。
例えば、データマイグレーションの場合、移行する必要のあるデータ、データの保存場所、現在のデータ形式、移行後のデータ形式を特定する必要があるでしょう。
また、現有資産の見える化と並行して、マイグレーションを完了させるために必要なタスクを網羅したチェックリストの作成もおすすめします。
マイグレーションは移行するデータやシステムごとに難易度が変わる点に留意しなければなりません。
例えば、業務システムのマイグレーションは難易度が高いと言われています。開発側がプログラムの目的や移行するデータの形式を理解する必要があるほか、リソース規模が拡大すればするほどシステムが複雑化するためです。これらを踏まえ、業務システムのマイグレーションは前工程で業務習得や調査に時間をかけなければなりません。
他方で、サーバーマイグレーションであれば、移行先のシステムに合わせて使用言語を変更する必要があるでしょう。
マイグレーションは移行したら終了ではなく、保守運用・中長期を見据える必要があります。
具体的には、マイグレーションの完了後は、新たなクラウドシステムやOSが通常の運用を中断することなく、同じ結果を生み出しているかチェックしましょう。
マイグレーションは、費用対効果の高いシステムの導入や、高いスケーラビリティを有したシステムの獲得を図るうえで欠かせません。
また、企業が前時代的なレガシーシステムを刷新し、業務の生産性と事業の収益性の向上を図るためにも不可欠です。
このような効用があるだけに、適切な方法にのっとったマイグレーションは、必ずやビジネスのイノベーションとDXの推進に役立つのは間違いないでしょう。
TSRI社のJANUS Studio®は、マイグレーションだけではなくレガシーシステムにおける様々な課題を解決しています。
ドキュメントがない、または不十分でも現在ご利用中のコードさえあれば「Application BluePrint®」「Transformation BluePrint®」でドキュメントを自動生成することが可能です。
また、JANUS Studio®ではお客様ご自身のソースコードを一部お借りしてテスト解析を行う、無料BluePrint® Previewもご用意しています。
Application BluePrint®(アプリケーションブループリント)とは、ソースコードの現在の形がHTML化されたドキュメントです。
ソースコードとターゲットコードがハイパーリンク化され、チャートやグラフを用いたソースコードの “AS-IS ”ドキュメント(旧システムの実体)を図として表示します。
Transformation BluePrint®(トランスフォーメーションブループリント)とは、AS-IS(既存システム)を解析し文書化します。
さらに、 “TO-BE” ドキュメント(変換された新しいシステム構造)を図示します。ここでは、変数、データ構造とデータフロー、制御フローと原因/結果モデル、複雑さの指標、外部インターフェイスの呼び出し、不使用コードと冗長コードの解析、類似・同一コードなどの解析が行えます。
© TSRI & Nippon RAD Inc. All rights reserved.