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

サーバーの契約更新やOSのサポート終了で、移行の期限が先に決まっていることは少なくありません。その場合に知りたいのは、移行に何か月かかるかよりも、期限までに新システムへ切り替えられるかどうかです。

間に合うかどうかは、作業の量だけでは決まりません。作業の量は規模と工程の比重からおおよそ見積もれますが、新システムへ切り替えられる日は業務カレンダーの都合で限られていて、作業が1か月遅れただけで切替が数か月先に延びることがあります。

規模別の期間の目安

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

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

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

工程ごとの期間の内訳

マイグレーションの工程は大きく4つに分かれ、期間の比重はおおよそ次のようになります。

期間がいちばん長いのは、プログラムの書き換えではなくテスト・検証です。マイグレーションは「移行前とまったく同じように動くこと」がゴールなので、画面や帳票、バッチ処理の一つひとつについて新旧の動作を突き合わせます。月末の締め処理や年次の処理のように、特定の日付やデータがそろわないと動かない処理は、その条件を再現したテストデータを用意してから確かめることになり、ここにも時間がかかります。

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

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

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

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

テストでの手戻り：
新旧の動作を突き合わせて差異が見つかれば、修正して再テストすることになります。長年の改修で複雑になったコードほど、1か所の修正が別の箇所に影響し、修正と再テストの往復が増えます。

移行中の機能改修への追従：
移行期間中も業務は止まらないため、現行システムには改修が入り続けます。改修を凍結すれば業務側でお待ちいただくことになり、変更を移行側に取り込み続ければ移行作業が増えます。移行期間が長いほど、どちらを選んでも負担は重くなります。

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

切替日の決め方

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

本番切替では、システムを止めて現行のデータを新システムへ移し、新システムで業務が回ることを確かめます。問題が見つかれば旧システムへ戻す切り戻しも判断しなければならず、ここまでを業務を止めてよい時間の中に収める必要があります。そのため多くの企業では、切替の時期は大型連休や月初月末を避けた閑散期などに限られ、決算期や繁忙期は最初から除外されます。切り替えを実施できる日は、業務カレンダー上の数少ない候補日に限られます。

候補日がこれだけ限られていると、作業の遅れが1か月であっても、予定していた切替候補日を逃せば次の候補日まで切り替えられません。

移行計画を立てるときは、まず業務カレンダーから切替候補日を洗い出し、そこから逆算して各工程の期限を置いてください。切替リハーサルでは、本番と同じ量のデータで移行にかかる時間を測り、切り戻しの判断まで停止できる時間内に収まるかを確かめておきます。予備の切替候補日も最初から計画に入れておけば、遅れが出たときに次の候補日を探し直さずに済みます。

AI活用による期間の変化

AIを使うと、期間の大半を占めていた現行調査、変換・実装、テスト・検証の3工程が縮みます。

現行調査は、ドキュメントが残っていなくてもAIがソースコードから構造と仕様を読み取るため、長引きにくくなります。変換・実装では、移行先のフレームワークの規約に沿ってAIがコードを書き換えます。最も長かったテスト・検証も、AIが変換・検証・修正のループを自律的に繰り返して新旧の差異を解消していくので、期間の4〜5割を占めていた部分が短くなります。仕組みの詳細はAIマイグレーションとは？仕組みと効果、導入前に知っておきたい注意点で解説しています。

一方で、AIを使っても縮まりにくい部分があります。業務知識に基づく受け入れテストと関係者との調整、そして切替日そのものです。切替候補日が業務カレンダーで決まる構図は、AIを使っても変わりません。工期が縮んだ分は、狙った切替候補日に間に合わせるための余裕として使えます。

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

移行期間中の改修凍結

人手による従来の移行では、「移行中は現行システムの改修を止めてほしい」とベンダーから求められるのが一般的でした。解析した時点のコードを基準に書き換えを進めるため、途中で現行側に変更が入ると、変更箇所の特定と影響範囲の再調査に加えて、書き換え済みのコードの修正とテストのやり直しが必要になるからです。人手でこの追従を続けるより、凍結をお願いするほうが工数を抑えられました。

ただ、移行が年単位なら凍結もそのまま年単位になります。その間に法改正への対応や取引先からの要請、現場の改善要望がたまり、切替直後に改修が集中します。凍結しきれずに改修を入れれば、今度は移行側との差分が積み上がり、切替時の反映漏れの原因になります。

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

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

まとめ

期限が決まっている移行の計画は、切替候補日の洗い出しから始まります。候補日から逆算して、期間の4〜5割にあたるテスト・検証を確保できるかを確かめてください。確保できない場合に検討するのは、移行方式の見直しか、AIの活用で調査・変換・テストの期間を縮めることです。

移行中に予定している改修があれば、凍結がいつから、どのくらいの期間必要になるかも、見積もりの段階でベンダーに確認しておくと、業務側の改修予定と突き合わせられます。

DEN-NOのAIマイグレーションサービスでは、NDA(秘密保持契約)を締結のうえでシステム概要とソースコードの一部をお預かりし、無料診断で現状リスクと移行可能性を解析して、概算費用とあわせて期間感をご提示します。切替を希望される時期やサーバー契約の更新時期が決まっていれば、あわせてお知らせください。その時期から逆算した見通しをお伝えします。仕様書・設計書がお手元になくてもご相談いただけます。

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

よくある質問

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

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

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

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

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

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