マイグレーションとは？手法や種類、失敗しないための注意点までわかりやすく解説

近年、老朽化したシステムの更新やクラウドへの移行でシステムを入れ替えるケースが増えてきています。ハードウェアやソフトウェアが老朽化したシステムでは、パフォーマンスの低下やサポート切れによるセキュリティリスクの増大、エンジニアの採用難などの障壁が起こりえます。
2018年には経済産業省から、日本でDX推進が十分におこなわれなかった場合の将来について「2025年の崖」というキーワードで警鐘が鳴らされました。
世界的にDXの推進が叫ばれるなか、これらの課題を解決する有効な手段の1つに「マイグレーション」があります。マイグレーションにはいくつもの手法があり、自社のシステムに応じた適切な方法で実施することが非常に重要です。

ここでは、マイグレーションの概要や目的、種類、手法、手順や注意点までをわかりやすく解説します。

＞＞　マイグレーションに関するご相談はこちら

マイグレーション（migration）とは、「移動」「移転」などを意味する言葉であり、IT分野では既存のシステムやソフトウェア、データなどを別の環境へ移すことを指します。
オンプレミスからクラウドへの移行、古い開発言語から現代的な開発言語への移行、アプリケーションの移行などがマイグレーションにあたります。

企業がシステムのマイグレーションをおこなうおもな目的として、次のようなケースがあげられます。

古いシステムではパフォーマンスが落ち、不具合やトラブルが発生するリスクが高まります。加えて、古いシステムアーキテクチャではAIやIoT、クラウド、ビッグデータなどの技術トレンドへの対応が制限されるケースもあります。
マイグレーションをおこない、老朽化したシステムから脱却することでそういったリスクを低減させられるほか、新しい技術やデバイスにも対応できるようになれば企業の競争力強化にもつながるメリットがあります。​​​​

＞＞システムの老朽化対策によるマイグレーション事例はこちら

アプリケーションやOS、ミドルウェア、ハードウェアなどは提供元があらかじめ定めた期間を過ぎるとサポートが終了します。サポートが終了するとセキュリティホールが発見されても対処されず、情報漏洩などのセキュリティリスクが高まります。ハードウェアも同様に、メーカーの保守サポートが切れると自社で対応しなければならなくなり、故障時の対応がかなり困難になります。
そのような事態に陥らないためにも、サポート切れのタイミングをあらかじめ把握しておき、計画的にマイグレーションをおこなうことが求められます。

「レガシーシステム」とも呼ばれる古いシステムは、COBOLなどの最近ではあまり使われなくなった言語で書かれていることが多いため、対応できるエンジニアが少なくなってきています。そのまま古いシステムを使い続けているとメンテナンスコストが膨らむだけでなく、やがてエンジニアが確保できなくなりメンテナンスそのものが困難になる可能性もあります。マイグレーションをおこない、レガシーシステムから脱却することはエンジニア不足に備えることにもつながります。
マイグレーションは現行システムのソースコードや構成を資産として活用できるため、これまでのノウハウを生かした運用や、従業員の教育コスト削減も可能です。

マイグレーションと混同しがちな用語として、コンバージョン、リプレース、エンハンス、モダナイゼーションの4つがあります。それぞれ解説していきます。

コンバージョン（conversion）は「変換」「転換」という意味であり、IT分野ではデータやファイルの別形式への変換を指します。マイグレーションが環境を移行することを意味するのに対し、コンバージョンは異なる設計思想・形式に転換することを意味しており、結果的に環境が変わる点は同じであるものの意味合いは異なります。

リプレース（replace）は「交換」「置換」という意味であり、古いシステムや容量不足、不具合などが発生したシステムを新しいものに置き換えるようなケースに使われます。
マイグレーションとの比較ではOSやプラットフォームなどの基盤部分までは変更しないのがリプレースと解説されることが多い一方で、「再構築」の意味合いでもう少し広い範囲を指して使われるケースもあります。

エンハンス（enhance）とは「強化」という意味であり、既存システムの拡張や機能追加、性能向上などを指します。マイグレーションとは異なり移行はともないません。

