企業活動に利用しているシステムは、年数の経過や環境の変化に伴いシステム移行が必要となります。

移行作業ですが、実は新規の開発よりも難易度が高いと言われていることをご存じでしょうか。

本記事ではシステム移行の種類や手順をご紹介し、難易度が高いと言われている理由を解説します。
また、スケジューリングや手戻りを発生させないコツなど、失敗しないための注意点もご紹介します。

下記のような方には特に役に立つかと思います。ぜひご一読ください。

• システムの移行にはどんな方法があるのか、どのような手順でおこなうのか知りたい方
• なぜ難易度が高いと言われているのか理由を知りたい方
• 移行を予定しており、成功させるポイントを調べている方

システム移行とは？

システム移行とは、既存システムから新しいものへの切り替えを意味します。
英語ではSystem Migrationと書きます。

下記のような類似用語がありますが、移行の対象が異なるためご注意ください。

• データ移行：従来とは異なるデータベース、ストレージなどへデータを移す作業。
• 業務移行：新システムで業務を運用すること、および運用のための準備作業。

「使うシステムが変わるだけじゃないの？」と思われる方も居るかもしれませんが、システム移行は一歩間違えると業務不可な状況にも繋がりかねない、極めて重要な作業です。

システム移行が必要となるタイミングとは

大企業や中小企業にも、システム移行が必要となるタイミングが存在します。
主なものとして、機器やOSのサポート終了、経営統合や古いシステムの刷新が挙げられます。

また、「2025年の崖」という用語もあり、業務効率化や競争力の強化のためにも移行を検討する企業が今後さらに増えると予想されます。

ここでは、移行が必要となるタイミングと、失敗しないための注意点についても解説します。

ハードウェアやOSのサポートが終了するタイミング

代表的なシステム移行のきっかけに、サーバーやストレージといった機器やOSのサポート終了があります。

サポート切れの機器を使い続けることもできるのですが、関連システムやソフトウェアとの連携が不可になったり、脆弱性が高まりサイバー攻撃に晒される危険性が生じるなど総じてリスクは高いです。

リスクを回避しながら企業活動を継続するためにも、利用中の機器やOSのサポート終了が分かった場合は、移行の検討を始めることをおすすめします。

本章では、ハードウェアとOSの場合それぞれ詳細と対応策についても解説します。

ハードウェアのサポートが終了するタイミング

長年にわたって機器を使用していると、サポートが終了するということがあります。
サポート対象外となった機器を使い続けることもできるのですが、例えばサーバーやストレージに異常が発生した際の調査や機器交換サポートを受けられず、業務を続行できないリスクとなります。

加えて、長年使用している機器の場合は特に経年劣化による故障のリスクは年々高まり、サポートの重要性も高まっていきます。

移行プロジェクトは数ヶ月～1年以上を要することがほとんどです。
移行がサポート終了に間に合わないということが無いように、サポート期限はしっかり把握しておけると良いですね。

OSのサポートが終了するタイミング

同様に、OSも長年使用し続けていると、サポートが終了する場合があります。
例えば近年では2023年1月にWindows 8.1のサポートが終了しました。

サポート対象外であっても引き続き使用することもできますが、下記のようなリスクが存在します。

• セキュリティリスクの上昇：セキュリティアップデートが適用されず脆弱性が高まり、サイバー攻撃による情報漏洩やデータ損失のリスクが高まります。
• 他サービスやソフトウェアへの影響：連携するサービスやソフトウェアが順次該当OSに対応しなくなり、利用不可となる可能性があります。

通常、OSのサポートが終了する場合は1年以上の猶予をもって連絡されるものであり、2024年4月時点で2025年10月にWindows 10のサポート終了が公表済です。
定期的にメーカーのサイトを見に行くなど早めに情報をキャッチし、余裕をもった検討ができると良いですね。

環境の変化に伴うシステムの統合

続いて、企業統合やM&Aといった企業環境の変化も移行の要因となります。
複数の企業が統合する場合、いずれか一社のシステムへ統合したり、またはまったく別のものを導入するなど必然的に移行作業が発生します。

また、複数企業の運用業務や既存データを融合しながら移行先の検討や検証をする必要があるため、移行プロジェクトは規模が大きく難易度が高いものになります。
ステークホルダーも多くなるため、事前検討や調査の工数を厚めに確保すると良いかと思います。

老朽化したレガシーシステム

