業務システムをリプレースするとき、最大のリスクはデータ移行です。新システムの設計や開発はベンダーが責任を持ちますが、移行する元データの品質は会社側にしかわかりません。文字化け、コード不整合、消えた取引履歴、二重に登録された顧客——こうしたトラブルは、本番運用開始後に発覚すると修復コストが10倍以上に膨らみます。本記事では中小企業のデータ移行を失敗させないための実践的な手順を、既存データの整理・移行スコープの線引き・検証プロセス・現場担当者の関わり方・本番切替判断の5つの観点から経営者目線で整理します。
この記事の結論(3行)
- データ移行の失敗原因は技術ではなく「既存データの整理不足」が8割。発注前のクレンジングが最大のレバー
- 移行スコープは「全期間」ではなく「直近3〜5年分」に絞ると、コストもリスクも大きく下がる
- 本番切替前に2回のリハーサルを実施。1回目で問題発見、2回目で修正確認まで踏むのが現実的
なぜデータ移行は中小企業で失敗するのか
中小企業のシステムリプレース案件で「移行で失敗した」と聞くケースの大半は、技術的な問題ではなく事前準備の問題です。ベンダーは依頼された通りのデータを移すしかなく、元データの品質まで担保することは難しいのが実態です。
- 既存データが整理されておらず、移行時に不整合が発覚する
- 移行スコープが曖昧で、「全部移す」前提のまま見積もりが膨らむ
- 現場担当者が移行プロジェクトに関わらず、ベンダー任せになる
- 検証プロセスが不十分で、本番運用後にデータの問題が見つかる
- 本番切替の判断基準が事前に決まっていない
この5つの構造的な問題を発注前に潰しておくことが、データ移行成功の鍵です。
既存データが整理されていない
長年使ってきた業務システムには、廃番商品コード、解約済み顧客、誤入力された取引データ、退職した担当者の情報など、整理が必要なデータが大量に蓄積されています。これらをそのまま新システムへ移すと、新システム側でも問題を引き継ぐことになります。
移行スコープが曖昧
「データは全部移します」という前提で進めると、移行コストが青天井になります。何年分のデータを移すか、どのテーブルを移すか、廃番データはどう扱うか——こうしたスコープを事前に決めないと、ベンダーは安全側に倒して「全部移す」見積もりを出します。
現場担当者が関わらない
データ移行は技術案件のように見えますが、「このデータは何か」「どこまで残すべきか」を判断できるのは現場の担当者だけです。現場が関わらず情シスとベンダーだけで進めると、業務知識が反映されず本番後に問題が噴出します。
検証プロセスが不十分
移行後のデータ件数を確認するだけでは検証になりません。「件数は合っているが中身が変わっている」という事象は珍しくなく、業務シナリオベースでの検証が必要です。
本番切替判断基準が決まっていない
「リハーサルで何件以下のエラーなら本番に進む」という基準を事前に決めていないと、本番直前に「進むか戻すか」で大混乱になります。
データ移行プロセスの5段階モデル
データ移行は次の5段階に分解できます。それぞれで「経営判断が必要なポイント」が明確になります。
| 段階 | 期間目安 | 主な作業 | 経営判断ポイント | |---|---|---|---| | 第1段階:整理 | 1〜2ヶ月 | 既存データの棚卸し・クレンジング | 整理を社内で行うか外注するか | | 第2段階:スコープ確定 | 2週間 | 移行対象の線引き | 何年分を移行対象とするか | | 第3段階:マッピング設計 | 1ヶ月 | 旧→新のデータ項目対応表 | 廃止項目・新規項目の扱い | | 第4段階:リハーサル | 2週間×2回 | 移行スクリプト実行と検証 | 本番進行の判断基準設定 | | 第5段階:本番切替 | 1〜2日 | 本番データの移行と検証 | 切替実施 or 延期の判断 |
この5段階のうち、第1段階の「整理」に最も時間と労力をかけることが、失敗を防ぐ最大のレバーです。
第1段階:既存データの整理(最大のレバー)
データ移行の8割の品質はここで決まります。具体的には次のような作業を含みます。
- 廃番商品コードの削除または「廃番」フラグの付与
- 解約済み顧客のステータス整理
- 重複登録された顧客・取引先の名寄せ
- 退職者アカウントの無効化
- 誤入力データの修正または削除
この作業は1〜2ヶ月かかります。発注後に始めるとプロジェクト全体が遅れるため、発注の3ヶ月前から着手することをお勧めします。
第2段階:スコープ確定
移行対象を「全期間」とするか「直近何年分」とするかを決める段階です。実務上は「直近3〜5年分は完全移行、それ以前は参照用に別データベースで保持」が現実解です。これだけで移行コストが3〜5割下がります。
第3段階:マッピング設計
旧システムの項目と新システムの項目を1対1で対応させる作業です。旧システムに存在して新システムにない項目(廃止項目)、新システムにあって旧データにない項目(新規項目)の扱いを決めます。ここでの判断は現場担当者が中心になって行います。
第4段階:リハーサル
本番切替の前に、移行スクリプトを2回実行します。1回目で問題を洗い出し、2回目で修正後の確認を行います。各リハーサルでは、件数確認だけでなく業務シナリオベースの検証(例:直近1ヶ月分の請求書が正しく生成されるか)を行ってください。
第5段階:本番切替
事前に決めた判断基準に基づき、本番切替を実施するか延期するかを決めます。判断基準の例:「リハーサルでクリティカルエラー0件、軽微エラー10件以下なら本番進行」など。判断基準を事前に決めておくことで、本番直前の混乱を避けられます。
データクレンジングの実践手順
第1段階の「既存データの整理」を具体的にどう進めるか、5つの実践手順を整理します。
手順1:データ件数の棚卸し
まず全テーブルの件数を一覧化します。「顧客マスタ3万件、商品マスタ1万件、取引履歴100万件」のように数字で把握することで、移行作業の規模感が見えてきます。
手順2:直近1年で使われたデータの抽出
直近1年で実際に登録・更新されたデータと、それ以外を分けます。1年間動きのないデータは、移行対象から外せる可能性が高いです。
手順3:重複データの名寄せ
特に顧客マスタは重複が多発します。「株式会社○○」と「○○株式会社」のような表記ゆれ、半角・全角の違いなど、目視で1万件をチェックするのは非現実的です。ExcelやAccessでの簡易チェックと、現場担当者による最終確認を組み合わせて進めます。
手順4:マスタコードの整理
商品コード・顧客コードなどのマスタコードに、廃止予定のコードや欠番がないか確認します。新システムでコード体系を変えるか維持するかも、この段階で決定します。
手順5:例外データの判定
「テストで入れたデータ」「過去の特殊取引」など、現場担当者しかわからない例外データを判定します。これは情シスやベンダーには判定できず、現場担当者の関与が必須です。
経営者目線で考える「データ移行への投資判断」
データ移行は、システム導入予算とは別枠で扱うべき投資です。新システム本体に1,000万円かけても、データ移行を100万円で済ませようとすると、本番運用後に問題が噴出して結果的に数百万円の追加コストが発生します。
経営者の判断が必要なのは3点です。第一に、データ移行予算をシステム本体予算の15〜25%確保する原則。1,000万円のシステムなら150〜250万円が目安です。これを下回ると、第1段階の整理工程を省略することになり、リスクが跳ね上がります。
第二に、データクレンジングを「現場の本業の一部」として扱う判断。1〜2ヶ月の整理作業は現場社員の時間を使います。これを「業務外の追加負担」と現場が認識すると進まないため、経営者が「会社の重要プロジェクトの一部として時間を確保していい」と明確に宣言する必要があります。
第三に、現場担当者をプロジェクトに専任化する人員配置。月の20〜30%の時間をデータ移行に充てる現場担当者を、各業務部門から1名ずつ指名してください。兼任体制では進まないのが現実です。経営者の意思決定がないと、現場マネージャーは部下を出してくれません。
データ移行は「ベンダーに任せれば終わる」ものではなく、「会社のデータ資産を再構築する」プロジェクトとして経営判断を行うべき領域です。
ぷらすわんの実例:A社のデータ移行整理
ある中小卸売業A社では、20年使ってきた基幹システムをリプレースする際、ぷらすわんが移行プロジェクトの整理段階から関わりました。当初は「データは全部新システムへ移す」という前提で2,000万円の見積もりが出ていましたが、整理を進めた結果1,300万円まで圧縮できました。
差分を生んだのは3つの判断です。第一に、20年分のデータを「直近5年は完全移行、それ以前は参照用別DBで保持」と線引きし、移行件数を100万件から30万件へ減らしました。第二に、顧客マスタの重複5,000件と廃番商品コード3,000件を整理し、新システムでのコード体系を整えました。第三に、現場担当者3名を週1日プロジェクト専任にして、現場知識を反映した判定を進めました。
整理段階で約1.5ヶ月かかりましたが、その後の移行作業は予定通りに進み、本番切替後のトラブルもほぼゼロでした。発注前の整理段階に時間と予算を投じることが、トータルコストを下げる最大のレバーです。自社のデータ移行プロジェクトを診断することで、どこから着手すべきかが明確になります。
リハーサルと本番切替の判断基準
第4段階のリハーサルと第5段階の本番切替について、もう少し具体的に整理します。
リハーサルは最低2回実施してください。1回目は「全データを移行スクリプトで流し込み、何件のエラーが出るか確認する」フェーズです。エラーの種類を分類し、クリティカル(業務停止につながる)/重大(修正必須だが運用回避可能)/軽微(後日修正でよい)の3段階で整理します。
2回目は「1回目で発見した問題を修正した後の再実行」です。クリティカルエラーは0件、重大エラーも0件、軽微エラーは10件以下、というのが本番進行の現実的な基準です。これを超える場合は本番切替を延期し、3回目のリハーサルへ進む判断をしてください。延期は失敗ではなく、本番運用後のトラブルを未然に防ぐ正しい判断です。
本番切替は基本的に週末を使います。金曜夜に旧システムを停止し、土日で本番データを移行、月曜朝から新システム稼働、というスケジュールが典型です。中規模データなら24時間程度で完了します。本番切替直後の1週間は、現場からの問い合わせが集中するため、ベンダーの常駐サポートを確保しておくことをお勧めします。リハーサル設計や判断基準の項目別に整理が必要な経営者は、診断から始める流れが現実的です。
データ移行で起こりがちな3つのトラブル事例
最後に、中小企業のデータ移行でよく見るトラブル事例と対処法を3つ整理します。
事例1:文字コードによる文字化け
旧システムがShift-JISで、新システムがUTF-8の場合、機種依存文字や半角カナで文字化けが発生します。リハーサルで全文字種を含むサンプルデータを用意し、文字化け箇所を洗い出してください。発覚してから対処すると数日かかるため、リハーサル段階での発見が肝心です。
事例2:自動採番の不整合
旧システムの伝票番号と、新システムの自動採番ロジックが食い違うケースです。新システム稼働後の最初の伝票番号を旧システムの続きから始めるか、新しい体系で振り直すかを事前に決めてください。
事例3:マスタ参照の崩壊
取引履歴に登録されている顧客コードが、整理過程で削除された顧客マスタを指している、というケースです。マスタを削除する前に、参照されている履歴データを別コードに付け替える作業が必要です。これを忘れると、新システムで取引履歴を開いた瞬間に「顧客不明」というエラーが多発します。
まとめ
データ移行で失敗しないためには、技術ではなく事前準備が8割の成否を決めます。発注の3ヶ月前から既存データの整理に着手し、移行スコープを「直近3〜5年分」に絞り、現場担当者をプロジェクトに専任化し、2回のリハーサルで本番進行の判断基準を確認するという5段階のプロセスを踏むことで、リスクを大きく下げられます。
経営者が判断すべきは、データ移行予算をシステム本体の15〜25%確保すること、クレンジング作業を現場の本業の一部として認めること、現場担当者を専任化する人員配置の3点です。データ移行を「ベンダー任せ」ではなく「会社のデータ資産を再構築するプロジェクト」として位置づける発想を経営判断に組み込めば、リプレース後のトラブルは大幅に減ります。自社の状況を比較を依頼する前に、まず整理段階から始めることをお勧めします。