システム移行とは？計画書の10項目と旧システムを止める条件

移行計画書を作る方は「移行計画書には何を書くのか」と空欄テンプレートの章、旧システムを止める時期を決めたい方は「旧システムはいつ止めてよいのか」の章をご覧ください。

システム移行とは何か｜データ移行・リプレイスとの違い

システム移行とは、今のシステムで行っている業務と、そこに保存しているデータを新しいシステムへ引き継ぎ、新しいシステムで業務を行えるようにする作業です。引き継ぐものは、3つに分けると整理しやすくなります。取引先や品目、過去の取引などのデータ、受注から請求までの処理と手順、他のシステムや取引先とのデータのやり取りです。データ移行は、このうちデータを引き継ぐ作業を指します。リプレイス（入れ替え）は今のシステムを別のシステムに置き換えることで、システム移行はその置き換えを実際に進める工程にあたります。

同じ「移行」でも、何を変えるかによって業務への影響は違います。

以下で主に扱うのは、業務の手順も変わるパッケージへの入れ替えと、個別開発への入れ替えです。今のシステムを残すか作り直すかの判断と、作り方ごとの違いは、基幹システムの再構築の進め方で解説しています。

移行方式はどう選ぶのか｜一括・段階・並行・パイロット

移行方式は、業務を止められる時間、業務や拠点を分けて移せるか、新旧のシステムを同時に動かす手間をかけられるかで選びます。方式によって、旧システムを残す期間の目安も変わります。

表の期間は目安です。実際に止める日は、移したデータの検証の結果、業務が落ち着いたか、過去のデータをどう保存するかを確かめて決めます。方式は組み合わせられます。たとえば、在庫管理は拠点ごとに順番に移し、請求額は新旧の両方で計算して結果を比べる、という形です。両方を動かす間も、取引先への請求書の発行や発注は、どちらか一方のシステムだけから行います。両方から出すと、二重請求や二重発注につながるおそれがあります。方式ごとの注意点は、再構築の記事の「移行方式はどう選ぶのか」で詳しく比べています。

システム移行はどの順番で進めるのか

一般社団法人日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」（2025年度調査）では、システム開発の工期が予定より遅れた企業297社に要因を聞いています（複数回答）。上位は「計画時の考慮不足」52.5%と「想定以上の現行業務・システムの複雑さ」48.8%でした（図表7-1-8）。工期が遅れた要因の工程として「運用準備・移行」を挙げた企業も21.3%ありました（図表7-1-9、174社）。どちらもシステム開発全体の数字ですが、移行でも、今の業務の例外的な処理と他のシステムとのやり取りを最初に調べ、必要な作業を洗い出してから日程を決めます。

開発会社が出す工程表が、本番の切り替えで終わっていることがあります。工程表、切り替え後の支援の計画、契約書のどこかに、旧システムを止めるまでの作業と担当、期間が書かれているかを、見積もりの段階で確かめてください。要件定義や開発も含めて日程を組むときは、システム開発のスケジュールの決まり方を参考にしてください。

移行計画書には何を書くのか｜10項目と記入例

移行計画書は、何を、いつ、誰が、どの手順で移すかと、うまくいかなかったときの扱いを決めた文書です。基幹システムの移行計画書に書く項目を、次の10項目に整理しました。記入例は、製造業で受注、在庫、生産の仕組みを入れ替える場合を想定したものです。

7の移行判定の基準、8の戻す手順、10の旧システムを止める条件は、どれも使うのが本番の直前か切り替えの後です。それでも計画の段階で決めておきます。決めていないと、切り替えの当日にその場で判断することになり、旧システムの費用をいつまで払うかも決まりません。

移行計画書はどんな書式で作ればよいか｜空欄テンプレート

移行計画書は、上の10項目を行にして、決めたこと、取りまとめ担当、決める期限、状態、承認者を書き込める表にします。状態の欄を「未着手・検討中・承認待ち・承認済み」の4つで書くと、まだ決まっていない項目と、承認を待っている項目を見分けやすくなります。次の空欄テンプレートは、表計算ソフトや文書に写して使えます。灰色の文字は記入の目安なので、自社の内容に置き換えてください。表の上には、システム名、対象の拠点と業務、版と最終更新日を書きます。