長年使用し続けているシステムをレガシーシステムと呼びますが、レガシーシステムを脱却し新しい技術やフレームワークを取り入れることもシステム移行に該当します。

経済産業省が提唱する「2025年の崖」という言葉をご存じでしょうか。
レガシーシステムを使用し続けていると競争力はどんどん低下し、2025年以降は年間で約12兆円の経済損失が発生すると言われています。

そういった事態を避けるためにもDX化を推進する必要があり、レガシーシステムを脱却しAIやIoT技術をといった新しい技術の導入が推進されています。

長年使いこまれたシステムはカスタマイズにより複雑化していたり、企業活動に深く根付いており移行が難しくなる傾向があります。
ですが、新しいシステムへの移行は業務効率化や競争力向上など企業活動にメリットとなります。
慎重に進める必要はありますが、レガシーシステムを使用している企業はぜひ移行を検討してみてください。

システム移行の方式

ここまで、移行の検討を開始するタイミングをご紹介しました。
次は、代表的な移行方式についてご説明します。

コストやリスク、どのようなケースにおすすめかについても解説します。
移行が決定しており方針に悩んでいる場合には特に役に立つかと思いますので、ぜひご一読ください。

一括で新システムへ切り替える方式

まずご説明するのが、旧システムを停止と新システムの稼働を一度におこなう方式です。
この場合、停止と稼働を一度におこなうため切り替えの作業ボリュームが大きく、システムが止まる期間が多いため週末やゴールデンウイークなど大型連休におこなうことが多いです。

一括で切り替える場合、実施作業は下記のような流れになります。

• データバックアップを取得
• 旧システムを停止
• ネットワーク切り替え
• 新システムを稼働

上記が完了して確認作業をおこない、問題がなければ運用開始です。
もしも問題が見つかり新システムの稼働が不可と判断された場合、設定を戻し旧システムを再稼働させます。

メリット

一括で新システムへ切り替える場合、下記のメリットがあります。

• 移行の検討期間や実際の移行期間が短い
• コストが低い

一括移行方式の場合、例えば金曜日までは旧システムを使用し、土日に移行作業、月曜日からは新システムが稼働というように短期間で移行が完了します。

また、新旧両方が稼働する並行稼働期間がないため他方式と比べると調査や検証の観点が少なく、プロジェクトが短期間で完了する傾向があります。

そのためプロジェクト工数が小さくなり、コストが低いという特徴があります。
機器サポート終了などの関係で早く切り替えをおこないたい場合やコストを低く抑えたい場合におすすめの方式です。

デメリット

一括移行方式には、他方式と比べ下記の課題があります。

• 問題発生時の切り戻し工程が多い
• システムを利用できない時間が発生する

本方式では切り替えに伴う全作業を一度に進めます。
例えば新システムが稼働した最終工程などで問題が見つかった場合は切り戻し作業が多く、予定時間内に作業が完了しなかったり、作業ミスが発生するリスクになります。

タイムスケジュール上に定期的にマイルストーンを設置し、切り戻しが不要かの判断ポイントを設けたり、切り戻しとなった場合に何の作業がいつ完了するかシミュレーションをして対策をしましょう。

また、新旧両方のシステムが利用不可の時間が発生するため、利用者に不便をかけたり販売機会を逃す可能性があります。
そのため、BtoCなど常時利用されるシステムの場合不向きかもしれません。

段階的に新システム切り替える方式

一度に全部を切り替えるのではなく、部分的な移行を繰り返す方式もあります。
この場合、最終的に移行が完了するまで下記作業を繰り返して進めていきます。

• 一部機能を移行（ネットワーク切り替えやデータ移行を含む）
• 新機能を利用
• 問題がなければ他機能を移行

上記例では機能を段階的に移行していますが、業務や利用者を順次移行していく方式もあり、パイロット移行方式と呼びます。
この場合、例えば一部署の業務を先行して移行し、稼働に問題がなければ他部署も移行を進めます。

メリット

段階移行には、下記2点の目立った特徴があります。

• 問題が発生した際に影響範囲が明確である
• 一度の移行時間が短い

最も大きな特徴が、移行がでもし問題が発生した場合に影響を局所化できるという点です。
移行をおこなった機能や業務、それに直結した業務に影響が限定されるため、迅速に復旧やリカバリ作業に着手できます。

また、一度一度の移行ボリュームは小さいため、作業時間が短い特徴もあります。
影響が限定的なことも伴い、移行スケジュールは立てやすいです。