モダナイゼーション（modernization）とは「近代化」「現代化」という意味です。マイグレーションは既存システムの構造には手を加えずに別の環境へ移行させますが、モダナイゼーションは既存システムで蓄積してきたIT資産を活かしながら、システムを新たに設計し最適化を図ります。
おもにレガシーシステムの刷新でよく使われる用語です。

マイグレーションには、おもに次のような種類があります。

サーバマイグレーション（Server Migration）とは、既存のサーバで稼働しているシステムを異なるサーバ環境へ移行することです。オンプレミスからクラウドへ、クラウドサービスから別のクラウドサービスへの移行などがあたります。新しいプラットフォームに移行することで多くの場合はパフォーマンスの向上をもたらします。
現在のサーバで実行しているオペレーションを損なうことなく移行するには、綿密な調査と準備が必要かつ慎重な対応が求められます。
データが増えて容量が不足してきた、サーバが老朽化してきた、保守契約が切れたといった場合によくおこなわれます。

データマイグレーション（Data Migration）とは、異なるシステム間やソフトウェア間、データ形式間でデータを移行することです。移行してもデータの整合性は保持しなくてはなりません。
記憶媒体の入れ替え、アプリケーションの更新・入れ替えなどの場合におこなわれます。
アプリケーションの入れ替えをおこなうときには、同時にデータの統合やクリーンアップをおこなうこともあります。

レガシーマイグレーション（Legacy Migration）とは、老朽化したシステムから新しい設計思想や仕様、製品に基づいた新システムへ移行することです。データマイグレーションとは異なり、機能とデータの両方を移行します。
企業全体に関わる規模の大きな案件となるため多くのコストや長い移行期間がかかりますが、運用コストの削減や新しい技術・ビジネスモデルに対応できるなどさまざまなメリットがあります。ただし、目的と手段を明確にしたうえで最適な方法で取り組まなければ無意味に終わってしまう可能性もあるため、慎重な検討が必要です。
「2025年の崖」問題やDX推進が世界的に叫ばれるようになり、話題にあがることが多くなったワードです。

クイックマイグレーション（Quick Migration）とは、コンピュータ上の仮想マシンを一時停止してから別のコンピュータへ移行することです。アプリケーションの再構成はせず、移行のみを指します。
既存の仮想マシンの状態を保存し、移行先の環境に展開して移行することで移行にかかる時間を大幅に短縮できます。ただし、移行元と移行先の環境が大きく異なる場合には利用できません。
仮想マシン上で動作しているシステムを稼働状態のままいったん停止して移行するので、コールドマイグレーション（Cold Migration）とも呼ばれています。
仮想マシンは一時停止するだけで再開時にシャットダウンや再起動などは不要です。

ライブマイグレーション（Live Migration）とは、クイックマイグレーションと同様に仮想マシンを移行することです。ただし、仮想マシンは停止させずに稼働したまま移行をおこなうのが特徴です。これにより稼働中のサービスを停止させることなく仮想マシンを移行できます。実際にはシステムの瞬断がありますが、アプリケーションやサービスは停止せず、ユーザーにも意識されません。
ユーザーに影響を与えないというメリットがありますが、高度なスキルが必要です。
また、ライブマイグレーションには、ストレージの共有や仮想マシンモニタの対応など、条件がある場合もあります。ホットマイグレーション（Hot Migration）とも呼ばれています。

マイグレーションには、おもに次のような手法があります。

リビルド（rebuild）とは本来「再構築」という意味です。開発工程のビルドをやり直す意味合いと、システムを全面的に新しく作り直し、データを新しい環境に移行する意味合い、２種類あります。マイグレーションの手法としてのリビルドは後者にあたります。
既存のシステムをベースに再設計をおこない、より適切なシステムを構築することで古い環境での課題の多くを解決できる一方で、システム全体の開発となるため多大なコストが発生するやり方でもあります。

リホスト（rehost）とは本来「再集結」という意味です。アプリケーションの言語やプログラムはほとんど変えずに、ハードウェアやOSなどの基盤部分だけを新しいプラットフォームへ移行します。既存のアプリケーションやデータなどの資産を継承でき、移行によるリスクやコストを抑えることができる一方で、根本的な構造や課題の改善ができずに残る側面もあります。
基本的にロジックの変更はおこないませんが、移行先の環境に合わせてある程度の設定や構成の調整、システムやアプリケーションの変化が生じる可能性があります。

