レガシーシステムの移行手順と成功のためのポイントを解説
2024.12.24（火）
- Webシステム
システム移行はOS・ハードウェアのEOL※のタイミングや、サービス・システム切り替えの場合に実施します。
しかし、現状は多くの企業で「レガシーシステム」と呼ばれる旧来の技術で構築されたシステムを利用し続けている状況です。レガシーシステムの利用を続けると、セキュリティやパフォーマンスなど、業務運営に多くの負の影響が生じます。
当記事で解説するシステム移行のメリットや具体的な手順を踏まえて、レガシーシステムの移行計画の参考としてください。
企業におけるシステム移行の現状
IPA（独立行政法人 情報処理推進機構）の調査によると、2023年時点で少なくとも60%以上の企業でレガシーシステムが使われ続けています。業種別に見ると機密性の高いデータを扱う金融、保険業は90%以上、レガシーシステムを保有しています。
また、企業がレガシーシステムから移行できない原因として、以下のような課題が上位に挙がっています。
- 他の案件に手一杯で十分な要員を割けない
- ユーザーの既存システムの操作性へのこだわりを解消できない
- ブラックボックス化によりレガシーシステムの解析が困難
そのほか、人材やスキル、稼働時間の不足により、システム移行を進められていない企業が多く存在しています。自社の課題と重なる担当者の方も多いのではないでしょうか。
これらの原因を解消できなければ、レガシーシステムからの移行は難しいままです。
結果として、後述するレガシーシステムを利用し続けるリスクを抱え続けることとなります。
https://www.ipa.go.jp/disc/committee/begoj90000002xuk-att/legacy-system-modernization-comittee-20240912-survey.pdf
レガシーシステムを利用し続けるリスクと移行のタイミング
レガシーシステムを利用し続けると、さまざまなリスクが生じます。
システムの運用開始から時間が経つにつれ、負の影響にも目を向けなければなりません。
この章では、レガシーシステムのリスクと移行を検討するタイミングについて解説します。
サポート終了によるシステム老朽化
レガシーシステムのハードウェア、OS・ミドルウェアのサポート終了が近づいたらシステム移行を検討しましょう。
通常、ハードウェアは5年前後でEOLを迎え、オンプレミス環境で運用している場合は定期的な交換が必要です。ハードウェアが故障した場合やEOLを迎えると、修理のためのパーツ交換が難しくなります。
その後も運用を続けると、システム停止や修理、復旧に莫大な費用がかかり、最悪の場合はビジネスの継続が困難になるリスクもあります。
EOLが迫った段階でシステム移行を検討しなければなりません。
また、OSやミドルウェアがEOS（End of Support＝サポートの終了）を迎えた場合も、障害発生時にベンダーからのサポートを受けられずトラブル時の復旧対応が困難となります。結果として、業務に重大な影響を及ぼすリスクが高まってしまいます。
EOSの時期が発表されたら、新しいバージョンのOS・ミドルウェアへの移行を検討しましょう。
業務ニーズへの対応力不足
レガシーシステムを運用し続けることは結果的に競争力の低下につながり、企業の成長を阻害してしまうリスクを抱えます。
技術革新が進む昨今、ビジネスにおける増収・増益には顧客のニーズやトレンドに応じた柔軟な対応が必要です。しかし、レガシーシステムでは柔軟性を高めにくく、変化する業務ニーズへ迅速に対応できない可能性が高まります。
システムパフォーマンスの低下
レガシーシステムのパフォーマンスは経年とともに低下し、システム全体の効率が悪化するリスクを抱えています。パフォーマンス低下を回避するためには、定期的なハードウェアの更新や、最新OSやミドルウェアへの移行が重要です。
今、故障をしていなくても、年数が経過するにつれて処理速度や耐障害性、電力効率など性能の低下が見込まれます。
同じシステム構成でも、基盤となるハードウェアやOS、ミドルウェアが新しくなるだけでシステム全体のパフォーマンス向上が期待でき、安定性の確保につながります。
運用コストの増大
レガシーシステムの運用は、新システムに移行した場合と比較して、システムの維持管理で以下のようなオーバーヘッドが発生することがあります。
現状のシステムの運用コストを把握したうえで、新システムへの移行を検討しましょう。
- ハードウェアの故障リスクが高まり、修理やパーツ交換の費用が発生する
- 旧式のハードウェアの場合は電力効率が悪く、電気代が高くなる
- セキュリティが脆弱な場合が多く、カバーするセキュリティ対策ツールの導入が必要
- ベンダーとの延長サポートを契約する場合の追加費用がかかる
- システムに精通した人材を確保する人的コストの増加
上記のコストが発生することにより、企業の経営効率に直接的な影響を与えるおそれもあります。
他システムとの連携が困難
プロトコルやインタフェースが十分ではないレガシーシステムを使い続けると、最新のシステムとのデータ連携が技術的に困難になり、日常の業務やサービス提供に影響が出る可能性があるため、早急な移行が必要です。
昨今のシステム環境は異なるシステム間でデータ連携ができる構成のものが多く、業務効率をアップできるものが多く存在しています。
レガシーシステムと他システムを連携せずにそれぞれ運用し続けた場合、業務データの一貫性・整合性が失われるほか、社内の意思決定の妨げになったり、作業効率を大きく下げてしまったりする可能性が高まります。
セキュリティリスクの増大
サイバー攻撃が高度化する現代では、レガシーシステムの古いハードウェアやソフトウェアはセキュリティ面の脆弱性となり得るので、新システムへの移行を検討しましょう。
脆弱性を抱えた状態での運用は攻撃を受けた場合に、金銭的な損失やブランドイメージの毀損につながるなど、企業にとって大きなリスクとなります。
例として、新しい暗号化アルゴリズムに対応できないレガシー環境では、通信規格が古く脆弱性があるプロトコルを利用せざるを得ません。データ暗号化や保護が不十分なため、攻撃を受けた際に簡単にデータなどを第三者に読み取られてしまいます。
脆弱性が生じる状況では、個人情報保護法やGDPRなどの各種規制への準拠が困難になるなど、コンプライアンス上のリスクも生じやすくなります。
将来的な企業成長の妨げになる
レガシーシステムを使い続けることは、将来的に企業規模の拡大の妨げになり得ます。
また、レガシーシステムに関する人材の確保やマニュアル化にも手間がかかってしまうため、できれば新システムへの移行を早急に検討したほうがよいでしょう。
レガシーシステムの拡張性の低さ・物理的移転の難しさがネックとなり、企業規模拡大に向けて新たに人材追加やオフィスの移転を考えた場合に対応できないケースがあります。
現時点では、レガシーシステムに精通している人材がいても、定年退職や転職など将来的な退職は避けられません。将来、精通している人材がいなくなればレガシーシステムが運用できなくなり、業務遂行が難しくなります。
システム移行の方式
システム移行にはいくつかの方式（パターン）があります。
レガシーシステム／新システムの構成はもちろんのこと、システムを利用している業務・サービスの実態に合わせて方式を選択することが必要となります。
システム移行の方式とそれぞれのメリット、ユースケースを確認しましょう。
一斉移行
一斉移行はレガシーシステムをすべて同時に新システムに切り替える方式です。一斉移行の場合、移行自体が短時間で完了でき、さらに移行前後で運用するのは1システムのみです。そのため、システムの管理コストが少なく済むメリットがあります。
一方で、移行後に不具合が生じた場合は切り戻しができないため、業務に大きな影響を及ぼします。事前準備やリハーサルを実施して移行の失敗リスクを下げることや、失敗時を想定した対策を立てておくことが重要です。
また、システムが使えない時間帯＝業務停止の時間帯が生じるため、夜間や土日祝日などエンドユーザーや従業員の利用が少ない時間帯を見極めて移行を実施することが望ましいです。
一斉移行は、短期導入が求められるシステム、業務停止の影響が小さいシステムなど、まとまったダウンタイムを確保しやすいシステムを移行する場合に行われることが多い方式です。
順次移行
順次移行は移行するシステムのうち、優先順位や依存関係から一部ずつシステムを段階的に移行する方式です。部分ごとに移行を進めるため、リスクを分散しながらシステム移行を進められます。
移行時に不具合が生じても切り戻しがしやすいので、移行フェーズ（作業）ごとに発生する各トラブルに対処しながら移行を進められる点がメリットです。
一方で移行期間が長くなりやすく、新旧両方のシステムが運用されている期間が存在するので、運用コストが高くなりやすい点や、フェーズごとの調整によりプロジェクト管理が複雑化する点がデメリットと言えます。
一斉移行と比較してエンドユーザーに影響が生じにくい手法なので、大規模システムやグローバル展開する企業の基幹システムなど、業務継続を重視するシステムを移行するケースに向いています。
並行運用
並行運用は新旧システムを両方とも運用し、新システムでの動作確認をしながら業務の遂行に問題がないことや、停止リスクの影響が少ないと判断したものから移行を実施する方式です。
順次移行は影響の大小にかかわらず故障や致命的な問題がなければ移行を完了させます。一方で並行運用は最初から新旧システムを両方とも稼働させる前提で移行を進めていくため、トラブルが発生しても、切り戻しがすぐにできて、失敗が起こりにくいというメリットがあります。
ただし、並行運用は新旧システムの並行運用期間が長いため、運用コストや管理の負担が順次移行よりもさらに高くなります。データの整合性維持や更新が複雑になり、データ同期や運用管理に高度な対応が求められる点もデメリットです。
並行運用は高い信頼性が求められる金融機関や医療機関のシステムなど、リスクを極力減らして移行したいシステムに向いています。
パイロット運用
パイロット運用は新システムの一部機能を一部ユーザーや部門に試験的に利用してもらい、影響を見極めながら移行を進めていく方式です。実際の稼働環境での動作確認を行い、トラブルの検出やフィードバックによる改善を図りながら進めるため、失敗リスクの低減につながります。
また、新旧両方のシステムを並行運用するものの、新システム側は小規模なシステムでよいので並行運用のコストも抑えられます。順次移行と並行運用、どちらのメリットも受けられる移行方式です。
ただし、パイロット運用時に問題がなくても実際の運用開始時に他部門とのギャップが生じてしまう可能性があることや、旧システムと新システムのデータ同期を行う必要性がデメリットとして挙げられます。
パイロット運用は新規サービスのためのシステム導入や、大規模なシステム刷新プロジェクトなど、システムの全体展開をスムーズにするために用いられます。
システム移行の具体的な手順
システム移行を進める大まかな流れは以下のとおりです。
- 現行システム（レガシーシステム）の課題と移行する内容の整理
- 移行計画の策定
- 移行の実施
- 新システム移行後の保守運用 ・サポート体制の構築
前章で解説した通り、移行方式にはいくつかのパターンがありますが、どのパターンでも上記の流れは変わりません。異なるのは各手順の作業タイミングだけです。
続いて、具体的にどのような手順でシステム移行を進めるのかを解説していきます。
現行システム（レガシーシステム）の課題と移行する内容の整理
システム移行を始めるにあたり、まずはレガシーシステムの現況と課題について整理しましょう。
既存システムの把握
既存システムと他のシステムやアプリケーションとの依存関係やハードウェア、ソフトウェアのバージョンなどを把握し、移行に必要なリソースを具体化します。移行前時点でのシステムの重要度やシステムのユーザー数などの確認も必要です。
システム移行後に既存システムで利用していた機能を利用できない、いわゆる「デグレード」を生じさせないよう、既存システムの仕様を把握することが不可欠です。
システム移行とあわせて業務プロセスを変更する可能性も踏まえながら、移行後のシステムに求めることを明確にしておきましょう。
移行する機能やデータと移行しないものを判別する
容量やハードウェアとの相性、次期環境の構成に応じて、既存システムの不要な機能やデータを判別しましょう。ただし、必要なものまで不要として移行対象から除外してしまうと、デグレードになるので注意しましょう。
例として、3年以上使っていない機能やデータは重要なものを除いて削除するといった基準を決めておくと、移行後に必要かどうかを判別しやすくなります。
移行計画の策定
必要な機能・データの判別まで完了したら、移行計画を立てる工程に進みます。
どのシステムを、どのように（移行方式）、誰が、いつまでに、など5W1Hに沿って計画を立てます。
どのシステムを移行するのか
既存システムの調査結果をもとに、クリティカルな業務システムや依存度の高いシステムを優先的に移行計画に組み込みます。
ほかにも決めるべき項目として以下があります。
- 各システムの移行に要する時間
- 詳細な移行スケジュール
移行期間中の業務への影響を最小限に抑える調整や、関係部署・ステークホルダーとの調整連携も必要です。
移行方式を選ぶ
システムの重要度、ユーザー数、移行に必要な時間などから総合的に移行方式を決定します。
例としては、下記のとおりです。
- システム移行に伴うダウンタイム時間をまとめて確保できる…一斉移行
- 社内全体で使うシステムのため、部署ごとに移行を進めたい…順次移行
プロジェクトメンバーの選定
IT部門の担当者や部門の代表者などと、計画時や移行時の役割分担を決めます。
必要となるプロジェクトメンバーは移行するシステムやデータへの精通度合い、スキルから総合的に選定しましょう。必要となる人材例は以下のとおりです。
- プロジェクトを統率するマネージャー
- 設計を行うシステムアーキテクト
- 開発作業を行うシステムエンジニア
- サーバーやネットワークを構築するインフラエンジニア
これらの人材を自社のみで賄うことが難しい場合は、システム開発会社への外注も検討しましょう。
移行手順の具体化
移行計画を立てる際は、各ステップを分解して、以下のような手順に沿った作業計画を作成します。
- 既存システムのデータバックアップ
- 既存システムの停止
- 新システムへのデータ移行
- システム再起動
- 検証手順など
手順を整理してプロジェクトメンバーで共有しておくと、リハーサルや本番移行の失敗リスクを低減できます。
また、予期せぬトラブルが発生した際の対応策を事前に検討し、リスク管理計画を策定することも大切です。移行失敗時のロールバック手順や障害発生時の対応フローなどを決めておきましょう。
システム移行の実施
移行手順を整理したら、システム移行作業を実施します。
リハーサルの実施
リハーサル用のテスト環境を用意して本番同様の作業を行います。リハーサルの目的と移行対象システムやデータ、周辺システムとの連携部分も含め、移行日当日のスケジュールを想定し、時間内に完了するようにタイムラインを組みましょう。
最重要ポイントはリハーサル時に発見された問題があれば記録をして、本番移行時に再発しないよう対策を練ることです。対策を手順や設計書に追記し、担当者間で共有して本番移行に備えます。
移行後のテスト項目はリハーサル前までに策定し、リハーサル環境でも確認すると、本番移行後のトラブルを防ぎやすくなります。
本番移行
本番環境への移行を実施する段階です。リハーサルと同様、またはリハーサルを受けて修正した手順に沿って、システムの切り替えを進めます。
万が一移行に失敗したり、エラーが発生したりした場合は、事前に決めておいた連絡先への連絡や切り戻し手順を実施して、システムダウンを最小限にとどめることを念頭に行動する必要があります。
移行後の受け入れテスト
システム移行後の受け入れテストを実施します。機能が正常に利用できるかどうかの確認とあわせて、パフォーマンスやセキュリティのテストを実施します。
具体的なテスト項目例として以下があります。
- 同時接続数が1,000を超えても問題なくリクエストを処理できるか
- CPUが高負荷になった場合にどのような挙動になるか
- ポートスキャンテストを実施し、閉じているべきポートが開いていないか
計画時点でテスト項目と基準を決めておき、基準を満たしているかどうかを移行後のタイミングで測定しましょう。
移行方式が並行運用、パイロット運用の場合は受け入れテストを実施し、問題ないことが確認できれば、既存システム（レガシーシステム）の廃止に進みます。
既存システム（レガシーシステム）の廃止対応
新旧システムを並行運用している場合、移行後のシステムに問題ないことが確認でき次第、既存システム（レガシーシステム）の廃止対応を行います。
新旧システムを並行運用する期間中は運用管理コストが高くなるため、できれば早い段階で既存システムを廃止することが望ましいです。
廃止対応の大まかな流れは以下のとおりです。
- データは必要なものをアーカイブし、不必要なものは削除
- サーバーやストレージデバイスは安全な手順で物理廃棄、リサイクル
- 旧システムの終了を関係者に通知し、旧システムへのアクセスが発生しないよう対応
上記の手順で進めることで、情報漏洩のリスクや不要な旧システムへのアクセスを防げます。
新システム移行後の保守運用・サポート体制の構築
システム移行後はユーザーからの問い合わせが殺到する可能性が高いため、対応できるように窓口やQ&Aを用意しておきましょう。トラブル発生時のため、IT担当部門によるサポート体制の整備も重要です。
システムの安定稼働に向け、上記のサポート体制の整備に加えて、稼働状況のモニタリングやアラート設定、トラブル対処手順の整備など緊急時に迅速な対応ができるようにしておきましょう。
運用開始から一定期間が過ぎたら、ユーザーからのフィードバックを踏まえて機能改善や操作性向上のための改修を検討するのもよいでしょう。
スムーズなシステム移行を実現するためのポイント
スムーズなシステム移行のためには手順に沿うだけでなく、ポイントを押さえておく必要があります。
具体的にどういった準備が必要なのか、確認しましょう。
関係者との綿密なコミュニケーションを実施する
経営層を含む社内関係者の理解を得ることで、スムーズなシステム移行が実現できます。
関係者間でのコミュニケーションが足りないと、以下のようなトラブルが生じてしまうことがあります。
- 要件定義がうまくいかず、技術的に実現できることが実現できない
- レガシーシステムに実装されていた機能がなくなり、使いづらくなってしまう
- 新システム移行のために必要な予算や人員が確保できない
例えば、レガシーシステムに固執する従業員がいる場合、新システムを利用するメリットや既存システムの利用を続けるリスクを丁寧に説明してコミュニケーションを取り、納得してもらい、解決を目指す必要があります。
また、経営層には費用対効果やメリットを定量的に示し、システム移行の重要性を理解してもらう場の設定が効果的です。
事前計画を徹底する
スムーズなシステム移行のためには、詳細な事前計画が鍵となります。移行フェーズごとにスケジュールや対応範囲、手順を定めておき、担当者やリスク対策なども決めておきましょう。
特に、新旧システムのデータや機能の差分が大きいほど、不測のトラブルが発生する確率が高くなります。計画通りに進まないケースを考慮し、柔軟に対応するためのバックアップやリカバリ期間の設定も大切です。
トラブル発生はシステム移行の大きな妨げになるので、リハーサルでトラブルへの対応方法をまとめたり、トラブルが起こりにくい手順に修正したりすることが重要です。
事前計画にあたり、移行プロジェクトの参画者は既存システムの細かい仕様や使い勝手を確認して、不明点を極力なくしておきましょう。必要に応じて、既存システムの運用担当者への仕様確認や、既存システムの設計図の更新なども実施すると認識の齟齬無くシステム移行を行えます。
業務への影響を最小限にとどめるスケジュールと手順設定を行う
システム移行は多くの場合、切り替えに一時的なダウンタイムが生じるケースがあります。
業務やサービスに支障のないスケジュール・手順でシステム移行を進めましょう。
例えば、24時間稼働が求められるシステムは、業務が比較的少ない時間帯や非稼働日に移行を実施することはもちろん、ユーザーへの事前通知を行わなくてはなりません。
本番移行後にトラブルが発生し、さらに移行前のシステムも使えない状況になるとユーザーへの影響が大きくなり、業務においても損害が発生する場合もあります。
特に、サービスレベルアグリーメント（SLA）に基づくサービスを提供している場合は、移行に伴うダウンタイムやトラブルはSLA違反となりユーザーへの支払い義務が生じるなどリスクが大きくなります。
本番移行で失敗した時の影響を小さくするための準備として、バックアップの確保や失敗時に自動で移行前のシステムに切り替えるフェールオーバーを設定しておくことも大切です。
リソース不足の場合は外注を検討する
社内で十分なリソースが確保できない場合は、外注業者への依頼を検討することもスムーズなシステム移行を実現する一つの手段です。
外部のシステム会社には豊富なノウハウや経験があるので、プロジェクトの一部または全体を委託すると、スムーズな移行を実現できます。
システムの秘匿性が高い場合などは、システム移行が行える社内人材の育成も有効といえるでしょう。ただし、近年のクラウド環境への移行やセキュリティ強化が求められるプロジェクトでは、最新技術に精通した人材が必要となるため、時間的な制約により育成まで手が回らないケースが多くあります。
専門知識を持つシステムエンジニアやインフラエンジニアに依頼することによって、移行のスピードが速まるほか、従業員の技術スキルの向上も期待できます。
まとめ～レガシーシステム移行の計画はお早めに～
レガシーシステムの移行が進んでいない企業はまだ多く存在しますが、新しい環境へのシステム移行を進めなければ、システムの拡張性・セキュリティ面・運用コスト面など多くのリスクを背負ったまま業務を継続することとなります。
自社でレガシーシステムを使い続けている場合は、ビジネスの発展や業務効率化のためにも早期にシステム移行に踏み切ることが望ましいといえるでしょう。
本記事で解説したシステム移行時の手順や移行方式、スムーズな移行のためのポイントを参考に、まずはシステム移行計画の策定から始めてみることをおすすめします。
Webシステムのレガシー化にお悩みの企業のみなさまへ
「今使っているシステムが使いにくい・古くなった」「セキュリティ面で不安がある」「移行人員が確保できない」など、業務システムのレガシー化に関連したお困りごとはありませんか？
また「業務を効率化したい」「ミスをなくしたい」などの業務改善のお悩みはありませんか？
グローバルネットコアは、Webシステム開発・Webサイト制作をはじめとするWebソリューションの構築・導入から運用・保守までトータルサポートしています。
具体的なサービスとして、Webシステム開発・システム保守・Webコンサルティング・サイト制作・効果測定・運用サポートなど、幅広く対応していることが特徴です。
Webシステム・サイトに関するあらゆる悩みや要望をヒアリングして、最適なサービスを提供します。
また、Webだけでなく、サーバーや社内ネットワークなどのITインフラ領域も一気通貫でサービスを提供しています。
些細なことでも、漠然とした課題感でも、Webシステムに関するお悩みは、当社へお気軽にご相談ください。
