システムマイグレーションの期間はどのくらい？規模別の目安と工期短縮の方法

レガシーシステムの移行を検討するとき、費用と並んで気になるのが「いつまでに終わるのか」です。移行が長引けば、その間も古いシステムの保守費用とリスクを抱え続けることになります。サーバーの契約更新やOSのサポート終了など、期限が先に決まっているケースも少なくありません。

この記事では、システムマイグレーションにかかる期間の目安を規模別に整理したうえで、スケジュールの内訳、工期が延びやすい要因、切替日の決め方、そしてAIの活用で期間がどう変わるのかを解説します。

システムマイグレーションの期間の目安【規模別】

マイグレーションの期間は、対象システムの規模にほぼ比例します。規模はソースコードの行数、いわゆるステップ数で測るのが一般的です。機能を変えずにプログラムを新しい言語・フレームワークへ書き換えるリライト方式を、従来どおり人手中心で行う場合のおおよその目安は次のとおりです。

移行方式によっても期間は大きく変わります。プログラムはそのままに稼働環境だけを新しくするリホストであれば、同じ規模でもこの目安よりかなり短く済みます。逆に、業務要件から見直して作り直すリビルドは、要件定義からやり直すため最も長くなります。方式ごとの違いと費用への影響はシステムマイグレーションの費用相場で詳しく解説しています。

なお、この目安はあくまで人手を前提とした従来手法の場合です。AIを活用した移行では前提が変わります。これは記事の後半で説明します。

期間の内訳はテストが半分近くを占める

スケジュールを考えるうえでまず知っておきたいのが、期間の内訳です。マイグレーションの工程は大きく4つに分かれ、それぞれの比重はおおよそ次のようになります。

意外に思われるかもしれませんが、期間の面で最大の工程はプログラムの書き換えではなく、テスト・検証です。マイグレーションは「移行前とまったく同じように動くこと」がゴールであるため、画面や帳票、バッチ処理の一つひとつについて新旧の動作を突き合わせる確認作業が発生します。この工程がプロジェクト全体の半分近くを占めることも珍しくありません。

ベンダーの提示するスケジュールを比較するときは、全体の長さだけでなく、テスト・検証にどれだけの期間が確保されているかを見てください。ここが不自然に短いスケジュールは、一見魅力的でも本番切替後の障害リスクを抱え込むことになります。

スケジュールが想定より延びる3つの要因

マイグレーションのスケジュールは、当初の計画から延びる方向に振れがちです。典型的な要因は3つあります。

現行調査が長引く。 設計書や仕様書が残っていない、仕様を知る担当者が退職している、といった状態だと、コードを読み解いて仕様を確かめる作業に想定以上の時間がかかります。調査は最初の工程であるため、ここでの遅れはそのまま全体の遅れになります。

テストで手戻りが発生する。 新旧の動作を突き合わせる中で差異が見つかれば、修正して再テストの繰り返しになります。長年の改修で複雑化したコードほど、1か所の修正が別の場所に影響し、このループが長引きます。

移行中の機能改修に追従が必要になる。 移行期間中も業務は止まらないため、既存システムには改修が入り続けます。移行作業を凍結して待ってもらうか、変更を移行側に取り込み続けるか。凍結すれば業務に影響し、取り込めば移行作業が増える。期間が長いプロジェクトほど、このジレンマがスケジュールを圧迫します。

3つに共通するのは、いずれも「作業量が事前に読みにくい」という性質です。だからこそ、余裕のないスケジュールを組むより、後述する切替日の設計とあわせて遅延を織り込んだ計画にしておくことが重要になります。

切替日は業務カレンダーから逆算する

見落とされがちですが、マイグレーションの完了日は作業が終わった日ではなく、新システムへ切り替えられる日です。そして切替日は、自由には選べません。

本番切替の前後にはシステム停止や集中的な動作確認が必要になるため、切替は業務への影響が最も小さいタイミングを選ぶのが原則です。多くの企業では大型連休や月初月末を避けた閑散期などに限られ、決算期や繁忙期は最初から除外されます。つまり、切替できる日は業務カレンダー上の数少ない候補日に限られています。