リライト（rewrite）とは本来「書き換え」「書き直し」という意味です。開発におけるリライトとは、システムやアプリケーションの枠組みは変えずに、既存の言語から異なる言語に書き換えてつくり直すことを指します。
例えば、COBOLで作成されていたメインフレーム上のシステムをJavaで書き換え、クラウドサーバなどに移行するケースがあげられます。
ソースコードを書き直すためある程度の時間やコストは必要になりますが、古い言語から移行することでパフォーマンスやセキュリティの向上、新しい技術への対応などが期待できます。ただし、アプリケーションの基本設計は既存のシステムのとおりなのである程度の制約があります。

ラッピング（wrapping）とは本来「包装」という意味です。メインフレームには手を加えずに、外部のオープンシステムからもアクセスできるように標準インターフェースを設けるやり方です。業務フローは変えずに新たなアクセス手段を確保することができます。
システムそのものは変わらないため低リスク低コスト短期間で取り組める一方で、既存の構造がそのまま残るためコスト削減などにはつながりにくい手法です。

リファクタリング（refactoring）とは本来「再設計」という意味です。既存のアプリケーションを見直し、開発しやすい構造や設計になるようにコードを書き換え、可読性や保守性、拡張性を向上させることを指します。具体的には重複したコードの削除、変数・関数名の変更、データベース構造の最適化などです。メンテンナスを重ねるうちに複雑になりがちなソースコードを整理することで、属人化やブラックボックス化を回避できます。

SaaS（Software as a Service）とは、クラウドサービス上で提供されるアプリケーションやサービスです。現在では多くの業務システムがSaaSとして提供されています。
SaaS移行には、おもに2つのパターンがあります。
1つはオンプレミス環境で利用していた業務システムをSaaSで提供されているアプリケーションに移行するパターンです。
そしてもう1つは、これまで利用していたSaaSのアプリケーションを別のSaaSアプリケーションに乗り換えるパターンです。新しいサービスに移行することで既存の課題を解決できるケースもあります。
特にオンプレミス環境からSaaSへの移行は影響範囲が大きく、セキュリティ面などの慎重な検討が必要です。
判断に迷う、懸念事項があるような場合は専門家のサポートを受けることをおすすめします。

​​​​​​​​​​​＞＞オンプレミス環境からAWSへのクラウドマイグレーション事例はこちら

マイグレーションを実施する際の手順をご紹介します。あくまで一例であり、移行対象や内容、実施する企業の状況によって実際の手順は変わります。
マイグレーションは対象範囲が大きいほど、より入念な準備が必要になります。移行を検討・実施する際にはきちんとした計画を立てること、計画に沿って段階的に進めていくことが非常に重要です。

なぜマイグレーションをおこなうのか、どのような課題を解決するのかなど、まずはマイグレーションをおこなう目的を整理し、基本的な方針を決定します。
マイグレーションは企業の将来を見据えた計画であり、多くの場合は規模の大きなプロジェクトとなり関係者も多く、プロジェクト完了までの期間も長くなるものです。
全体の方向性を一致させるためにも、最初に方針を策定することが重要になります。

具体的には、主に次の項目を決定します。

• 現状の業務を洗い出して把握し、課題を整理する
• 現状のシステムの構成やデータを調査する
• マイグレーションをおこなう範囲を決定する
• どのような形で実施するか方針を検討する
• 移行先を決定する
• 大まかなスケジュールを決定する
• 必要なタスクを整理する

決定した方針に基づき、計画を立てて移行計画書を作成します。あらかじめ移行計画を立て手順に沿って実施することで、効率よく、抜け漏れなく移行作業を進めることができます。
移行計画書の詳細について順を追って解説していきます。

移行に必要な情報を記載します。具体的には、おもに次の項目です。

• 移行の全体的な方針
• 移行手段
• 移行要件
• 移行する時期
• 移行する範囲
• 移行の前提となる制約条件
• 移行による業務への影響

