システムのデータ移行では、旧環境のデータを新環境へコピーするだけでなく、意味や関連性が保たれ、必要な業務を続けられることを確認します。件数が一致していても、顧客と契約の対応がずれたり、金額や状態の意味が変わったりしていれば、移行は成功とはいえません。
進める順番は、移行対象と正本の決定、データ調査、変換ルール、テスト、切替条件、切り戻しの確認です。本記事では、業務システムやWebシステムを更新する企業の担当者向けに、移行作業を依頼する前に決める事項と、結果を確認する方法を整理します。
データ移行の全体像を先に押さえる
移行は「コピーして終わり」ではなく、何を移すか決める→旧項目と新項目を対応付ける→試験移行する→数字と業務で照合する→切替を承認するという順に進めます。作業担当者だけで切替可否を決めず、受注や請求など実際に使う部署の確認を入れます。
1. 移すデータと残すデータを分ける
最初に、日常業務で使うデータ、履歴として参照するデータ、保管だけが必要なデータを分けます。すべてを同じ形式で新システムへ移す必要があるかを確認してください。
- 顧客、商品、取引先、担当者等のマスター
- 進行中の案件、注文、契約、申請
- 完了した取引と変更履歴
- 添付ファイル、画像、帳票、出力済み資料
- 権限や設定、外部サービスとの対応情報
保存期間や削除の可否は、社内方針、契約、適用される法令等を所管担当者へ確認します。古いという理由だけで削除せず、逆に重複や不要な一時データを無条件に持ち込まないようにします。対象外にしたデータも、保管場所と参照方法を記録します。
2. 正本と識別番号を決める
複数システムに同じ情報がある場合は、どれを正本として移すかを決めます。担当部署によって値が異なる場合、移行担当者が推測で選ばず、業務責任者が優先ルールを決定します。
新旧で識別番号が変わる場合は対応表が必要です。顧客IDを変えたら、その顧客の注文、請求、添付ファイルなども正しく結び直します。新しいIDを発行できたことと、関連データの整合が取れたことは分けて確認します。
外部サービスや取引先が旧IDを使う場合は、旧IDを保持するか、変換するか、相手側の変更が必要かを検討します。システム内部だけで完結すると思っていた番号が、帳票や問い合わせ対応に使われていないかも確認してください。
例：顧客IDを変えるなら受注の参照先も変える
架空の受注管理システムを考えます。旧システムの顧客ID「C001」を新システムで「501」にする場合、顧客表だけを変えると、受注表が参照する「C001」は新しい顧客を指せません。旧IDと新IDの対応表を用意し、受注・請求・添付ファイルの参照先まで変換して照合します。
この対応表には、旧ID・新ID・変換結果・例外理由を残します。IDの重複や参照先不在があれば自動で成功扱いにせず、対象レコードを確認待ちへ分けてください。
3. 現行データの品質を調べる
設計書の項目定義と実データが一致するとは限りません。代表的なデータだけでなく、件数、空欄、重複、桁数、日付、文字コード、対象外コード、関連付けの欠落を調べます。
「必須のはずの項目が空欄」「既に廃止したコードが残る」「同じ顧客が別表記で複数ある」といった状態は、移行時のエラーや誤集計につながります。欠損を埋める、統合する、保留する、旧データとして保持するなど、扱いを決めます。
データ修正は、元の値、修正理由、承認者を記録します。移行プログラムの中だけで黙って補正すると、後から件数や金額が変わった理由を追えません。個人情報を含む抽出データは、閲覧者、保管先、保存期限も決めて管理します。
4. 変換ルールを項目単位で明文化する
旧項目と新項目の対応表を作り、型、桁数、単位、コード、空欄時の扱いを記録します。項目名が同じでも意味が同じとは限りません。
- 税込・税抜、数量単位、通貨などの違い
- 日時のタイムゾーンや日付だけの情報
- 状態コード、取消、論理削除、廃止済みデータ
- 一つの項目を複数へ分ける場合
- 複数項目を一つへ統合する場合
- 添付ファイルのパスやアクセス権の変更
変換に迷うデータは、AIや担当者の勘で自動確定しないでください。確認待ち一覧へ分け、業務責任者が決定します。移行処理を何度実行しても同じ結果になるか、途中から再実行して二重登録しないかも確認します。
5. 移行テストで確認すること
テストは、本番とは分離した環境で行います。移行した顧客情報から本番メールが送られたり、外部APIへ実登録されたりしないよう、送信先やジョブを分離・無効化してから開始します。
確認するのは、テーブルの件数だけではありません。合計金額、数量、状態別件数、関連データの欠落、代表帳票、検索結果、閲覧権限などを比較します。業務として利用できるかは、利用部門による確認も必要です。
一部抽出の確認だけで全件正しいと断定せず、自動照合できる項目は全件で確認し、業務判断が必要な部分は選定理由を決めてサンプル確認します。不一致は「仕様上の変更」と「移行誤り」に分け、未解決事項を残したまま本番へ進まないようにします。
試験移行の照合表をどう作るか
架空の受注データを例にすると、合格条件は次のように具体化できます。数字は例示であり、実際の許容差は業務責任者と先に決めます。
| 確認対象 | 比較方法 | 不一致時の対応 |
|---|---|---|
| 受注件数 | 対象期間・状態別に新旧の件数を比較 | 取消・重複・対象外条件を照合 |
| 受注金額 | 税区分と通貨を揃えて合計を比較 | 丸め・税計算・単位の変換を確認 |
| 顧客との関連 | 全受注の参照先IDが存在するか検査 | 旧新ID対応表と未変換行を確認 |
| 業務操作 | 検索、請求書発行、権限別閲覧を操作 | 再現手順と担当者を記録して修正 |
件数が一致しても、同じ顧客に請求が紐づくとは限りません。自動照合できる項目は全件で確認し、画面・帳票の意味は利用部署が確認する、という役割分担にします。AWSの移行データ検証の説明でも、元データと移行先データを対応行で比較し、不一致を報告する仕組みが示されています。この記事の確認表は特定の移行製品を前提にしません。
6. 切替時点と差分移行を決める
テスト中も旧システムの更新が続く場合、本番切替までに増えたデータを反映する必要があります。初回の全体移行と、最終差分の取得・適用を分ける方法がありますが、更新日時だけで差分を確実に把握できるかは実装によります。
新規登録だけでなく、訂正、削除、取消、添付ファイルの更新も対象です。取得順序や参照関係を確認し、どの時点の状態へ揃えるかを決めます。差分の取得方法がない場合は、停止時間を確保して最終データを移す必要があるか検討します。
切替の可否は、処理が終了したという技術的な結果だけでなく、照合、主要業務、外部連携、問い合わせ窓口の準備を含めて判断します。誰が最終承認するか、何時までに判断するかも事前に決めます。
7. ロールバックで失うデータを確認する
問題があれば旧システムへ戻すという方針だけでは不十分です。新環境へ切り替えた後に、利用者が入力したデータをどう扱うかを決めます。
旧環境へそのまま戻すと新規入力が失われる場合は、更新停止、差分取得、変換、再登録が必要になります。新旧でデータ構造が異なると、逆方向への変換が簡単とは限りません。戻せる期間と条件、戻せない場合の復旧方法を確認してください。
切り戻しの実行者、判断者、利用者への連絡、作業後の照合まで手順に含めます。バックアップファイルの存在だけでなく、必要な時間内に復元し、業務を再開できることを検証します。
切替当日の判断を時系列に書く
例えば「金曜18時に旧システムの更新を停止→最終差分を抽出→移行処理→件数・金額・参照関係を照合→受注登録と請求書発行を確認→責任者が公開を承認」と並べます。各時点で、担当者、終了見込み、合格条件、未達なら戻す期限を記録します。新環境で受注が始まった後の切り戻しは、新たな入力を失う可能性があるため、停止・保全・再取り込み手順まで決めておきます。
この段取りはシステム構成や停止可能時間によって変わります。Microsoftの公開前チェックリストも、移行・検証・切替手順の試験と業務側の承認を確認項目に挙げています。
8. 費用・期間と相談前の確認事項
費用や期間は、データ量だけでなく、形式の違い、品質、関連性、変換の複雑さ、停止時間、差分反映、照合、リハーサルで変わります。旧システムの資料や抽出権限が不足している場合は、調査を別に見積もります。
相談前には、移行元と移行先、データ種類、概算件数、添付ファイル、停止できる時間、期限、旧環境を残せる期間を整理します。正確に分からない項目は未確認とし、調査方法を相談してください。
定常的にデータを同期するAPI連携は、一度限りの移行とは異なります。継続連携が必要な場合は、API・SaaS連携の同期と運用の見積項目も確認します。システム刷新の方式自体を検討中なら、延命・更新・リプレイスの判断基準と分けて整理すると、先に調べる範囲が明確になります。
