新システムへのデータ移行、何を確認する？

顧客情報、未完了の注文、在庫、債権、添付資料などを洗い出し、各データの担当者、必要な期間、正とする保存元を確認します。新システムで処理する必要のない履歴は、参照方法を合意したうえで別に保管する選択肢もあります。すべてを無条件に移す前提にしないことが大切です。

移行するデータの範囲は、既存システムのどの部分を残すかによっても変わります。改修か全面刷新かをまだ決めていない場合は、既存システムは改修する？それとも刷新する？を参考に、移行対象を確定する前に対応方針を整理できます。

保存や削除は、自社で確認した保管上の要件と利用権限に沿って判断します。不明な点は社内の担当者に確認してから範囲を決めましょう。旧システムから出力できたファイルでも、必要な情報がすべて含まれている、案件関係者全員に共有してよい、とは限りません。

この段階では、移さないデータとその参照方法も含め、責任者が確認した移行範囲を残します。

新旧でコード、状態、計算方法が異なる場合があります。例えば、旧側の「処理中」が、新側では「確認待ち」と「担当割当済み」に分かれる架空のケースです。どちらへ変換するか、手作業で確認する対象は何か、既存データだけでは判断できない点は何かを業務側と合意します。

項目の対応表には、移行元、移行先、変換ルール、例外の扱いを記載します。例えば顧客コードを変える場合、注文と債権も正しい顧客へ結び付く必要があります。同名だからといって同じ法人か確認せず統合すると、取込みは成功しても残高の帰属が誤るおそれがあります。

顧客の重複、商品コードの欠落、日付形式の不統一は、対応一覧にして修正方法の確認者を決めます。元データと変換ルールを残せば、後から差異を説明できます。取込みエラーを消すためだけに、意味の分からない値を黙って修正しないようにしましょう。

中間ファイルを使う場合も値の意味を保つ必要があります。電話番号、郵便番号、商品コードの先頭のゼロ、日付の解釈、金額の丸めは、取込みエラーにならず変わることがあります。誤りやすい値を試し、初期値で埋めるのではなく、修正のため差し戻す条件を決めます。

すべてを同じ方法で直す必要はありません。ルールで変換できるもの、業務確認が必要なもの、保留するものを分けます。全行を無理に取り込むより、担当者のいる例外一覧が役立ちます。

未処理の注文、取消済みの取引、情報が欠けたケースなど、実務を代表するデータで試します。件数だけでなく金額、数量、データ間の関係、添付資料を開けるかも照合しましょう。変換した項目は、業務上の意味が正しく保たれているか確認します。

全社の債権総額が一致しても、別の顧客へ金額が移っていれば正しい移行とはいえません。件数と金額の総計、顧客・拠点別、処理途中や訂正済みの取引と、層を分けて照合できます。全件確認か抽出確認かは影響に応じて合意し、少数のサンプルで全データの正しさを断定しないようにします。

差異は移行処理の誤り、合意済みの違い、元データの問題などに分けます。業務側が内容を確認し、技術側が修正と再実行を記録します。自動比較は助けになりますが、残高や状態が実務に合っているかという判断までは代行できません。

試行ごとに元データの版と変換ルールを記録します。ルールを直したら、再実行の範囲と重複を防ぐ方法を確認します。差異の担当者、再照合の結果、残る違いを認めた人も残しましょう。移行件数だけでなく、本番移行を判断する根拠になります。

移行結果を承認する前に、実際の利用者が新システムで未処理の注文を進めたり、顧客の残高を調べたりできるかを確認しましょう。システムの受入テスト、何を確認する？では、この確認に使う場面、期待する結果、不具合の記録方法を整理しています。

抽出後も旧システムが受注を続けるなら、その後の更新をどう扱うのでしょうか。締切時刻、追加データ、更新できる担当者、最終照合を切替前に決めておきます。一括移行か段階的な同期かは、構成と許容できる停止時間によって変わり、万能な方法はありません。

切替後は合意した期間と範囲で過去情報を参照できるようにしつつ、使わなくなった側への誤入力を防ぎます。更新権限、参照権限、旧システムの廃止は別の判断です。照合、保管、必要な参照方法を責任者が確認してから、旧データの削除を判断します。

更新と過去データの参照方法を決めたら、利用開始の時刻、支援する担当者、問題が起きた際に切替を止める条件も整えます。新システムの稼働前に準備しておきたいことでは、切替前、当日、稼働後に必要な作業をどう連携させるかを説明しています。

Fenixへのご相談では、機微情報を除いたサンプル、業務ルール、照合に使う帳票をご用意いただくと、日程を決める前に必要な作業を整理しやすくなります。

Fenixへ相談する