新しいシステムで何を移行するのか、移行する対象と、対象ごとの移行方法を決めて記載します。
データやネットワークだけでなく、システム運用や業務処理なども移行の対象です。例えば会計システムを移行する場合は、会計システム自体のシステム運用と経費申請処理などを含めた業務処理も移行の対象になります。
移行するシステムやデータを利用する業務には何があるかを洗い出して可視化し、移行対象に抜け漏れがないかこの段階でしっかり確認しておきましょう。
また、移行後の全体を把握できるように「機能一覧」や「サービス全体図」などもあわせて作成します。

移行には「一括移行方式」「段階的移行方式」「並行移行方式」の3つの方法があります。
移行対象ごとに移行方式と、トラブル発生時に備えて旧システムへの切り戻し方法も決定します。

• 一括移行方式：既存のシステムを停止し、一気に新しいシステムへ移行する方式
• 段階的移行方式：業務ごと、機能ごとに少しずつ既存のシステムから新しいシステムに移行する方式
• 並行移行方式：既存のシステムと新しいシステムを併用し、徐々に移行する方式

移行期間中にシステムや業務にどのような影響があるのかを記述します。移行による影響は移行範囲の大きさに比例して大きくなる傾向があります。あわせて、その影響にどう対処すれば良いのかも記述しておきます。例えば、業務に与える影響を小さくするため定時後や休日に移行する、段階的に移行するなど、それぞれ対策を記述しておくと便利です。

移行前には十分なテストが必要になるため、移行テストの方法、実施範囲、実施環境など、詳細を記述します。移行ツールのテストや移行作業のリハーサル、テスト環境・本番環境での各テストなど、実施回数や内容を記述します。

移行完了までの全工程のスケジュールを記述します。全体の大まかなスケジュールと、細分化した細かなスケジュールを明記します。
スケジュールをたてる際は日程に余裕を持たせることが重要です。開発やテスト、不具合修正などで予想外の工数が発生した場合でも、スケジュールに致命的な遅れが出ないようある程度のバッファを持たせるようにしましょう。
他にも、それぞれのタスクの開始条件やタスク間の依存関係を記述しておきます。これらは作業の遅れや前倒しが発生したときに適切に対処するために必要な情報となります。

移行プロジェクトチームの体制と役割分担を利用側、開発側でそれぞれ決定し記述していきます。大きなプロジェクトは関係者も多くなるため、体制図に明記し連絡の抜け漏れなどのリスクを防ぎます。
移行体制では、プロジェクトチーム全体の中に次のような小さなチームを作ることも多くあります。

• 新システムの設計や開発をおこなうチーム
• 移行作業をおこなうチーム
• システム移行後の教育をおこなうチーム

移行計画書が整ったら、計画書にしたがって移行作業をおこないます。
テスト環境でのテストが完了したら、次に本番環境でのテストをおこないます。「リハーサル」と呼ばれる段階です。
リハーサルは複数回おこない、不具合の発見と解決に着手していきます。不具合がなくなったら移行可能の判定を出し、移行作業に入ります。
入念にテストをおこなわないと不具合が残り、移行後に正常に動作しないなどのトラブルにつながる可能性があります。それらを防ぐためにも、繰り返しのテストと不具合の修正が必要です。

移行リハーサルで「移行可能」と判定したら、いよいよ本番環境への移行作業をおこないます。新しいシステムを構築し、現行システムのデータを新しいシステムに移す作業です。移行作業が終了したらシステムの切替えをおこない、移行プロジェクトチームは運用担当者へ管理権限の移管をおこないます。
移行前後でシステムに変化点が生じる場合は、移行計画書に基づいて業務担当者やサポート担当者への教育も実施していく必要があります。

マイグレーションは前述したような複数のメリットが見込める一方で、注意しなければならない点も多く存在します。場合によっては移行後のデメリットのほうが大きくなってしまう可能性もあるため、慎重に確認をおこなう必要があります。
おもに次のような点に注意が必要です。

マイグレーションをおこなう際は、十分に事前調査をおこなってから計画を立てましょう。事前調査では現行システムの使い方や設計、運用方法などを洗い出して可視化し、正しく理解することが必要です。その内容を踏まえて、より適切なシステムを構築することで移行時のリスクを抑えることができます。