影響を限定的にしながら慎重に移行を進めたい場合や、大型連休でなく平日など移行時間を短くしたい場合におすすめの方法です。

デメリット

一方、段階移行方式にはデメリットも存在します。

• 検討事項が多い
• プロジェクトが長期化しやすく、コストが膨らむ可能性がある

この方式を採用する場合、特定の機能が移行済の状態で関連業務は問題なく進められるかなど、検討や検証すべきことは多くなります。
そのため工数は大きくなり費用も膨らむ可能性があります。

また、移行実施回数が複数回に及び、各作業で手順書の整備や移行リハーサルが必要となることからプロジェクトは長期間に及ぶ傾向があります。
作業工数、人員確保の観点でもコストは高くなる可能性があります。

移行を早期に済ませたい企業やコストを抑えたい企業には不向きかもしれません。

現行システムと新システムを同時並行で運用しながら進める方式

新旧システムが並行運用する移行方式もあります。
この場合、移行作業が完了後、新システムの安定稼働が確認できるまで、既存システムも稼働したままとなります。

具体的な流れは下記のようになります。

• ネットワーク接続など、新システムの稼働準備をおこなう
• データを入力（またはデータ同期）
• 新システムを起動
• 一定期間稼働を続け、問題が発生しないことを確認
• 旧システムを停止

メリット

並行運用稼働方式には下記の利点があります。

• リスクが低い
• 利用者の安心感が高い

この方式の最大の特徴はリスクが低いことです。
並行稼働をするため、仮に新システムに致命的な問題が見つかった場合も旧システムで業務を存続することができます。

また、問題や障害が見つかった場合も既存システムで業務を存続しながら調査やバグ修正などリカバリができるため、業務へ与える影響が少ないです。

もう一つの特徴として、移行が完了するまでに利用者が新システムを実際に使用するため、安全性や使い勝手が分かっており、利用者の安心感は高いと言えるでしょう。

リスクを極力抑えたい場合や、利用者が移行に不安を感じる場合におすすめの方式です。

デメリット

一方で、並行運用稼働方式には下記の難点があります。

• コストが高い
• データの整合性が取れないリスクがある

この方式では、新旧双方のシステムが両立するため、設定作業や保守作業でコストは高くなることが見込まれます。
また、利用者は一定期間2つのシステムを業務に利用するため、どのように双方を使用するかといった検討や負荷が高くならないようなケアも必要になります。

もう一つの難点に、データの整合性が取れないリスクがあります。
データを双方に手入力する場合、入力を誤らないような仕組み作りが重要です。
またはデータを同期する処理を組み込む場合は、正確性や負荷が高い場合にも問題なく同期されるか、しっかりとした検討や検証作業が必要となります。

検討事項や検証作業も多くなるため、コストを抑えたい企業には不向きかもしれません。

システム移行のパターンは2つ

システム移行は、移行先が自社管理システムか、ベンダーが提供するクラウド型かによって2つのパターンに分けられます。

ここでは、2つの移行パターンの概要と、各移行パターンの費用やカスタマイズ性についても解説します。

サーバーを効率的に使用する技術のひとつに、仮想化技術があります。
下記記事では仮想化技術の概要や導入時の注意点も記載しているので、興味がある方はぜひ参照ください。

自社に設置したサーバーやネットワークを使ってシステム運用を行う

一つめのパターンは、自社に設置したオンプレミス型への移行です。

オンプレミス型とは、自社でネットワークを構築し、自社で保守もおこなう形態です。
クラウド型と比較すると初期コストはかかりますがランニングコストがかからず、自社に応じた作り込みが可能だという特徴があります。

この移行パターンの場合、移行作業は全て自社内で完結します。
そのため外部要因を挟まず連携や作業をスムーズに進めることができます。

一方で、システムの総入れ替えとなるためサーバーなどの構築費用が高額になり、専門知識が必要という点は注意が必要です。

オンプレミスからクラウドに移行する

二つめの移行パターンは、クラウド型への移行です。

クラウド型ではベンダーが運用するサーバー上に自社システムを構築します。
ランニングコストがかかりますが、サーバーメンテナンスや老朽化対策、セキュリティ対策もベンダーに任せることでき、その利便性から近年利用する企業が増加しています。

クラウド型へ移行する場合、サーバーやネットワークの構築作業が不要であるため、コストは低くスピーディーな移行が可能です。

