顧客データ移行後、注文や問い合わせの履歴が別人に表示されるときは、元データを直接修正する前に「旧顧客IDから新顧客IDへどう変換したか」を検査します。同名・同姓の顧客がいても、名前で推測して履歴を付け替えてはいけません。
旧IDと新IDの対応表を用意する
移行前の読取専用スナップショットを保全し、旧顧客ID、旧システムの組織ID、移行後の新顧客ID、移行日時、処理バッチIDからなる対応表を用意します。例えば旧ID C-0012 が新ID U-473 に対応する記録を固定し、履歴テーブルの外部キーをどの時点で置換したか追えるようにします。個人情報を含む対応表は必要な人だけに閲覧権限を与えます。
IDの再採番と重複を確認する
移行の際に新システムが通し番号を再採番していた場合、旧IDをそのまま新IDとして参照すると別の人へ紐づく可能性があります。対応表で旧IDの重複、新IDの不正な重複、対応先が空欄の行を集計します。1対1のはずなのに旧IDに新IDが2件あるなら自動修正しないで保留します。統合顧客・法人グループなど例外の多対一関係は事前の仕様で判断してください。
紐付け先の顧客属性を照合する
注文履歴の顧客IDと新しい顧客マスターを結合し、旧IDとの対応に矛盾がないか照合します。氏名だけではなく、法人コード・登録日時・旧取引先番号など信頼できるキーで確認します。ただし誤登録を修復するために不必要な個人属性を横断閲覧しないようにしてください。試験用に匿名化した複数件で「Aさんの注文がAさんに、Bさんの問い合わせがBさんに表示される」を確かめます。
誤登録の修正前に移行ログを保存する
誤紐付けを発見したら、どの履歴IDが旧IDいくつから新IDいくつへ転換されたかログを保存します。書換え前にバックアップを取得し、関係する履歴・添付・請求書の参照を一覧化します。顧客向け画面に別人の情報が露出している場合は、修復だけでなくアクセス停止・情報漏えい対応を優先してください。大量の一括UPDATEは対応表を再検査した後、承認された手順で実行します。
参考資料
