基幹システムやERPの移行は、新システムにデータを取り込むだけの作業ではありません。業務手順、マスタ、帳票、外部連携、権限、運用、利用者への教育までを、業務を止めずに引き継ぐためのプロジェクトです。対象を早く絞り込みすぎると、テストや切替の直前に連携漏れ・権限不足・データ例外が見つかりやすくなります。
この記事では、移行範囲の決め方から方式選定、データ移行、計画書、切替判定、見積・検収、役割分担までを順に解説します。自社の制約に合う移行方式と、切替・発注の判断条件を整理できるようになります。
システム移行はデータ取込だけでなく、業務・連携・権限・運用・教育を含めて、調査から安定化まで一貫して管理します。
01Sectionシステム移行とは？最初に決める範囲と全体工程
システム移行とは、旧環境で行っていた業務を新環境へ安全に引き継ぐ活動です。新システムを利用できる状態にする「導入」、旧データを新環境で使える形にする「データ移行」、本番利用を旧環境から切り替える「切替」は、いずれも移行プロジェクトを構成する要素です。
計画・受入テスト・移行・引継ぎを段階的に管理する考え方は、デジタル・ガバメント推進標準ガイドラインでも示されています。民間企業にそのまま適用する義務はありませんが、移行計画と統制を考える際の実務上の参考になります。
導入・データ移行・切替を分けて、対象漏れを防ぐ
導入の設計だけを進めても、旧システムのデータをどこまで引き継ぐか、外部連携をいつ切り替えるか、利用者がどの権限で業務を行うかが未定義なら、移行は完了しません。対象・非対象・別施策として扱う領域を、業務責任者と情報システム部門が早期に決めます。
移行対象として確認する5つの領域
業務
受注、購買、在庫、会計、承認、締め処理など。新業務設計そのものは別施策に分ける場合もあります。
データ
マスタ、残高、履歴、添付ファイル、ログ、コード体系。移行・参照保管・アーカイブ候補に区分します。
連携・帳票
外部システム連携、認証、帳票、分析出力、再送・復旧手順を確認します。
権限・運用
利用者、職務分掌、監視、問合せ、障害対応、旧環境の扱いを確認します。
教育・定着
教育対象、手順書、初期支援、問合せ窓口を決めます。
現状調査から安定化までの流れ
標準的な流れは、現状調査、範囲・方式決定、移行設計、準備、テスト移行・リハーサル、本移行・切替、照合・安定化です。前工程で決めた対象範囲は、後工程のデータ量、テスト範囲、教育対象、見積条件に連動します。
ERP・基幹システム導入全体の工程は、基幹システム・ERP導入の進め方も参照してください。移行日から逆算した担当・期限管理は、プロジェクトのタイムライン作成の考え方を使うと整理しやすくなります。
02Section一括・段階・並行稼働はどう選ぶか
一括・段階・並行稼働は、停止枠だけでなく、整合性、運用体制、切戻し条件を満たせるかで選びます。
方式は「短期間で終えられそうか」だけで決めません。停止可能時間、分割後の整合性、旧新間の同期、並行運用の体制、切戻し可能性を同時に確認します。段階移行、並行稼働、切戻しを検討する観点は、標準ガイドライン研修資料も参考になります。
3方式を同じ条件で比較する
| 方式 | 適用条件 | 追加で必要な準備 | 避けるべき条件 | 再設計する条件 |
|---|---|---|---|---|
| 一括移行 | 停止枠内に抽出、変換、登録、照合、業務開始まで完了できる見込みがある | 本番相当のリハーサル、時刻入り手順、連絡網、切戻し条件 | 停止枠をリハーサルで再現できない、切戻し手順や判断者がない | 停止枠超過または切戻し不能が見込まれる |
| 段階移行 | 法人・拠点・業務・機能などで分けても、旧新間の整合を保てる | マスタ、残高、取引、連携の同期対象・頻度、正本データ、暫定運用 | 分割後の共有マスタや連携の整合を説明できない | 同期設計や対象境界を検証しても整合を保てない |
| 並行稼働 | 二重入力・照合の担当、対象、期限、業務上の基準となるデータを決められる | 差異承認、照合頻度、終了条件、追加要員と教育 | 通常業務と二重運用を両立する体制がない | 担当者・期限・正本データを確保できない |
方式は、停止枠、データ整合、運用体制、切戻しの条件をすべて満たせるかで選びます。段階移行は、切替の影響を分けられる一方で、旧新のどちらを正しいデータとして扱うかを決める必要があります。並行稼働も、照合担当と終了期限がなければ差異を増やすため、常に安全な方式とはいえません。
停止枠から候補を絞る判断フロー
移行方式を決める前の判断手順
- Step01
停止枠内に一括移行を完了できるか確認する
抽出、変換、登録、照合、業務開始までを、リハーサル結果で確認します。完了できる根拠があれば一括移行を候補に残し、なければ段階移行または並行稼働の条件を確認します。
- Step02
分割後の整合と同期を確認する
拠点・業務・機能を分けた後も、マスタ、残高、取引、連携の整合を保てるかを確認します。保てない場合は段階移行を保留し、同期設計または対象境界を先に検証します。
- Step03
並行運用の体制を確認する
二重入力・照合の担当者、対象範囲、期限、業務上の基準となるデータを確保できるかを確認します。確保できない場合は並行稼働を前提にせず、リハーサルと受入テストを厚くします。
- Step04
切戻し条件を確認する
旧環境を利用できるか、いつ誰が切戻しを決めるか、連絡先と手順があるかを確認します。これらが未確定なら、どの方式も確定しません。
- Step05
成立しない場合は計画を再設計する
一括は停止枠に収まらず、段階移行では整合を保てず、並行稼働の体制もない場合は、対象縮小、同期設計の先行検証、停止枠・切替日の再調整、導入順序の再設計を検討します。
ポイント
必要条件がそろわない場合は、3方式のいずれかを無理に選ばず、制約を解消してから再判定します。
03Sectionデータ移行は対象定義・品質確認・照合を台帳で追跡する
データ移行では、対象区分、品質課題、変換ルール、照合差異、承認をデータ単位で追跡します。
データ移行で重要なのは、取込件数ではなく、新環境で業務に使える状態を確認することです。データごとに対象、品質、変換、照合、承認を追跡し、業務責任者が例外を判断できるようにします。データ分析、クレンジング要否、移行設計、テスト、リハーサル、検証を管理する例は、データ移行・検証の要件定義例で確認できます。
移行・参照保管・アーカイブ候補を分ける
日常業務で使うデータは移行対象、旧環境で参照できればよいものは参照保管、日常利用はしないものの参照・監査・保存のために保管するものはアーカイブ候補として扱います。この区分を決めずに全件移行を前提にすると、データ整備や検証の範囲が必要以上に広がることがあります。
保存・廃棄はデータ単位で確認する
電子取引データ、個人情報、監査記録、契約情報などは、保存・廃棄の扱いを一律に決められません。対象データ、法令、契約、業界規制、社内規程を確認してください。電子取引データ等の要件確認先としては、国税庁「電子帳簿保存法の概要」があります。
品質確認と変換ルールを決める
データプロファイリングとは、件数、欠損、重複、形式、値の偏りなどを調べる現状調査です。この結果をもとに、重複排除、表記ゆれの統一、旧新コードの対応、欠損や例外の扱いを決めます。重複の統合は名寄せの進め方、欠損・表記ゆれの整備はデータクレンジングの基本、コード体系を含む定義はマスタデータ管理も参考になります。
件数だけでなく、重要残高や業務シナリオまで照合して受入を判断します。
データ移行を進める5つの実務フェーズ
- Step01
対象と現状を定義する
移行・参照保管・アーカイブ候補を区分し、対象期間、データ所有部門、件数、欠損、重複、旧コード、参照関係を把握します。
- Step02
品質基準と整備ルールを決める
許容できない欠損・重複・形式不備、クレンジング、名寄せ、手修正の範囲、例外の承認者を定義します。
- Step03
マッピング・変換を設計する
旧新の項目、コード、日付、桁数、必須項目の対応と変換ルールを記録します。
- Step04
テスト移行とリハーサルを行う
変換エラー、件数差異、性能、業務利用上の問題を確認し、本番に近いデータと手順で所要時間、連携、切戻し条件を検証します。
- Step05
本移行・照合・引継ぎを行う
承認済みの手順で進捗と例外を記録し、件数、重要残高、項目変換、重点サンプル、業務シナリオを照合します。残課題、問い合わせ先、監視、再処理、旧環境の参照方法を運用へ引き継ぎます。
データ移行台帳と照合観点の最小項目
- ✓
データ名、移行・参照保管・アーカイブ候補の区分、対象期間、所有部門を記録する
- ✓
欠損・重複・旧コードなどの品質課題と、クレンジング・変換ルールを記録する
- ✓
件数、重要残高、項目変換、重点サンプル、業務シナリオの照合方法を決める
- ✓
差異の説明、例外処理、受入の承認者をデータごとに明確にする
- ✓
保存・廃棄・参照方法について確認先と判断結果を残す
04Sectionシステム移行計画書は実行・承認・変更判断の基準にする
移行計画書は、単なる日程表ではありません。目的、対象、責任、前提、変更、完了条件をつなぎ、関係者が実行・承認・変更判断に使う上位文書です。小規模な案件でも、目的、範囲、担当、移行日、テスト、切戻し、完了条件は省略しないほうが安全です。
移行計画書の必須構成
目的・成功条件
背景、対象業務、移行完了と安定化の定義を記載します。
範囲・前提・依存関係
対象・非対象、旧環境、連携先条件、未確定事項と決定期限を管理します。
方式・体制・工程
方式の選定理由、責任者、連絡経路、工程、WBSを記載します。
データ・テスト・受入
データ品質、変換、照合、必須シナリオ、受入基準と承認者を記載します。
切替・切戻し・リスク・完了条件
停止枠、当日手順、判定条件、残課題、引継ぎ、完了判断を記載します。
WBSは、作業を担当者・期限ごとに分解した計画表です。移行計画書が「何を、なぜ、誰が判断するか」を扱うのに対し、WBSは実行作業、データ移行台帳はデータ単位の品質・承認、テスト計画書は検証範囲、切替手順書は当日の時刻入り作業、リスク台帳は問題の予防・対応を扱います。
リハーサル後は、所要時間、未解決の差異、連絡網、切戻し開始条件、暫定運用を更新し、切替可否の判断者が確認します。変更が出た場合は、影響範囲、代替案、決定者、決定期限を計画書と関連台帳で追跡します。
05Section失敗を防ぐリスクレビューとGo／No-Go判定
切替判定は数値だけでなく、業務影響、暫定策、承認、切戻し可能性を組み合わせて行います。
リスクレビューと切替判定は、目的が異なります。リスクレビューは切替前に予防・早期検知・責任者への報告を行うためのものです。Go／No-Go判定は、切替時点で証跡と承認に基づき開始・条件付き開始・延期または切戻しを決めるためのものです。
工程横断で確認する6つのリスク領域
| 領域 | 失敗パターン・早期兆候 | 業務影響 | 予防・検知と対応・報告先 | 確認時点・責任者 |
|---|---|---|---|---|
| 計画 | 対象・責任が未確定、変更が口頭のみ | 手戻り、受入不能 | 範囲・前提・決定者を記録し、変更は責任者へ判断依頼 | 要件確定・変更時／プロジェクト責任者 |
| データ | 重複・欠損・旧コードが直前に判明、差異理由が未分類 | 残高不整合、検索不能 | 台帳、品質ルール、テスト移行で検知し、例外承認を依頼 | 調査・テスト・リハーサル／データ所有者 |
| 連携 | 未試験の連携、再送手順や監視がない | 受注・請求・在庫等の停止 | 連携一覧、異常系試験、再送・復旧手順を確認し、連携先へ報告 | 設計・連携試験・当日／情報システム責任者 |
| テスト | 必須シナリオ未実施、証跡不足、重大不具合の期限未定 | 利用開始後の業務停止 | 受入基準と再試験計画を記録し、重大度を判定会議へ報告 | 受入テスト完了時／受入責任者 |
| 切替 | 停止枠超過、手順漏れ、切戻し未試験 | 業務停止、復旧遅延 | 本番相当リハーサル、時刻入り手順、連絡網を確認し、決裁者へ報告 | リハーサル・当日／切替責任者 |
| 定着 | 教育漏れ、窓口未定、旧環境依存 | 誤入力、処理遅延 | 教育対象、手順書、問合せ窓口、残課題を管理 | 切替前・初期運用／業務・運用責任者 |
ポイント
リスクレビューは未解決事項を早く減らすための管理、Go／No-Goは切替時点の意思決定と記録です。用途を混同しないことが重要です。
Go／条件付きGo／No-Goを分ける
許容差を一律の数値だけで決めるのではなく、差異の説明可能性、業務影響、承認、暫定策、停止枠、切戻し可能性を組み合わせて判断します。
| 判定観点 | Go | 条件付きGo | No-Go | 必要な証跡・承認 |
|---|---|---|---|---|
| 差異の説明 | 件数・除外・エラー・差異を説明でき、業務影響がない | 残差異が限定的で、暫定策・責任者・期限・再判定時刻がある | 重要差異を説明できず、暫定策でも業務影響を抑えられない | 差異台帳、データ所有者・業務責任者の承認 |
| 重要残高・重要データ | 調整根拠と必要承認が完了している | 限定的な調整の責任者、期限、影響、承認を記録している | 調整・承認が未完了で影響を管理できない | 残高・明細照合、調整記録 |
| 必須シナリオ | 必須業務、主要連携、必要権限を確認済み | 限定業務に代替手順、対象者、支援窓口、期限がある | 業務継続に必要なシナリオ・連携・権限が未完了 | テスト結果、受入責任者の承認 |
| 重大障害 | 業務継続、法令、契約、セキュリティに影響する未解決障害がない | 検証済み暫定策と監視、責任者、解消期限がある | 重大な未解決障害がある | 障害一覧、影響評価、暫定策の記録 |
| 停止枠・切戻し | 停止枠内の完了見込みと切戻し手順・判断者が確認済み | 短縮策、監視点、延長判断者、切戻し開始時刻がある | 停止枠超過見込み、または切戻しの前提がない | リハーサル結果、手順書、連絡網 |
| 判断者・記録 | 必要な責任者が参加し、理由を記録する | 例外承認者も条件を承認する | 延期・切戻し・連絡開始の決裁者が承認する | 会議記録、承認時刻、連絡対象 |
条件付きGo・No-Goで残すべき記録
- ✓
条件付きGoでは、残課題、暫定策、業務影響、解消責任者、解消期限、再判定時刻、必要承認を記録する
- ✓
暫定策が実行できる担当者・対象者・支援窓口を明確にする
- ✓
No-Goでは、延期または切戻し、旧環境の利用可否、データ更新の扱いを記録する
- ✓
連絡開始者、連絡順、連絡対象を決める
- ✓
次回再判定に必要な検証項目、責任者、期限を課題として登録する
切替当日の進行、連絡、切戻し手順をさらに具体化する際は、カットオーバーの進め方を参照してください。
06Section見積・検収では金額より先に比較条件をそろえる
移行費は、対象範囲、データ品質、連携要件、移行方式、支援範囲で変わります。条件が異なる見積金額を横並びにすると、どこまでが移行作業に含まれるかを誤解しやすくなります。まず費用構造と発注者側の作業を分け、同じ前提で比較します。
作業分解、規模、類似実績、変動要因を踏まえる見積の考え方は、IPAの見積もり手法が参考になります。ただし、対象範囲や支援内容がそろわない案件に共通の金額・期間を当てはめることはできません。
費用構造を分ける
概算依頼の前に、移行に関わる作業を費用層ごとに分解します。各層について、見積依頼対象、自社負担、未確定のいずれかを記録してください。同じ前提がそろうまで、金額だけで比較しないでください。
概算前提として分ける5つの費用層
調査・計画
現状調査、対象範囲の整理、移行方式の検討、計画書作成を分けます。計画作成支援を見積依頼するか、自社で判断・作成するかを分類します。
データ整備・変換
データプロファイリング、クレンジング、名寄せ、変換設計、手修正、例外承認を分けます。業務判断が必要な整備作業は自社負担となる場合があるため、未確定の担当を残さないようにします。
連携・帳票・テスト
外部連携、認証、帳票、分析出力、連携先調整、テスト移行、受入テスト、不具合修正・再試験、本番相当リハーサルを分けます。連携先の対応範囲やテスト回数が未定なら、見積比較前に明示します。
切替・安定化支援
切替当日の立会い、夜間・休日対応、障害対応、切戻し支援、初期運用の支援を分けます。支援時間帯と安定化期間は、見積対象か未確定かを明記します。
新システム関連費と発注者側工数
ライセンス・利用料、導入設定、環境準備は移行作業とは別に管理します。データ確認、例外承認、連携先調整、受入、教育、Go／No-Go判断に必要な社内工数も、外部見積に含まれない負担として別に分類します。
概算前提を固定する
まず5つの費用層ごとに、対象作業、担当、前提条件を記入し、「見積依頼対象」「自社負担」「未確定」に分類します。次に未確定の項目には確認担当者と期限を置き、見積依頼書に対象・除外・変更時の扱いを明記します。これにより、金額差が作業範囲の差なのか、支援時間帯や受入条件の差なのかを確認しやすくなります。
概算前提と見積比較でそろえる項目
移行対象と除外範囲
対象システム、業務、データ区分・期間、旧環境の保管、対象外の業務を固定します。
データ整備・変換の担当
クレンジング、名寄せ、手修正、例外承認を誰が担うかを明確にします。
連携・帳票・テスト・リハーサル
連携先調整、再試験、テスト回数、本番相当リハーサルの範囲を確認します。
切替・安定化支援と成果物
夜間休日の立会い、障害対応、切戻し支援、計画書・手順書・照合結果などを確認します。
受入基準・変更管理・発注者側作業
検収条件、追加変更時の扱い、データ確認、受入、教育、承認に必要な社内工数を分けます。
成果物・受入基準・変更管理を比較する
検収では、作業を実施したことだけでなく、何を成果物とし、どの受入基準を満たせば完了とするかを発注前に合意します。たとえば、移行計画書、変換仕様、テスト結果、照合結果、切替・切戻し手順、残課題一覧の提出有無と承認者を確認します。
見積・検収で確認する比較条件
- ✓
移行対象・対象期間・添付・履歴・マスタ・連携と、除外範囲が同じ条件か確認する
- ✓
データ整備、例外処理、手修正、連携先調整を誰が担当するか確認する
- ✓
テスト・リハーサルの回数、範囲、不具合修正・再試験の扱いを確認する
- ✓
切替支援の時間帯、障害時の対応、切戻し支援、安定化期間を確認する
- ✓
成果物、受入基準、変更時の承認手順、日程・費用への影響、発注者側作業を確認する
仕様、成果物、受入、変更管理の確認観点は、デジタル庁の調達手続マニュアル・雛形等も参照できます。民間契約では自社の契約条件に合わせて具体化してください。
07Section自社と外部支援の役割分担を決める
外部の技術支援を利用しても、業務上の正しさを決める責任は自社からなくなりません。業務部門、情報システム部門、プロジェクト責任者、外部支援者の間で、実行者だけでなく承認者と判断時点を明確にします。
自社に残す判断と、外部支援を検討する作業
自社側では、業務ルールの優先順位、データ定義、名寄せ・例外処理の承認、受入判定、Go／No-Goの最終判断を保持します。一方で、現状調査、変換設計、移行ツール設定、連携試験の運営、切替当日の進行、初期安定化は、専門性や稼働時間が不足する場合に外部支援を検討しやすい作業です。
個人データを委託先が扱う場合は、委託先の選定、契約、安全管理、取扱状況の把握、再委託の確認を行います。個人情報保護委員会のガイドライン（通則編）および委託先を監督してますか？を確認し、契約上の責任分界と運用を整えてください。
体制不足には3つの選択肢で対応する
工程ごとに、業務責任者、データ例外の承認者、連携先調整担当、受入責任者、切替当日の決裁者と対応要員を指名します。いずれかが不足する場合は、次のいずれかを明確にします。
- 不足する技術・運営作業を外部支援の依頼範囲として定義する
- 対象業務、データ、連携、利用者を縮小または分割する
- 受入・切替の日程を再設定し、レビューとリハーサルの時間を確保する
依頼前に自社で整理する情報
対象システム・業務・データ・連携
対象・非対象、データ区分、連携先、旧環境の扱いを整理します。
停止可能時間と方式候補
繁忙期、停止枠、一括・段階・並行稼働の成立条件を整理します。
データ品質課題と未確定事項
重複・欠損・旧コード・保存要件と、確認期限・担当者を整理します。
受入責任者と切戻しの決裁者
必須シナリオの確認者、Go／No-Go判断者、連絡網を整理します。
不足する役割・稼働時間・支援希望範囲
調査、変換、連携、テスト、切替、安定化のどこで不足するかを整理します。
システム移行でよくある質問
データを新システムに取り込めば、システム移行は完了ですか？+
データ取込は一工程です。業務シナリオ、連携、帳票、権限、利用者教育、運用引継ぎ、照合と受入まで確認して、初めて業務を引き継げたと判断できます。
段階移行なら一括移行より安全ですか？+
一概にはいえません。段階移行では旧新間のマスタ、残高、取引、連携の同期と、どちらを業務上の基準となるデータにするかを管理する必要があります。分割後の整合を保てない場合は、かえってリスクが高まります。
Go／No-Goの許容差は、あらかじめ数値で決めるべきですか？+
数値だけで決めるのではなく、差異を説明できるか、重要データの承認があるか、必須業務を実行できるか、重大障害がないか、停止枠と切戻し条件を満たすかを組み合わせて判断します。
外部支援を利用しても、自社側で決めるべきことは何ですか？+
業務上の正しさ、データ例外の承認、優先順位、受入判定、Go／No-Goの最終判断は自社側で明確にします。外部支援には、成果物、責任分界、受入基準、変更時の扱いを具体的に示します。
判断を次の合意につなげる
移行範囲、方式、データ照合、Go／No-Go、見積条件、役割分担は、それぞれを別々に決めるのではなく、移行計画書と関連台帳でつなげて追跡します。未確定事項には担当者と決定期限を置き、方式の成立条件、受入基準、発注条件を合意してから次の工程へ進めます。
core-system-erp-selection
この記事カードはサンプル表示です。CMS連携後は記事タイトル、概要、サムネイルなどを記事データから取得します。
関連記事
ERP導入・移行の支援先を比較する
移行対象、停止可能時間、連携要件、データ品質課題、必要な支援範囲を整理したうえで、ERP導入・移行を支援できる会社を比較できます。
ERP導入564社掲載
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。
