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

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

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

規模別の期間の目安

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

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

規模が大きいほど計画どおりに終わりにくい傾向は、業界の統計にも出ています。JUASの企業IT動向調査2025によると、2024年度にシステム開発の工期が「予定より遅延」したプロジェクトの割合は、100人月未満で16.6%、100〜500人月未満で33.8%、500人月以上で43.7%でした。東証上場企業とそれに準じる企業981社の回答です。

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

工程ごとの期間の内訳

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

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

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

スケジュールが延びる要因

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

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

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

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

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

JUASの企業IT動向調査2025でも、工期が予定より遅れた266社が挙げた要因の上位2項目は「計画時の考慮不足」47.7%と「想定以上の現行業務・システムの複雑さ」44.4%でした。

切替日の決め方

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

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

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

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

AI活用による期間の変化

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

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

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

当社が手がけた約25万行の基幹システム移行では、レガシーなFuelPHPで構築されたシステムをPHP 8系とLaravel 12へ移行し、従来手法の見積もりと比較して金額・工期とも約60%の削減を実現しました。このプロジェクトの背景と進め方はFuelPHPからLaravelへの移行事例で紹介しています。

移行期間中の改修凍結

人手による従来の移行では、「移行中は現行システムの改修を止めてほしい」とベンダーから求められるのが普通でした。解析した時点のコードを基準として書き換えを進めるため、途中で現行側に変更が入ると、変更箇所の特定と影響範囲の再調査に加えて、書き換え済みのコードの修正とテストの再実施が必要になります。人手でこの追従を続ける工数は大きく、凍結をお願いするほうが現実的だったからです。ただ、移行が年単位なら凍結もそのまま年単位になります。その間、法改正への対応や取引先からの要請、現場の改善要望は蓄積される一方で、切替直後にそれらの改修が集中します。凍結しきれずに改修を入れれば、今度は移行側との差分が積み上がり、切替時の反映漏れの原因になります。

当社の進め方では、移行期間全体にわたって改修を止めていただく必要はありません。AIによる解析と変換は繰り返し実行できるため、現行側に改修が入るたびに変更履歴を把握し、影響範囲を再解析して移行先へ反映します。凍結が必要になるのは本番切替の直前です。現行側の最後の変更を移行先に反映し、最終差分を確定して新旧比較を終えるために、短い凍結期間を設ける場合があります。

前述のFuelPHPからLaravelへの基幹システム移行では、改修凍結期間は2週間でした。移行期間中も既存システムの改修は続き、その内容に移行作業が随時追従しています。凍結が2週間で済むのであれば、改修の予定を移行スケジュールに合わせて調整する負担は小さく、切替候補日の直前に凍結期間を設ける計画も立てやすくなります。移行中の改修の扱いはよくあるご質問でもお答えしています。

まとめ

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

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

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

よくある質問

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

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

Q. 改修を凍結する期間は、どのくらい必要ですか？

本番切替の直前に、最終差分を確定するために設ける短い期間のみです。当社の基幹システム移行事例では2週間でした。移行期間中の改修をどう扱うかは、本文の「移行期間中の改修凍結」の節で解説しています。

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

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