注意点として、OSやソフトウェアのバージョンやネットワーク構成の都合で予期しない連携エラーが発生する可能性があります。
また、オンプレミス型と比較するとカスタマイズ性は劣るため、自社に合わせた作り込みを予定している場合は不向きかもしれません。

システム移行が難しい理由・注意点

システム移行は、綿密な方針検討や作業の正確性を要することから新規開発よりも難易度が高い作業だと言われています。

また、データ不適合など一つの誤りが業務に多大に影響を及ぼす可能性もあり、事前のデータ調査も高い正確性を要します。

本章では、システム移行が難しいと言われている理由を、注意点も含めて解説します。
移行を検討中の企業の方は特に役に立つかと思いますので、ご一読ください。

作業の正確性が求められる

システム移行では、本番移行時はもちろんのこと、調査・検証段階も正確性が重要となります。

本番移行時はタイムスケジュールに沿って移行作業を進めるため、誤りが発生すると手戻りとなり後続の作業に影響を与えます。
また、データ移行や設定の誤りなど、場合によっては新システム稼働に致命的なエラーとなり、移行後に新システムが稼働できない可能性も考えられます。

致命的な誤りは、調査段階でもありえます。
例えば、新旧で一致していないデータ構造が誤って一致と判断されてしまった場合、プログラム修正の必要性に気がつかないまま後続の検討や見積に進んでしまい、発覚したプロジェクト中期や後期に影響を与えます。

移行作業では個人が作業が誤りに気をつけるほか、再鑑体制を敷くなど一つ一つのタスクを正確に対応することが重要です。

緻密な計画が必要

システム移行では綿密な調査とスケジューリングが必要となります。
検討段階で網羅的に作業を洗い出し、各作業の見積をおこなってスケジュール作成をすると思いますが、様々なトラブルが発生する可能性があります。

例えば、データの移行漏れや不一致のリスクがあります。
移行データの量が多いほど移行漏れのリスクは高くなり、データベースの差異によりデータ構造が不一致になるリスクも存在します。

また、移行先サーバーやシステムは従来よりスペックが向上すると思いますが、急激な処理能力の向上によりメモリが枯渇するなどトラブル発生の可能性もあります。

できるだけ不意のトラブルを防止できるように、検討段階から有識者に参画してもらい、細部まで配慮の行き届いた計画を立てられると良いですね。

限られた期間内に作業しないといけない

移行作業は基本的に多くのステークホルダーが関係するため、予定時間内で作業を完遂させることが求められます。

一定期間システムが利用不可となる場合は特に、利用者に事前に利用不可の旨を通知していると思います。
仮に予定時間を超過しても稼働ができない場合は販売期間の損失や顧客満足度の低下につながります。

遅延なく移行作業を完遂するためには、移行準備の際に下記2点に注意をしてください。

• バッファ時間を織り込んだスケジュール：バッファを織り込み、余裕を持たせた移行タイムスケジュールとしましょう。
• コンティンジェンシープランの策定：本番作業時に起こりうる問題を事前に想定し、有識者にも確認してもらい対応策を事前に検討します。

新旧のシステムで扱えるデータが異なる場合がある

移行計画ではデータ構造の確認は特に重要な作業です。
新旧システムで同一のデータとなるべきが、製品やバージョンの差異から、空白データの扱い方や小数点データのデフォルトの四捨五入設定など差異が発生する場合があります。

旧システムのデータ構造をそのまま維持できるか、またはデータ構造が変わる場合はそれに合わせどのプログラムを修正するのか、検討段階で整理しマッピング資料を作成しておくと良いです。

また、データ構造以外でも注意が必要です。
例えばファイル形式やOfficeのバージョンなど、旧システムで扱っているファイルやソフトウェアは引き続き使用可能か、検討段階で網羅的に確認ができると良いですね。

システム移行の一般的な手順

次は、移行の一般的な流れについてご説明します。
移行形式などに関わらず、システム移行は基本的に今回ご紹介する手順になるかと思います。

移行では、事前調査、計画策定、リハーサルやリリース後などプロジェクト全体にわたりマイルストーンが存在します。
失敗しないための注意点もあわせて記載していますので、参考になれば幸いです。

手順1：移行元システムとデータの調査

最初に、既存システムのスペックやネットワーク構成、データを確認します。
下記は確認観点の一例です。

• OSの種類やバージョン
• サーバーやストレージの容量
• 対応可能なファイル形式
• データ構造
• データ量
• バックアップ取得方法