このことが、スケジュール遅延の影響を増幅させます。作業の遅れが1か月でも、予定していた切替候補日を逃せば、次の候補日まで切替は動かせません。

移行計画を立てるときは、まず業務カレンダーから切替候補日を洗い出し、そこから逆算して各工程の期限を置いてください。そのうえで、切替リハーサルと予備の切替候補日をあらかじめ計画に入れておくと、遅延が起きても影響を最小限に抑えられます。

AIの活用で期間はどう変わるか

ここまでは人手を前提とした従来手法の話でした。生成AIの実用化により、この前提は大きく変わりつつあります。

AIで大きく縮むのは、期間の大半を占めていた3つの工程です。現行調査では、ドキュメントが残っていなくてもAIがソースコードから構造と仕様を読み取るため、調査の長期化を抑えられます。変換・実装では、移行先のフレームワークの規約に沿ってAIがコードを書き換えます。そしてテスト・検証では、AIが変換・検証・修正のループを自律的に繰り返して品質を作り込むため、最大の工程だったテスト期間を大幅に圧縮できます。仕組みの詳細はAIマイグレーションとは？仕組みと効果、導入前に知っておきたい注意点で解説しています。

一方で、AIを使っても縮まりにくい部分はあります。業務知識に基づく受け入れテスト、関係者との調整、そして切替日そのものです。切替候補日が業務カレンダーで決まる構図は、AIを使っても変わりません。AIの短縮効果は、作業期間の余裕が生まれることで狙った切替候補日を確実につかまえられるようになる、という形でスケジュールに効いてきます。

当社が手がけた約25万行の基幹システム移行では、レガシーなFuelPHPで構築されたシステムをPHP 8系とLaravel 12へ移行し、従来手法の見積もりと比較して金額・工期とも約60%の削減を実現しました。スケジュール面で特筆すべきは、既存システムの改修凍結期間を2週間に抑えられたことです。AIによる変換は繰り返し実行できるため、移行中の改修内容に移行作業を随時追従させられます。前述の「改修追従のジレンマ」を、仕組みで解消した形です。このプロジェクトの背景と進め方はFuelPHPからLaravelへの移行事例で紹介しています。

まとめ：期間の見積もりは「自社システムの状態」で決まる

規模別の目安は出発点にすぎず、実際の期間は、ドキュメントの有無やコードの複雑さといった自社システムの状態と、切替候補日の制約でほぼ決まります。検討の初期段階で概算の期間感をつかむには、実際のシステムに即した診断を受けるのが確実です。

DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、現状リスクと移行可能性をまとめた診断レポートと概算費用を無料でご提示しています。仕様書・設計書のご準備は不要です。

AIマイグレーションサービスの詳細はこちら

よくある質問

Q. 最短でどのくらいの期間で移行できますか？

規模と状態によりますが、AIを活用した移行では、小規模なシステムなら数か月以内に本番切替まで到達できるケースがあります。まず一部の機能でPoC(試行プロジェクト)を行い、品質を確認してから全体を進める段階的な方式でも、従来手法の一括移行より短く済むことが多くなっています。

Q. 移行期間中、既存システムの改修は止める必要がありますか？

長期間の凍結は不要なケースが多くなっています。AIによる変換は繰り返し実行できるため、既存システムの改修内容に移行作業を追従させられるからです。当社の基幹システム移行事例では、改修凍結期間を2週間に抑えました。

Q. 期間を正確に見積もるには何が必要ですか？

ステップ数などの規模に加えて、ドキュメントの有無、コードの複雑さ、連携システムの数、そして切替可能な時期の制約がわかると精度が上がります。当社の無料診断では、ソースコードの一部から現状を解析し、概算の費用とあわせて期間感をご提示しています。費用の相場観はシステムマイグレーションの費用相場もあわせてご覧ください。