マイグレーションとは、「移転」や「移動」などを意味する言葉で、現在利用しているシステムを新しい環境に移行することを意味します。
システムの老朽化に伴う運用・管理コストの削減、セキュリティリスクの軽減、レガシーシステムからの脱却などが主な目的とされ、DX推進や「2025年の崖」対策としても注目されています。
マイグレーションにはいくつかの種類・手法があり、システムの規模や目的によって最適なタイプはそれぞれ異なるため、自社に適した方法で実施することが大切です。
今回は、マイグレーションの概要や種類・手法、実施するメリット、進め方、成功に向けたポイントなどを詳しく解説していきます。
目次
１．マイグレーションとは？
マイグレーション（migration）とは、もともと英単語で「移動」「移住」「移転」といった意味を持つ言葉で、IT分野では既存のシステムやソフトウェア、データなどを新しい環境へ移行することを指します。
例えば、オンプレミス環境からクラウド環境へ移行する、古い開発言語から現代的な開発言語へ移行する、大量のデータを新しいプラットフォームへ移行する、などがマイグレーションにあたります。
部分的な修正やパッチ適用はマイグレーションには当てはまりません。
マイグレーションの対象となるものは、既存システム、サーバー、ストレージなど多岐にわたり、「何を」刷新・移行するかによって、マイグレーションの種類や実施すべきタイミングはそれぞれ異なります。
マイグレーションと混同しやすい用語
リプレイスとの違い
マイグレーションと混同されやすい用語の1つとして「リプレイス（replace）」があります。
リプレイスは、「交換」「置換」といった意味を持つ英単語で、老朽化・故障したり、時代遅れで古くなった既存システムを新しいものに入れ替えることを指します。
リプレイスとマイグレーションの違いは、一言でいえば「別環境に変わるか否か」という点にあります。
リプレイスでは、元の環境を維持したまま、古くなったシステムを新しいシステムに入れ替えますが、マイグレーションでは、既存システムを置き換えることなくそのまま新しい環境へと移行し、必要に応じてOSやプラットフォームなどの基盤部分の変更も行います。
コンバージョンとの違い
リプレイスと同じくマイグレーションと混同されやすい用語の1つに、「コンバージョン（conversion）」があります。
コンバージョンは、「変換」「転換」「転化」という意味を持つ英単語で、データやソース、ファイルを現在の形式から別の形式へと変換することを指します。
例えば、ソース変換ツール等を使って、COBOLなどの古いプログラミング言語から、Javaなどの新しい言語へ機械的に変換する作業などが該当します。
両者とも、「これまで使っていたシステムやソフトウェアはそのまま」という点は共通していますが、マイグレーションは「新しい環境やバージョンへの移行」を、コンバージョンは「異なるデータ形式・ファイル形式への転換」を示しているという違いがあります。
エンハンスとの違い
「エンハンス（enhance）」とは、英語で「強化する」「高める」という意味を持ち、既存システムの機能を追加・拡張したり、性能を向上させたりすることを指します。
既存システムに手を加え、今よりもスペックの高いシステムへと進化させるという点でマイグレーションとは異なります。
モダナイゼーションとの違い
「モダナイゼーション（modernization）」とは、「現代化」「近代化」といった意味を持つ英単語です。
古い技術や仕組みによって構築されている従来のシステム（＝レガシーシステム）について、最新技術を取り入れながら、現在のニーズやビジネス環境に合わせて最適化することを指します。
違いとしては、マイグレーションは単に既存システムを別の環境へ移行することを指しますが、モダナイゼーションは時代に乗り遅れているレガシーシステムを刷新し、システム全体の最適化を図ることを意味しています。
さらに、モダナイゼーションの対象となるのは基本的に「レガシーシステム」のみですが、マイグレーションの場合、レガシーシステムかどうかは問わず、「自社で現在使用しているシステム」が対象に含まれます。
２．マイグレーションの目的
マイグレーションを行う目的としては、次の5つが挙げられます。
- 「2025年の崖」に対する対策
- ランニングコストの削減
- セキュリティ向上や故障リスクの回避
- ブラックボックス化の防止
- 成長戦略の一環
「2025年の崖」に対する対策
経済産業省が2018年9月に発表した「DXレポート」によると、このままレガシーシステムの刷新が行われなかった場合、企業はDXの波に乗り遅れて競争力を失い、2025年以降に年間で最大12兆円の経済損失が生じる可能性があると指摘されています。
つまり、レガシーシステムの存在が「2025年の崖」問題発生の大きな要因となっており、マイグレーションはレガシーシステムから脱却する手段の1つとして注目されています。
ランニングコストの削減
DXレポートでは、レガシーシステムを今後も運用し続けることで、将来的に企業IT予算の9割以上をメンテナンス費に割かなければならなくなると提言しています。
レガシーシステムは、COBOLなどの最近ではあまり使われなくなった言語で構成されていることが多いため、このまま使い続けていると、メンテナンス費がどんどん膨らむだけではなく、古い言語に精通したエンジニアを確保できず、メンテナンスそのものが困難になる可能性もあります。
マイグレーションにより、レガシーシステムを新しいシステムに移行することで、運用・管理コストの大幅な削減が期待できるほか、既存システムのソースコードや構成、データ等を資産として有効活用できるため、これまでのノウハウを生かした運用や、従業員の教育コスト軽減につなげられます。
セキュリティ向上や故障リスクの回避
システムやハードウェア、ソフトウェアには、それぞれメーカーが定めるサポート期間があり、期間を過ぎると故障時のサポートを受けられなくなってしまいます。
また、サポートが終了したソフトウェアは、セキュリティ上の問題が見つかってもアップデートが提供されないため、情報漏えいやデータ損失のリスクが高まります。
そのような事態に陥らないためにも、サポート切れのタイミングをあらかじめ把握しておき、計画的にマイグレーションを行うことが求められます。
ブラックボックス化の防止
レガシーシステムは、度重なるアップデートや独自カスタマイズの繰り返しで、全容を把握できないほど複雑化・肥大化しているケースが少なくありません。
特に、レガシーシステムの運用・保守業務が属人化している場合、担当エンジニアが退職してしまえば、どんな機能がどういった意図で実装されているのか誰も正確に把握しておらず、容易に手が出せなくなってしまう状態に陥るおそれがあります。
こうしたレガシーシステムの「ブラックボックス化」を防ぐためにも、マイグレーションは必要といえます。
成長戦略の一環
近年は特に、ビジネス環境や顧客ニーズの変化が非常に激しい時代です。
レガシーシステムの多くは、AIやIoT、クラウド、ビッグデータなどの最新技術に対応しておらず、それにより競合他社との市場競争に敗れ、撤退を余儀なくされるといったリスクがあります。
マイグレーションによりレガシーシステムの刷新を行い、最新の技術やトレンドを取り入れられるようになれば、目まぐるしく移り変わっていく外部環境や顧客ニーズへ柔軟に対応し、企業の競争力強化につなげることができます。
３．マイグレーションの種類
マイグレーションの種類としては、次の6つが挙げられます。
- レガシーマイグレーション
- データマイグレーション
- サーバーマイグレーション
- ライブマイグレーション
- クイックマイグレーション
- クラウドマイグレーション
レガシーマイグレーション
レガシーマイグレーションとは、老朽化・複雑化・ブラックボックス化したレガシーシステムを、新しいシステムに移行・刷新することです。
昨今、「2025年の崖」問題やDX推進が叫ばれるようになり、重要視されるようになったキーワードです。
企業全体に関わる規模の大きな案件となるため、多くのコストや長い移行期間がかかりますが、運用コストの削減や新しい技術・ビジネスモデルに対応できるなどさまざまなメリットがあります。
ただし、目的を明確にしたうえで、自社にとって最適な方法で取り組まなければ無意味に終わってしまう可能性もあるため、慎重な検討が必要です。
データマイグレーション
データマイグレーション（DBマイグレーション）とは、既存の環境から新しい環境へとデータやデータベースを移行することで、いわゆる「データの引越し作業」のことです。
既存システムをオンプレミスからクラウドへ移行する際や、ハードウェアが老朽化してリプレイスが必要になった際などに、データマイグレーションによりデータを移行します。
使用するソフトウェアやデータ形式が変わらない場合は、ファイルの複製や移動だけで済むケースもありますが、多くの場合は既存データを新しい環境に適した形式に変換し、データの整合性を保持する必要があります。
サーバーマイグレーション
サーバーマイグレーションとは、既存のサーバーで稼働しているシステムを異なるサーバー環境へ移行することです。
例えば、オンプレミス環境からクラウド環境へ、クラウド環境から別のクラウド環境へサーバーを移行する場合が当てはまります。
既存サーバーが老朽化してきた、データが増えて容量が不足してきた、サーバーの保守契約期限が迫っている場合などによく実施されます。
ライブマイグレーション
ライブマイグレーションとは、別名「ホットマイグレーション」とも呼ばれ、あるコンピューター上で動作中の仮想マシン（VM）を停止させずに稼働したまま他のコンピューター上に移行することです。
仮想マシン（VM）を停止させずに移行が可能なため、稼働中のサービスやアプリケーションを停止させることなく、システムのメンテナンスや機器の入れ替え、構成の変更などを行うことができます。
厳密には、切り替えのタイミングで一瞬だけネットワークが遮断される「瞬断」が発生しますが、移行に伴うサービスの中断が生じることはなく、ユーザーへの影響はほぼありません。
クイックマイグレーション
クイックマイグレーションとは、別名「コールドマイグレーション」とも呼ばれ、あるコンピューター上で動作中の仮想マシン（VM）を一時的に停止した状態で他のコンピューター上に移行することです。
移行後もOSのシャットダウンや再起動などは行われず、ソフトウェアの実行状態はそのまま引き継がれます。
ただし、移行元と移行先の環境が大きく異なる場合には利用できません。
クラウドマイグレーション
クラウドマイグレーションとは、オンプレミスで運用している既存システムを、AWSやMicrosoft Azureなどのクラウド基盤に移行することです。
DX推進やリモートワークの普及に伴い、近年実施する企業が増えてきており、自社に合った適切なクラウドサービスを選択すれば、運用・保守コストの削減や業務効率化、データアクセスの柔軟性向上、BCP対策、セキュリティ強化といった効果が期待できます。
４．マイグレーションの手法
マイグレーションの手法としては、次の6つが挙げられます。
- リホスト：インフラ刷新
- リライト：プログラム言語の変更
- リビルド：システムの再構築
- リファクタリング：再設計
- ラッピング
- SaaS移行
リホスト：インフラ刷新
リホストとは、使用している言語やアプリケーションの仕様は変更せずに、ハードウェアやOSなどの基盤部分のみを新しいプラットフォームへ移行する方法です。
ソフトウェアの中身を変えず、ハードウェアやOSのみを移行するため、既存のアプリケーションやデータをそのまま継承できるうえ、短期間・低コスト・低リスクで移行を実現できる点がメリットです。
一方で、既存プログラムやアプリケーションに含まれていた問題もそのまま引き継いでしまうため、アプリケーションが抱える根本的な課題の改善にはつながらないというデメリットがあります。
既存システムで使える機能やセキュリティ面で特に問題がない場合に適しており、オンプレミスからクラウドへの移行によく利用されます。
リライト：プログラム言語の変更
リライトとは、アプリケーションの仕様はそのままに、プログラムを別の言語に書き換えたうえで、新しいプラットフォームへと移行する方法です。
例えば、COBOLなどの古いプログラミング言語から、Javaなどのよりモダンで拡張性のある言語へとソースコードを書き直すケースなどが当てはまります。
古い言語を書き換えることで、システムのパフォーマンスやセキュリティが向上し、新しい技術にも対応できるようになる点がメリットです。
一方で、プログラムの書き換えに時間と労力がかかる、リホストと同じく既存システムが抱える問題を根本的に解決しづらい、といったデメリットがあります。
リビルド：システムの再構築
リビルドとは、既存システムを全面的に新しく作り直し、データのみを新しい環境に移行する方法です。スクラッチ開発などが当てはまります。
リホストやリライトといった他の手法とは異なり、既存システムを流用することはないため、既存システムの課題を抜本的に解決可能な点がメリットといえます。
ただし、既存システムをベースとして一から新しくシステムを再構築するため、多大なコストと時間がかかるというデメリットがあります。
既存システムの老朽化・複雑化・ブラックボックス化が進み、大きく見直しを図りたい場合におすすめです。
リファクタリング：再設計
リファクタリングとは、既存アプリケーションの内部構造を整理し、メンテナンスしやすい構造・設計となるようコードを書き換え、可読性や保守性、拡張性を向上させる方法のことです。
具体的には、重複したコードの削除、変数・関数名の変更、データベース構造の最適化などがあります。
システムは長く利用していると、メンテナンスのたびにコードが複雑化しがちですが、リファクタリングによって整理されることで、特定のエンジニアしかメンテナンスを行えない属人化やブラックボックス化の状況を回避できるというメリットがあります。
また、コードの可読性や保守性が高まることで、トラブル発生時の原因も突き止めやすくなるため、システム運用の安定化にもつながります。
ラッピング
ラッピングとは、既存システムのメインフレーム（＝基幹システムなどに用いられる大型コンピューターのこと）には手を加えずに、外部のシステムからアクセスできるようなインターフェースを用意し、アクセス手段を増やす手法です。
システムの基本的な部分や業務フローを変更せずに、少ない工数で新たなアクセス手段を追加できるのがメリットですが、リホストやリライトと同様、既存システムの欠点やリスクをそのまま引き継ぐため、システムが抱える問題の根本的な改善が難しいというデメリットがあります。
SaaS移行
SaaS（Software as a Service）とは、インターネット経由でソフトウェアやアプリケーションを提供するクラウド型サービスのことです。
現在では多くの業務システムがSaaSとして提供されています。
SaaS移行には、主に次の2つのパターンがあります。
【オンプレミス→クラウドへの移行】
オンプレミス環境で利用していた業務システムを、SaaSで提供されているアプリケーションに移行するパターン
【クラウド→他のクラウドへの移行】
これまで利用していたSaaSのアプリケーションから、別のSaaSアプリケーションに乗り換えるパターン
どちらのパターンであっても、新しいクラウドサービスに移行することで、既存の課題を解決できる可能性があります。
特に、オンプレミス環境からSaaSへ移行する場合は影響範囲が大きくなるため、セキュリティ面などの慎重な比較検討が必要です。
５．マイグレーションを行うメリット
マイグレーションを実施するメリットとしては、次の5つが挙げられます。
- 生産性の向上
- セキュリティの向上
- コスト削減
- 既存システムの有効活用
- 新しい技術の導入が容易
生産性の向上
マイグレーションを通じたレガシーシステムからの脱却により、既存システムが抱えるリスクや課題を解決できるほか、業務効率化につながる新機能の導入も可能となり、利便性の向上や生産性の向上が期待できます。
例えば、既存システムで動作の遅さを感じている場合、新しい環境に移行することでパフォーマンスが向上し、業務時間の短縮や生産性アップにつなげられます。
さらに、クラウドサービスやデータセンターなどを活用すれば、運用・管理にかかる手間も削減され、より生産性の高い業務に集中できます。
セキュリティの向上
マイグレーションにより新しい環境に移行することで、古いシステムが有していた脆弱性を取り除いたり、最新のセキュリティ機能を活用できるようになり、セキュリティ面の強化につながります。
例えば、既存システムの老朽化を放置していると、サーバーやストレージの故障や劣化によって大切な業務データが失われてしまう恐れがあります。
また、ソフトウェアなどのサポートが終了しているのに古いシステムを使い続けていると、脆弱性が残り続けてしまうため、セキュリティリスクも高まります。
マイグレーションを行うことで、システムのセキュリティ対策が改善され、情報漏えいやデータ損失などのさまざまな脅威・リスクから、会社や顧客の情報を守ることにつながります。
コスト削減
マイグレーションにより、システムの運用やメンテナンスにかかるコストを大幅に削減できるようになる点も大きなメリットです。
エンジニア不足やシステムの老朽化・複雑化もあって、レガシーシステムの運用・保守には多額のコストがかかります。
さらに、レガシーシステムの運用・保守に資金や人材が割かれることで、新たなデジタル技術を用いてビジネスモデルの変革を目指す「攻めのIT投資」にリソースを振り向けることが困難になります。
その点、マイグレーションでJavaやPython、PHPなどの学習しやすいオープン系開発言語に移行することで、古くなったシステムの運用・保守の負担を軽減し、コスト削減につなげられます。
ほかにも、一から新たにシステムを構築するよりも、マイグレーションで既存システムのソースコードなどを流用する方が、開発コストを抑えやすいというメリットもあります。
既存システムの有効活用
マイグレーションは、既存システムのソースコードや構成、データを有効活用できることから、まったく新しいシステムを一から開発するよりも、「これまで培ってきたノウハウや使い慣れたインターフェースを活かせる」という点で優れています。
今まで使っていたシステムを踏襲する分、「従業員の学習コストを軽減し、移行後もスムーズにシステムを活用できる」「移行に伴う業務への影響を最小限に抑えやすい」といったメリットが得られます。
「システムやデータだけ」を新しい環境に移行することで、既存システムの潜在的な価値を最大限に引き出すことが可能です。
新しい技術の導入が容易
マイグレーションを実施し、自社独自のクローズドなシステムから、オープン系のシステムへと移行することで、クラウド・AI・モバイル・IoTなどの新しい技術の導入も容易になります。
オンプレミスを前提にしたシステム設計では、最新技術の即時導入が難しい面もありますが、クラウドへの移行によって、市場の動きに合わせたより柔軟な対応が可能になります。
６．マイグレーションの課題
マイグレーションの課題としては、次の3つが挙げられます。
- 開発に携わった人が残っていない
- ドキュメントが整備されていない
- テストに膨大な手間やコストがかかる
開発に携わった人が残っていない
1つ目の課題は、「既存システムの開発に携わった人が異動・退職等によりすでにいない」ことです。
既存システムをマイグレーションする場合、既存システムの仕様を十分に理解する必要があります。
しかし、マイグレーションの対象となるシステムが、10～20年以上の長い年月を経ていることも珍しくありません。
長い年月が経った既存システムの開発経緯を確認しようにも、システム開発に関わった当時の社員やエンジニアがすでに退職し、話を聞けない状態となっている可能性があります。
このため、マイグレーションを行うには、既存システムのプログラム解析のほか、システムに存在する機能がどのような業務で使用されているのかなど、ビジネス知識も持ち合わせたエンジニアの存在がカギとなります。
ドキュメントが整備されていない
2つ目の課題は、「仕様書・設計書などのドキュメントが整備されていない」ことです。
マイグレーションを行うとなると、既存システムの機能を隅々まで把握する必要がありますが、レガシーシステムの場合、設計書をはじめとしたドキュメントが存在しないことも珍しくありません。
仮にドキュメントが存在していたとしても、機能の追加・改修時にドキュメントの更新を怠ったために、ドキュメントに記載されている内容と実際に動作している機能の内容がかけ離れてしまっているケースもあります。
このように、ドキュメントが残っていない、あるいは整備されていない状態だと、既存システムの調査・分析に時間を要することになり、マイグレーションへの着手にも遅れが生じてしまいます。
テストに膨大な手間やコストがかかる
3つ目の課題は、「マイグレーション時に実施するテストに膨大なコストがかかる」ことです。
既存システムのマイグレーションを行う際は、多くの場合「既存システムの機能が新環境でもすべて引き継がれている」ことを前提にします。
この時実施するテストが、移行前と移行後でシステムが同じ処理結果になるかどうかを確認する「現新比較テスト」です。
そして、マイグレーションにおける「現新比較テスト」の対象範囲は「全機能」となるため、テスト項目は膨大な数にのぼり、テストに要する手間やコストも侮れません。
７．マイグレーションの流れ
マイグレーションを実施する際の大まかな流れは次の通りです。
- 現行システムの仕様と課題の把握
- 移行範囲・種類・移行先の検討
- 移行計画の策定
- 移行計画書の作成
- 移行リハーサル
- 本番移行
現行システムの仕様と課題の把握
まずは、既存システムの仕様と現状の業務課題を把握するところからはじめましょう。
既存システムの構成や扱っているデータの内容、業務フローなどを整理し、「既存システムで何が課題となっているのか」「それにより、現場でどのような問題が生じているのか」を正確に把握していきます。
そのうえで、「なぜマイグレーションを行うのか」「マイグレーションを経て何を実現したいのか」という目的を明確にし、基本的な方針を決定しましょう。
企業が抱えている現状の課題やマイグレーションの目的によって、このあと決めるマイグレーションの種類や移行範囲が変わってきます。
移行範囲・種類・移行先の検討
次に、既存システムの仕様と自社の課題を踏まえて、「どのようなシステムやデータ」を「どんな方法で」「どこに移行するのか」、マイグレーションの移行範囲・種類・移行先を検討します。
移行範囲については、既存システムの状態や業務内容をもとに、移行するもの・しないものを選別します。
マイグレーション方法については、移行対象や範囲によってさまざま種類があるため、自社の目的や課題に合わせて最適な手段を選択することが大切です。
移行先については、そもそも移行可能かどうか、移行元と移行先の環境で互換性があるかどうかなどの確認が必要となります。
なお、データマイグレーションを行う場合には、あらかじめ不要データを削除するなどして既存データを整理しておき、円滑に移行できる体制を整えておきます。
移行計画の策定
マイグレーションの方向性が定まったら、それを具体的に実行するための移行計画・移行手順を策定していきましょう。
マイグレーション全体で実施すべきタスクを整理して、必要なリソースと工数を洗い出し、移行計画に落とし込みます。
移行する手段や期間、本番当日の流れなどのほか、データのバックアップなど各現場で必要な作業も計画に含めましょう。
なお、移行本番までの間に何らかのトラブルが発生することもあるため、余裕を持ったスケジュールを組むことも重要です。
予算・人員の制約や、不測の事態が発生するリスクなども考慮し、「一括ではなく段階的に移行する」「移行する範囲を限定する」など、無理のないゆとりを持った計画を立てるようにしましょう。
既存システムのサポート終了に伴うマイグレーションの場合は、サポート期限までにマイグレーション作業をすべて完了できるよう、逆算してスケジュールを策定します。
移行計画書の作成
移行計画書を丁寧に作成することで、効率的に抜け漏れなくマイグレーション作業を進めることができます。
計画書には次のような内容を記載します。
【移行概要】
- 移行の全体的な方針
- 移行手段
- 移行要件
- 移行する時期
- 移行する範囲
- 移行の前提となる制約条件
- 移行による業務への影響
【移行対象】
- 移行する対象
- 対象ごとの移行方法
【移行方式】
下記3つの方式のうちいずれか
- 一括移行方式：既存システムを停止し、一気に新しいシステムへ移行する方式
- 段階的移行方式： 業務ごと・機能ごとに、少しずつ既存システムから新しいシステムに移行する方式
- 並行移行方式：既存システムと新しいシステムを併用しながら、徐々に移行する方式
【移行による影響】
- 移行期間中に他システムや業務へ与える影響
- その影響への対処法
【移行テスト計画】
- テスト方法
- テストの実施範囲
- テストの実施環境
↓下記のテスト実施回数や内容も記載
- 移行ツール
- 移行作業のリハーサル
- テスト環境
- 本番環境
【移行スケジュール】
- 全工程のスケジュール
- 細分化したスケジュール
【プロジェクト体制】
- 新システムの設計・開発担当
- 移行作業担当
- システム移行後の教育担当
移行リハーサル
移行計画書が完成したら、計画書にしたがって移行作業を開始していきます。
まずは、テスト環境を構築して、本番と同じ条件で「移行テスト」を実施します。
テスト環境で問題がなかった場合は、本番と同じ条件の作業を本番環境で行う「移行リハーサル」を実施し、不具合や課題を洗い出します。
課題や不安要素が解消されるまで複数回リハーサルを繰り返し、
- 移行テストと移行リハーサルが同じ結果になるか
- システムに不具合は残っていないか
- 移行前のシステムにあった機能が移行後も問題なく使えるか
- 移行したデータに問題がないか
などを検証していきます。
また、リハーサルをしながら各工程の所要時間も調べて、移行当日のタイムスケジュールを確定し、本番当日に予定通り移行作業を進めるための準備を整えましょう。
本番移行
移行リハーサルで問題がないと確認できたら、いよいよ本番環境でマイグレーション作業を実施します。
リハーサルの際に決定したタイムスケジュールに従い、遅れがないように移行作業を進めましょう。
移行完了後は新システムへの切り替えを行い、場合によっては運用担当者への引き継ぎ・フォローも実施します。
なお、通常業務に影響が出ないよう、本番の移行作業は業務時間外に実施するのが一般的ですが、作業の影響が既存システムにまで及ぶ可能性のある場合は、移行スケジュールやシステムの停止時間、業務への影響などを事前に関係者へ連絡しておきましょう。
８．マイグレーションのポイント
マイグレーションを成功させるために押さえておきたいポイントを7つご紹介します。
- 現状の課題・現行システムを正確に把握する
- 自社に適した方法で進める
- 関係者への周知を徹底する
- ハードウェアのリース更新時期に行う
- 本番当日の作業を減らす
- 旧環境をしばらく残す
- 重要なシステムは外注も検討する
現状の課題・既存システムを正確に把握する
マイグレーションの成功には、業務の現状と課題の「見える化」、既存システムの正確な理解が必要不可欠です。
既存システムを詳しく調査し、システムの使い方や設計、運用方法などを洗い出して可視化することで、何が課題なのか、どこに問題があるかが見えてきます。
課題や問題点の洗い出しをする際は、システム・アプリケーションやデータ、ファイルなどを細かくチェックすることが大切です。
さらに、自社業務を滞らせている問題点を正確に把握できれば、どのシステムのマイグレーションが必要なのか、どのような方法でマイグレーションを行うべきかが明確になります。
丁寧な事前調査が、移行漏れや移行失敗のリスクを軽減することにつながります。
自社に適した方法で進める
マイグレーションには、「リホスト（インフラ刷新）」「リライト（プログラム言語の変更）」「リビルド（システムの再構築）」「リファクタリング（再設計）」などさまざまな進め方がありますが、目的に合わせて自社に適した手法を選ぶことが重要です。
例えば、プロジェクトに関われる人員が少ないのに手間のかかる移行方式を選んでしまったり、予算に余裕がないのにコストのかかる移行方式を選んでしまったりすると、最悪の場合プロジェクトが頓挫してしまう恐れがあります。
既存システムの規模や移行する範囲、実施する目的、予算や人員などのリソースの制約も考慮しながら、適切なマイグレーション方法を選択しましょう。
関係者への周知を徹底する
マイグレーションの実施においては、現場社員や管理職など、システムを利用する関係者全員への事前周知が欠かせません。
また、移行に伴いシステムの使い方や業務プロセスが大きく変化することもあるため、システム利用者への研修・教育など、移行後のサポートも入念に行う必要があります。
ハードウェアのリース更新時期に行う
リホスト（インフラ刷新）やリビルド（システムの再構築）の場合、マイグレーションを実施するタイミングとして、ハードウェアのリース更新時期が1つの目安になります。
更新時期と同時にマイグレーションを実施すれば、同時に機器の入れ替えも可能であり、データ移行などの作業も一度で済ませられるため、現場への負担を軽減できるというメリットもあります。
リースの更新時期から逆算して、余裕を持った計画を立てると良いでしょう。
本番当日の作業を減らす
当日の作業が最小限になるように、事前にできることは前もって進めておきましょう。
例えば、更新が確実にないデータは先に移行を済ませておいて、本番当日は前日まで変わる可能性の高いデータのみを移行するよう、移行対象となるデータ量を減らしておくことなどが挙げられます。
本番当日の作業工数をあらかじめ最低限に減らしておくことで、万が一トラブルが発生した場合でも余裕を持って対応できるほか、システムの停止時間も短くて済むため、機会損失の防止にもつながります。
旧環境をしばらく残す
新環境への移行がスムーズに進まない場合も想定して、しばらくは旧環境を残しておきましょう。
そうすることで、万が一移行中にトラブルが発生した際には作業を中止し、旧環境に戻して業務を継続することができます。
さらに、旧環境を残すことは、移行後にトラブルが発生した場合への備えにもなります。
新環境での運用中にトラブルが発生しても、旧環境に切り戻しを行うことで、業務停止のリスクを回避できます。
重要なシステムは外注も検討する
マイグレーションを安全かつ確実に進めるには、専門的な知識・スキルが必須となるため、自社だけでは対応が難しいケースも多くあります。
特に、会社として重要なシステムであればあるほど慎重な対応が求められることから、自社でマイグレーションを実施するのが困難な場合には、必要に応じて外注も検討してみましょう。
専門家の手を借りてマイグレーションを行うことにより、トラブル発生リスクの軽減や作業の迅速化・効率化につながります。
なお、マイグレーションの外注先を選定する際は、価格や対応期間だけでなく、十分な技術力や専門性、実績を持ち合わせているかどうかを見極めることが重要なポイントです。
自社と同じ業界・規模の企業における対応実績があれば、その業者が必要なスキルやノウハウを有していると判断できる1つの目安になります。
９．当社コンピュータマネジメントのマイグレーション事例
最後に、株式会社コンピュータマネジメントで対応したマイグレーションの事例をご紹介します。
メガネレンズ受発注システムのマイグレーション
課題・背景
お客様の既存システムについて、もうすぐ保守契約の満了時期が迫っており、今後ハードウェアの老朽化や、OS・ミドルウェア・ソフトウェアのサポート期限切れによるセキュリティリスク等が心配されたため、早急なEOL対応が必要でした。
実施目的
- 新しいOS、ミドルウェアのシステム環境を構築し、適合させることで、製品不具合やセキュリティ問題への迅速な対応を目指す。
- ライセンス料が安価なミドルウェアでシステム環境を構築することで、毎月の維持費を節約する。
ご支援内容（期間：約1年3ヶ月）
システム移行分野において実績のあるS社と共同で、現行機能に変更は加えず、新環境へのマイグレーションのみを実施しました。
- システム移行方針策定フェーズ（4ヶ月）
┗移行の前提となる制約条件（移行対象・ミドルウェア・テスト方法・スケジュール等）の洗い出し
┗移行の全体的な方針・方式の策定
- 資産移行フェーズ（5ヶ月）
┗データ移行設計
┗データ移行ツール作成
┗S社へのサポート作業（既存プログラムの説明、QA対応、技術サポート等）
- テストフェーズ（6ヶ月）
┗総合テスト、システム運用テストの実施
┗ユーザーテスト支援
┗本番移行
１０．まとめ
いかがでしたでしょうか？
マイグレーションは、ゼロから新しいシステムを構築するのではなく、既存のシステムやデータなど新しい環境に移行することです。
そのため、新しいシステムを完全に一から構築する場合と比べてコストを抑えることができ、これまでのノウハウを活かすことも可能です。
ただし、既存システムの規模や移行する範囲、実施する目的などによって移行方法は異なるため、十分に事前調査を行ってから無理のない計画を立て、自社に合うやり方でマイグレーションを実施することが大切です。
必要に応じて経験豊富な専門家のサポートも上手く活用しながら、マイグレーションを効果的・戦略的に実施しましょう。
なお、当社コンピュータマネジメントでは、「情報システム部門の業務効率化に向けて、専門家の視点から具体的なアドバイスが欲しい」と感じている企業様向けに、情シス支援サービス「ION」を行っております。
以下リンクより情シス支援サービス「ION」に関する資料を無料でダウンロードすることができますので、興味のある方はぜひチェックしてみてください。
お電話・FAXでのお問い合わせはこちら
03-5828-7501
03-5830-2910
【受付時間】平日 9:00~18:00
フォームでのお問い合わせはこちら
この記事を書いた人
Y.M（マーケティング室）
2020年に株式会社コンピュータマネジメントに新卒入社。
CPサイトのリニューアルに携わりつつ、会社としては初のブログを創設した。
現在は「情シス支援」をテーマに、月3本ペースでブログ更新を継続中。