【移行計画書】
システム名：
対象の拠点と業務：
版：　　　最終更新日：
作成者：　　　承認者：

1. 移行の対象
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

2. 移行方式
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

3. 日程
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

4. 体制と役割
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

5. データの扱い
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

6. リハーサル
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

7. 移行判定の基準
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

8. 旧システムへ戻す手順
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

9. 切り替え後の支援
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

10. 旧システムを止める条件
　決めたこと：
　取りまとめ担当：　　　決める期限：
　状態（未着手／検討中／承認待ち／承認済み）：
　承認者・承認日：

週に1回の打ち合わせでは、状態が「承認済み」になっていない項目と、決める期限を過ぎても決まっていない項目を確かめます。7・8・10の行が決まらないまま、リハーサルの日を迎えないようにします。

移行リハーサルでは何を確かめるのか

リハーサルでは、本番で作業する担当者が実際の手順に沿って、本番に近い量のデータを移します。回数は規模によって変わりますが、本番と同じ手順で最後まで通す回を少なくとも1回入れます。手順書の読み合わせだけでは、作業が何時間かかるかも、誰がどこで手を止めるかも分かりません。

リハーサルで記録するのは、作業にかかった時間、新旧のデータを比べた結果、手順書どおりに進まなかった箇所の3つです。時間は、切り替えに使える休日の枠に、予備を残して収まるかを見ます。新旧のデータは同じ時点の数字で比べます。件数と合計金額に加え、在庫は品目、拠点、ロット（同じ条件で作った製品のまとまり）ごとに、売掛金（まだ回収していない売上）は取引先ごとに比べます。合計だけを比べると、品目ごとの過不足が打ち消し合って、差に気づけません。

現場の機器と操作も、このときに確かめます。現場の担当者がハンディ端末で品物のバーコードを読み取り、ラベルプリンターでラベルを印刷します。次の工程でそのラベルを読み取り、処理を続けられるところまで確かめます。新システムを使う担当者は、勤務の時間帯ごとに、自分の仕事を一通り新システムで処理してみます。旧システムへ戻す手順も、リハーサルの中で一度試しておきます。本番で初めて使うと、手順書の不備にそこで気づくおそれがあります。

本番に切り替えてよいかはどう判定するのか｜移行判定の基準

切り替えの当日に判断がぶれないよう、判定の日時と責任者、延期する基準を移行計画書で決めておきます。判定の日には、責任者がリハーサルの結果と現場の準備の状況を、計画書の基準に照らして確かめます。

判定は、切り替えの作業を始める前と、業務を始める前の2回行います。下の工程表の例では、金曜18時に停止と取り出しの作業を始めてよいかを、日曜15時に新システムで業務を始めてよいかを判定します。業務を始めた後の火曜正午には、続けるか戻すかを判断します。2回目の判定では、本番で移したデータを新旧で比べ、データを取り出した後に入った取引（差分）が反映されていることを確かめてから、責任者が業務の開始を承認します。

基準を満たさなかったときは延期します。延期した場合の次の切り替え日の候補も、計画の段階で押さえておきます。候補がないと延期しにくくなり、基準を満たさないまま切り替える判断に傾きます。

旧システムへ戻せる期限を決めても、期限内なら必ず戻せるわけではありません。切り替えた後に新システムで登録した受注や在庫の動きを旧システムへ移す方法と、すでに送った発注や出荷の指示の扱いが決まっていて、初めて戻せます。

切り替え当日は何をどの順番で進めるのか｜時刻別の工程表

切り替えの当日は、作業を時刻ごとに並べた工程表を作り、作業ごとに担当と完了の条件を決めておきます。次の表は、土日と祝日の月曜を使って切り替え、火曜から新システムで業務を始める場合の例です。判断する人と作業する人は分けて書いています。移行計画書の記入例（金曜18時の判定、業務を始めた日の正午を戻すかの期限にする）に合わせました。

出荷の指示を正午の判断の後に出すのは、出荷の指示を出した後は旧システムへ戻さないと決めているためです。記入例の2で、請求額を新旧の両方で計算して比べるのは、火曜から新システムを正式な記録にしたうえで、比べるのに必要な取引だけを旧システムにも入力する形です。旧システムから請求書は出しません。

