基幹システムの入れ替えで、もっとも手間がかかるのがデータ移行です。
そして、もっとも軽視されやすい工程でもあります。「今のデータをそのまま移せばいい」と考えて着手し、想定の何倍も時間がかかる。よくある展開です。
この記事では、ERP導入支援を手がけるベンチャーネットが、Odooへのデータ移行の進め方を整理します。読み終えると、次の3つが分かります。
- データ移行で、なぜつまずくのか
- 何を移し、何を捨てるべきか
- 移行を成功させる5つのステップ
なぜデータ移行でつまずくのか
「そのまま移す」が最大の落とし穴
長く使ったシステムには、必ずこうしたデータが溜まっています。
- 何年も取引のない取引先
- すでに廃番になった品目
- 同じ会社が別名で複数登録されている
- 表記がバラバラの住所や名称
- 誰も使っていないマスタ項目
これらをそのまま新システムに移すと、新しいシステムでも同じ混乱が続きます。
せっかく入れ替えたのに、検索しても目的のデータが見つからない。集計が合わない。そんな状態が再現されます。
データの状態が、移行の期間を決める
移行にかかる時間は、データの量ではなく状態で決まります。
整理されたデータなら、量が多くても移行は進みます。逆に、重複や表記ゆれが多いデータは、量が少なくても膨大な確認作業が発生します。
誰も全体像を知らない
もうひとつの難所は、「どこに何のデータがあるか」を把握している人がいないことです。
基幹システムのほかに、部署ごとのExcel、個人のPC、紙の台帳。実際に業務で使われているデータが、あちこちに散らばっています。
ステップ1：データの棚卸し
移行の第一歩は、移すことではなく知ることです。
どこに何があるかを洗い出す
次の観点で、業務で使っているデータを列挙します。
- 現行の基幹システムに入っているデータ
- 部署ごとに管理しているExcelファイル
- 個人が持っている作業用のデータ
- 紙で運用している台帳
意外に多いのが、3つ目と4つ目です。システムに入っていないのに、業務上は不可欠というデータが見つかります。
データの種類を整理する
移行対象は、大きく3種類に分かれます。
| 種類 | 内容 | 移行の考え方 |
|---|---|---|
| マスタデータ | 取引先、品目、勘定科目、従業員など | 最優先。整理して移す |
| 残高データ | 在庫数量、売掛・買掛の残高など | 切替時点の数字を移す |
| 履歴データ | 過去の受注・出荷・仕訳など | 移すか、参照用に残すか判断 |
とくに履歴データは、判断が必要です。次の章で扱います。
ステップ2：何を移し、何を捨てるか
マスタデータ：使っているものだけ移す
取引先や品目は、直近で実際に取引があったものに絞るのが基本です。
判断の目安：
- 直近2〜3年で取引のある取引先
- 現在も扱っている品目
- 在籍している従業員
「いつか使うかもしれない」で残すと、新システムで検索性が下がります。必要になったときに、あらためて登録するほうが健全です。
残高データ：切替時点の数字を正確に
在庫数量、売掛金・買掛金の残高などは、切替時点の数字を移します。
ここでもっとも大切なのは、移行の前に実地で確認することです。とくに在庫は、帳簿と実数が合っていないまま移すと、稼働直後から差異の調査に追われます。
履歴データ：全部を移す必要はない
過去の受注データや仕訳を、すべて新システムに移す必要はありません。
現実的な選択肢は3つあります。
移す：直近1〜2年分だけを移行する
参照用に残す：旧システムを参照専用で一定期間残す
書き出して保管：CSVやPDFで出力し、必要時に確認できるようにする
法令上の保存義務がある帳簿・書類については、保存方法と期間の要件を確認してください。制度の解釈にかかわる部分は、税理士や顧問先への確認をおすすめします。
ステップ3：データを整える
仕分けが終わったら、移す対象のデータを整えます。
よくある整備項目
- 重複の統合：同じ取引先の重複登録をひとつにまとめる
- 表記ゆれの統一：「株式会社」と「(株)」、全角と半角の混在を揃える
- 必須項目の補完：新システムで必要になる項目の空欄を埋める
- コード体系の見直し：品目コードや取引先コードの付け方を整理する
コード体系は、この機会に見直す
長年運用していると、コードの付け方が場当たり的になっていることがあります。
移行は、この体系を見直す数少ない機会です。ただし、変更すると現場が混乱する面もあるため、影響範囲を確認したうえで判断してください。
整備は現場と一緒に行う
「この取引先はまだ使うのか」「この品目は生きているのか」。
これらは、システム担当だけでは判断できません。現場を巻き込む工程として、あらかじめ時間を確保しておく必要があります。
ステップ4：移行テスト
一度で成功することはない
移行は、必ず複数回のテストを前提に計画します。
1回目で必ず問題が見つかります。項目の対応が合わない、文字数の上限を超える、日付の形式が違う。こうした問題を洗い出すのがテストの目的です。
テストで確認すること
- 件数が合っているか（移行前と移行後で数が一致するか）
- 金額の合計が合っているか
- 文字化けや欠落がないか
- 業務が実際に回るか（受注から請求まで通してみる）
とくに最後が重要です。データが入っただけでは不十分で、そのデータで業務が流れるかを確かめます。
現場に触ってもらう
テスト環境に移したデータを、実際に使う人に見てもらってください。
「この取引先の名前が違う」「この品目が出てこない」。現場でなければ気づけない問題が、必ず出てきます。
ステップ5：本番移行
切替のタイミングを決める
多くの場合、月次や期の区切りに合わせます。残高の締めが明確になるためです。
切替直前の作業を計画に入れる
本番移行では、切替直前の最新データを移す作業が発生します。
この間、業務を止めるのか、並行して運用するのか。あらかじめ決めておかないと、切替当日に混乱します。
旧システムをすぐに止めない
参照が必要になる場面が、必ず出てきます。一定期間は旧システムを参照専用で残しておくのが安全です。
移行を軽く見ないための注意点
移行を「作業」だと思わない
データ移行は、単なる引っ越しではありません。業務で使う情報を棚卸しする工程です。
だからこそ、システム担当だけでは完結しません。現場と経営を巻き込む前提で計画してください。
期間を短く見積もらない
もっともよくある失敗が、移行期間の過小見積もりです。
とくに仕様書が残っていない、データが散らばっている、現場が忙しくて確認に時間がかかる。こうした条件が重なると、想定の何倍もかかります。
移行を理由に業務を止めない
「移行が終わるまで待つ」という進め方は、現場の負担を増やします。
領域を区切って段階的に移す方法を検討してください。全部を一度に切り替えないほうが、リスクも小さくなります。
よくある質問
過去のデータはすべて移すべきですか？
その必要はありません。
マスタと残高は移し、履歴は直近分だけ移す。それ以前は旧システムを参照用に残すか、書き出して保管する。この形が現実的です。全部を移そうとすると、期間も費用も大きく膨らみます。
データの整備は誰がやりますか？
現場の協力が不可欠です。
「この取引先はまだ使うのか」といった判断は、システム担当には分かりません。支援先が作業を代行することはできますが、判断そのものは自社で行う必要があります。この時間をあらかじめ確保しておいてください。
Excelで管理しているデータも移せますか？
移せます。むしろ、Excel管理からの脱却が導入の目的になることも多くあります。
ただし、Excelのデータは形式が不揃いなことが多く、整備に時間がかかります。棚卸しの段階で、どのExcelが業務で使われているかを洗い出してください。
移行にはどれくらいの期間がかかりますか？
データの状態によって、大きく変わります。
整理されたデータなら短く済みますが、重複や表記ゆれが多い場合は、整備だけで相当の時間がかかります。まず棚卸しをして、状態を把握するところから始めてください。期間の見積もりは、その後の話になります。
まとめ：移行の前に「整理」がある
この記事の要点です。
- そのまま移すと、新システムでも同じ混乱が続く
- 移行期間を決めるのは、データの量ではなく状態
- マスタは絞って移し、残高は正確に、履歴は全部を移さない
- 移行テストは複数回が前提。業務が回るかまで確認する
- データの判断は現場でしかできない。時間を確保しておく
データ移行は、地味で手間のかかる工程です。しかし、ここを丁寧にやるかどうかで、新システムが使えるものになるかが決まります。
そして、この作業の本質は「自社がどんな情報で事業を回しているのか」を見直すことです。技術の話に見えて、経営の話でもあります。
ベンチャーネットは、SAP、NetSuite、Odoo、AIスクラッチ開発の4つを扱っています。移行の進め方だけでなく、そもそもどの選択肢が合うのかという段階からご一緒できます。
「どこから手をつければよいか分からない」という状態こそ、相談の出発点です。
もう少し詳しく知りたい方へ
関連記事