前述したように、マイグレーションにはいくつもの移行方式があります。どの方法を選ぶかは現在抱えている課題がどういうものか、どの部分を新しくしなければならないのかで決まります。
また、予算や人員、スキルによっても利用できる方式は異なるので注意が必要です。プロジェクトに関われる人員が少ないのに手間のかかる移行方式を選んでしまう、予算が少ないのにコストのかかる移行方式を選んでしまうようなことがあると、最悪の場合プロジェクトが完了できなくなる恐れもあります。

移行前には、リハーサル（テスト）を十分におこなうことが欠かせません。入念なリハーサルによって、移行前に不具合や問題を発見し対処することができます。
テスト環境での単体テストや結合テスト、より本番に近い環境での複数回テストなど、マイグレーションの範囲に応じて必要なリハーサルを必ずおこないましょう。

マイグレーションをおこなうときは、情報システム部門や管理職、ユーザーである現場の社員など、関係者へしっかり周知しておきます。移行にともない、システムや業務プロセスが大きく変化することもあるため、事前・事後ともに徹底した周知が求められます。

マイグレーションを適切に進めるには必要なスキルやノウハウが多いため、自社だけでは対応が難しいケースも多くあります。特に、会社として重要なシステムであるほど慎重な対応が求められる作業になります。そのような場合にはプロの業者に外注するのもひとつの手段です。

業者選定の際は価格や対応期間などが重要なポイントになりがちですが、マイグレーションの委託においては必要なスキルやノウハウを持っているかどうかが特に重要となります。
多くの場合、ソフトウェア開発領域だけでなくインフラやネットワークの知識、移行後の稼働を見据えた運用設計ノウハウも重要となるため、開発領域とインフラ領域、両方の実績を持っている業者を選ぶことをおすすめします。
自社と同じ業界や規模の企業での対応実績があれば、自社の依頼に必要なスキルやノウハウを持っていると考えるひとつの目安になります。

再委託とは、委託された業者がさらに他の開発会社に委託することです。契約形態にもよりますが、再委託はリソース不足を補う有効な手段である一方で、発注元は再委託先と直接コミュニケーションをとることができません。委託範囲が広がることでプロジェクト管理が煩雑になり、認識のズレが発生するリスクも高まります。
外注先には再委託の有無と、するのであれば過去に委託実績のある会社かを確認しましょう。特に、プロパー社員がリーダーとして機能せずに再委託先に丸投げのような実態となっていないかは注意が必要です。

​​＞＞マイグレーションに関するお悩み・ご相談はこちら

株式会社エヌアイデイで対応したマイグレーションの事例を2つご紹介します。

お客様の親会社のシステム変更にともない、関西地区/福岡地区/沖縄地区の拠点ネットワークで新社内システムの構築と設定変更をおこないました。
4ヵ月というタイトなスケジュールで新システムを構築・稼働し、ネットワークの切替えやユーザー端末の設定変更をおこなう必要があり、AWSマネージドサービスを活用してできるだけ効率的に短期間での再構築とネットワーク切替えを実現しました。さらに、リモート監視サービスをご提供して運用負荷軽減にも貢献しています。

＞＞AWSを活用した社内システムマイグレーション事例の詳細はこちら

お客様のグループ全体でクラウド移行を進めるため、オンプレミス環境で稼働していたActiveDirectoryサーバ、ファイルサーバ、NASサーバデータをクラウドへ移行しました。OSのEOS対応をおこなうため、ドメイン機能のバージョンアップとActiveDirectoryのデータを保持したままでのクラウド移行が必要でしたが、条件を満たしたままシステム全体をAWSに移行し、セキュリティや可用性の向上も実現しました。

＞＞オンプレミス環境からのサーバマイグレーション事例の詳細はこちら

システムを利用している限り、定期的にマイグレーションを検討する場面が出てくると思います。特に最近はシステムの老朽化と新しい技術への対応、さらに業務でのクラウドサービスの利用増加などでマイグレーションの需要は伸びてきています。
マイグレーションは企業にとって重要なプロジェクトです。現行のシステムの課題を解決できるよう新しいシステムを構築し、安全に移行しなくてはなりません。そのためにはシステムの高度な知識やノウハウが欠かせません。
自社だけで対応するにはハードルが高い場合は、必要に応じて経験豊富な専門家のサポートも上手く活用し、効果的なマイグレーションを目指しましょう。

＞＞エヌアイデイの「クラウドソリューション」について詳しくはこちら