データ量について、蓄積データであれば移行時にどの程度の容量となっているかシミュレーションしましょう。
また、例えば直近数年分のデータなど一部データを移行対象とすると、新システムをスリム化し移行費用を抑えることが可能です。

データ量・構造の確認は今後の作業内容や工数に影響が大きい作業です。
有識者を交え、手戻りのないように進められると良いですね。

手順2：移行計画書の作成

次は移行の情報をとりまとめ、計画書として記載します。

• 概要：移行時の前提条件
• 対象：データや機能、ネットワーク構成など移行対象
• 使用ツール：データ移行や確認に使用するツール
• 方式：本番移行で採用する方式。一括移行、段階機能移行、並行運用移行など
• スケジュール：移行時におこなうタスクと見積からスケジュールを策定
• 移行時の影響：移行作業中の業務への影響
• 体制：チーム編成と役割
• テスト：移行テストの範囲や実施環境

情報処理推進機構(IPA)のサイトに、より詳細な移行計画書の情報が記載されています。
興味がある方は下記のリンクからご確認ください。

情報処理推進機構(IPA)の公式サイトはこちら

手順3：移行リハーサルの実施

次は、本番で使用する手順書をもとに、移行リハーサルをおこないます。
本番作業時に発生しうる課題を事前に検知するため、実施時間帯や環境は可能な限り本番と同様な条件でおこないましょう。

課題が見つかった際は、リハーサル完了後に課題解消の対策を練ると思います。
対策が有効であるかを確認するためにも、少なくとも2回はリハーサルを実施するようスケジュールを組みましょう。
また、問題が発生した際の切り戻し手順もこの段階で確認しておけると良いですね。

手順4：移行作業を実施

リハーサルで手順に問題ないことが確認できたら、いよいよ手順書に沿って本番の移行作業となります。

注意点として、一つの誤りが後続に大きな影響を与える可能性があります。
手順書は誰が見ても分かるような明確な記載とし、チェック体制を敷いて誤りのないよう慎重に進めます。

また、環境差異の原因など、どうしても本番まで検知できない課題も発生するかもしれません。
慌てずに上司や有識者へ判断を仰げるよう、緊急時の連絡先を明確にしておきましょう。

手順5：新システムのテストをする

移行作業が完了後、新システムで問題なく運用を開始できるかテストをおこないます。
実際の業務を始める前に網羅的に確認するため、下記のように非機能検証を含めてテストしましょう。

• 通常業務が問題なく実施できるか
• データ構造は正しく移行できているか
• 移行先データ量は想定通りであるか（データの移行漏れがないか）
• 高負荷に耐えられるか
• サーバーのCPUやメモリ使用率は余裕はあるか

テストケースが多く時間が長くなってしまう場合は、ツールの導入や確認用スクリプトを実装し自動化をするのも有効ですので、検討してみてください。

手順6：運用担当者への引継ぎ

移行の最後の手順は、運用担当者へ引き継ぎや教育です。
運用担当者が新システムに戸惑うことがないようマニュアルを整備し、必要に応じて説明会を実施します。

大きく運用が変わる場合は、例えばリハーサル段階から引き継ぎを開始するなど引継ぎ期間を長めにとり、できるだけ不明点を潰したうえで運用を開始するようにしましょう。

また、運用担当者のみでは特定分野の知識が弱いこともあるかもしれません。
移行完了後、安定稼働するまでは移行担当者と連絡が取れるようサポート体制を整えると良いですね。

システム移行のまとめ

本記事では、システム記事の検討タイミングや移行方式、手順についてご説明しました。
下記に内容をまとめます。

• システム移行とは既存システムから新システムへ切り替えること
• ハードウェアやOSのサポート終了、企業統合や効率化の際に検討する
• 移行には一括移行、段階移行、並行運用の方式がある
• 作業の正確性が求められ、新旧システムでのデータ差異などの理由により難易度が高いとされている
• 既存データ調査、移行計画書の作成、移行リハーサル、移行、テスト、引継ぎの流れで進める

システム移行は、時間内に作業を完遂させる正確さと計画性が必要であり難易度の高い作業です。
システム移行についてのご質問や、移行を企業に依頼するご相談は株式会社Jiteraへご連絡ください。
実績豊富なITの専門家が貴社のお手伝いをさせて頂きます。

株式会社Jiteraへのご連絡はこちらから