時刻は例で、データの量とリハーサルで測った時間に合わせて決めます。実際の工程表には、作業ごとの終了予定と実績、遅れたときの連絡先の欄も足し、どこまで遅れたら次の判断に進むかを決めておきます。

旧システムはいつ止めてよいのか｜完全移行までの期間と条件

旧システムへの入力をやめた後も、照合や過去のデータの参照のために、旧システムを残すことがあります。旧システムを残す期間が、そのまま二重入力の期間になるわけではありません。入力、比較、参照を終える時期を分けて決めると、経理や現場の負担と、旧システムの維持にかかる費用を別々に見積もれます。

この記事では、3つ目まで終えて新システムだけで業務を回せる状態を「完全移行」と呼びます。弊社では、基幹システムを全体的に入れ替える案件で、開発が終わってから完全移行までに1年ほどを見込んでいます。決算など年に1度の処理と、その会社が定期的に行う棚卸や単価の改定まで、新システムで一度確かめてから止めるためです。

止める前に確かめる条件の例を挙げます。どの条件を置くかは、会社ごとに移行計画書で決めます。

最後の条件には、法令の保存期間が関わります。法人税では、法人は帳簿と取引に関する書類を、その事業年度の確定申告書の提出期限の翌日から7年間保存しなければなりません。青色申告書を提出して税務上の赤字（欠損金額）が生じた事業年度などは10年間で、そうした事業年度が平成30年4月1日より前に始まった場合は9年間です（国税庁「No.5930 帳簿書類等の保存期間」、令和8年4月1日現在法令等）。株式会社は、会社法でも、会計帳簿と事業に関する重要な資料を、帳簿を閉じた時から10年間保存しなければなりません（会社法第432条第2項）。

保存の方法にも決まりがあります。令和6年1月1日以後に電子でやり取りした請求書などのデータは、紙に印刷するだけでは足りず、電子帳簿保存法のルールに沿ってデータのまま保存する必要があります。一定の条件で保存の要件をゆるめる措置もありますが、その場合もデータ自体は保存します（国税庁「電子帳簿保存」）。直近の数年分だけを新システムに移す場合は、それより前のデータを取り出して保管するか、参照だけできる環境を残すかを決め、必要なときに検索して画面や紙に出せるかを確かめます。保存の方法が要件を満たすかは、顧問の税理士にも確かめてください。

旧システムの保守や利用の費用は、止める日までかかります。契約によっては、旧システムを止めた後も、最低利用期間が終わるまで料金がかかります。見積もりを比べるときは、開発費に加えて、完全移行までの旧システムの費用と、参照用の環境を残す費用も入れて比べます。作り方ごとの費用の比べ方は基幹システムの費用相場で整理しています。保守の期限から逆算して要件定義をいつ始めればよいかは、再構築の記事の「開発が終わってから完全移行まで、どのくらいかかるのか」で説明しています。

弊社に頼むと、移行はどう進むのか

要件定義の1〜2か月は、お客様に今の業務をご説明いただき、必要な機能をご確認いただきます。その内容をもとに、弊社が原則としてフルスクラッチ（既製品を使わず、必要な機能を一から作る方法）で開発します。全体を作り直す場合、開発が終わるまでに半年から1年、そこから完全移行までにさらに1年ほどが目安です。替える範囲と移行の条件によって変わります。受入テスト（完成したシステムが依頼した条件を満たすかをお客様が確かめる試験）、移したデータの確認、操作の練習には、お客様の担当者に入っていただきます。開発するシステムの画面と操作は、登録なしで試せる基幹システムの体験デモで確かめられます。

完成したシステムとデータはお客様のものです。完成後の伴走支援もご相談いただけます。開発の費用は、替える範囲に応じて個別にお見積もりします。

よくある質問

登壇・セミナー実績

開催レポートを読む →

開催レポートを読む →

神戸商工会議所・石川県庁など、各地の商工会議所や自治体でAI活用セミナーに登壇しています。現場で得た知見をもとに、上場企業を含むさまざまな規模の会社のAI導入を支援しています。