「今使っている販売管理のシステムがもう古くて、サポートも切れそうなんです。新しいクラウドのサービスに移りたいんですが、十年分の取引データや取引先の情報がちゃんと移るのか、それが不安で決められなくて。移した後に数字が合わなかったら、と思うと」——先日、卸売業の経営者から、こんな相談を受けました。乗り換えたい気持ちはあるが、データ移行で失敗する話を聞くので怖い、というのです。
システム刷新でトラブルが起きるとき、その多くは新しいシステムの新機能の不具合ではありません。「古いシステムから新しいシステムへ、データを移す一点」に事故が集中します。しかもこの部分は、発注者からは中身が見えにくく、見積書でも「データ移行 一式」とだけ書かれがちです。本記事では、データ移行で事故らないために発注者が先に押さえるべき勘所を、受託で伴走する立場から整理します。システムそのものを作り替える判断はレガシー移行の記事で扱っているので、ここでは「データを移す」ことに絞ります。
なぜ、データは素直に移らないのか
「エクスポートして、インポートすれば終わりでは？」と思われがちですが、現実はそう単純ではありません。古いシステムと新しいシステムは、データの持ち方が違うからです。
たとえば、取引先の情報。旧システムでは会社名と担当者名が一つの欄に入っていたのに、新システムでは別々の欄に分かれている。日付の書き方が違う。同じ取引先が表記ゆれで二重に登録されている（「株式会社○○」と「（株）○○」）。金額の丸め方や税の扱いが違う。こうしたマスタデータの不整合を放置したまま流し込むと、新システム側でエラーになるか、あるいはもっと厄介なことに、エラーにならずに「間違ったまま」入ってしまいます。
さらに、業務データは単独では存在しません。受注データは取引先マスタと商品マスタに紐づいており、この紐づけが移行でずれると、受注はあるのに取引先が空欄、といった状態が生まれます。データ移行が難しいのは、一件一件を移すことではなく、データ同士の関係を保ったまま移すことなのです。このデータの受け渡し設計そのものの難しさは業務データ受け渡しの記事でも掘り下げています。
事故は「切り替え当日」に噴き出す
厄介なのは、これらの問題が切り替え当日まで表に出ないことです。テスト段階では少量のサンプルデータで動作を確認し、うまくいったように見える。ところが本番の全データを流し込み、実際の月次処理や請求を回した瞬間に、不整合が一気に噴き出します。
これは中小企業だけの話ではありません。大企業でも、2024年に食品大手が基幹システムをSAPの新しい基盤へ刷新した際に大規模な障害が起き、多くの商品が出荷停止となり、全面復旧まで数か月を要した事例が知られています。潤沢な予算と体制があっても、データ移行の検証が不十分なら事故は起きる。逆に言えば、規模の大小にかかわらず、事故らせない勘所は共通しています。
事故らせない、3つの勘所
発注者として、次の三つが見積もりと計画に入っているかを確認してください。ここが抜けている提案は、当日に事故る確率が高いと考えてよいです。
1. 移行リハーサル。本番と同じ手順・同じデータ量で、移行を事前に通しで練習します。少量のサンプルで「動いた」だけでは足りません。本番相当のデータ量で流して初めて、処理にかかる時間や、大量データ特有のエラーが見えます。リハーサルは一度で終わらず、見つかった不整合を直しては再実行し、きれいに通るまで繰り返します。
2. 本番の実データでの検収。テスト用の作り物ではなく、本物のデータを移した状態で、旧システムと新システムの数字を突き合わせます。「取引先の件数は一致するか」「今月の売上合計は旧システムと合うか」——発注者自身がチェックできる項目を、あらかじめ受託側と決めておきます。
3. 並行稼働の期間。切り替え直後に旧システムをすぐ捨てず、一定期間は両方を動かして結果を比べます。ここで注意したいのが期間の長さです。コスト削減のために並行稼働を1週間に縮めた結果、月次や四半期の処理で不整合が続出し、旧システムに緊急で戻す羽目になった——という失敗が実際にあります。業務には月次締め・棚卸し・決算といった周期があり、その一巡を検証できる期間（多くの場合、最低1か月以上）を確保しておく必要があります。
| 勘所 | 確認すること | ここを削ると |
|---|---|---|
| 移行リハーサル | 本番相当のデータ量で通しで練習しているか | 当日に時間切れ・想定外エラー |
| 本番データでの検収 | 旧新の数字を突き合わせる項目を決めているか | 間違ったデータに後から気づく |
| 並行稼働 | 業務サイクル一巡を検証できる期間があるか | 月次処理で不整合が噴出 |
事例: 並行稼働を1か月確保して、静かに乗り換えた会社
具体例を挙げます。社員四十名ほどの卸売業（社名は伏せます）で、十年以上使った受注・在庫システムをクラウドのサービスへ移す案件がありました。相談を受けた時点で先方がいちばん恐れていたのは、「切り替えたら在庫数や売掛の残高が合わなくなること」でした。
そこで、いきなり本番切り替えはせず、まず取引先マスタと商品マスタの表記ゆれ・重複を洗い出して整理することから始めました。そのうえで本番相当のデータで移行リハーサルを二度通し、二度目で残っていた不整合を潰しました。切り替え後は旧システムを1か月間そのまま残し、月次締めを新旧両方で回して数字が一致することを確認してから、旧システムを停止しました。派手なことは何もしていません。効いたのは、移行前にマスタを整え、本番データで検証し、業務が一巡するまで旧システムを残したことです。おかげで、現場が「数字が合わない」と混乱する場面は一度も起きませんでした。
発注前に、この一文を見積もりで確かめる
データ移行の成否は、契約前の見積もり段階でおおよそ決まります。提案書や見積書を受け取ったら、「移行リハーサル」「本番データでの検収」「並行稼働の期間」が明記されているかを確認してください。ここが「データ移行 一式」の一行に潰されている場合は、それぞれ何をどれだけやるのかを必ず聞き返す。この確認をするだけで、当日に事故る提案かどうかは、かなりの精度で見分けられます。要件定義や契約形態も含めた発注全体の基礎はシステム開発の発注ガイドの記事にまとめています。
古いシステムから乗り換えたいがデータ移行が不安、提案を受けたが移行計画が妥当か判断したい、移した後に数字が合わずに困っている——そうしたお悩みがあれば、グリームハブの開発・AI・自動化のご相談からお気軽にお問い合わせください。マスタの棚卸しから、移行リハーサルと検収項目の設計、並行稼働の計画まで、切り替え当日に事故を起こさない進め方をご一緒します。
