ERP データ移行 完全ガイド|手順・ツール比較・マスタ整備・並行運用と失敗回避
目次 クリックで開く
本記事の親ピラー(包括ガイド)
本記事は Aurant Technologies の ERP移行 親ピラーガイドを支えるクラスター記事です。
ERPの導入・刷新プロジェクトにおいて、追加コストの60〜70%はデータ移行が占めるという業界統計があります。当初予算では収まるはずだったプロジェクトが、終わってみれば1.5〜2倍の費用がかかっていた――その大半の原因が、マスタ整備の遅延、移行ツールの選定ミス、並行運用設計の甘さの3点です。
本記事は、ERPデータ移行プロジェクトを「予算と時間を守って終わらせる」ための実務ガイドです。4ステップの進め方、マスタクレンジングの具体的手法(SQL例とAI活用パターンを含む)、主要移行ツール7選の機能・料金比較、並行運用の3パターン、年商規模別のコスト試算、そして失敗パターン6つと回避策まで、現場で実際に効く順序で整理しました。
1. ERP データ移行プロジェクトの4ステップ全体像
移行プロジェクトは、技術的な作業に見えて実態は「マスタ整備とビジネスルール合意」の比重が大きい仕事です。次の4ステップで、業務部門と情シスの責務を分けて進めるのが定石です。
ステップ1:データ品質アセスメント(DQA)
プロジェクトの最初の30日で実施するのが、データ品質アセスメント(Data Quality Assessment)。「移行前のマスタが今どのくらい汚れているか」を定量化します。重複レコード数、廃止フラグなしの未使用マスタ数、表記揺れ率、必須項目欠損率――これらの指標を、移行対象マスタごとに数値化します。
この段階で「マスタクレンジング工数の見積もり」を確定させ、Phase 2以降の体制と予算を組みます。DQAをスキップしてマッピング設計に入ると、後段で「想定よりマスタが汚かった」事故が起きてプロジェクトが3〜6ヶ月延びます。
ステップ2:マスタクレンジングとマッピング設計
30〜90日のフェーズで、優先度の高いマスタから順次クレンジングします。並行して、旧ERPと新ERPの項目マッピング表を作成。「同じ意味の項目はどれか」「データ型・桁数・コード体系の差異をどう吸収するか」「NULL値・デフォルト値の扱い」を、業務ルールとしてドキュメント化します。
ステップ3:移行ツール選定とパイロット移行
90〜180日のフェーズで、移行ツールを選定し、本番データの一部(例:直近3ヶ月の取引データ、上位100社の取引先)でパイロット移行を実施。「移行ジョブが何時間で終わるか」「エラー件数と原因」「リトライ後の整合性」を実測し、本番手順書に落とし込みます。
ステップ4:本番移行と並行運用、カットオーバー
180〜270日が本番移行と並行運用、270〜360日でカットオーバー。並行運用期間中は、旧ERPと新ERPの両方で月次決算を実施し、集計結果の差異を検証します。差異が許容範囲内(一般に金額差0.1%以下)になったタイミングで、新ERP単独運用へ切り替えます。
2. マスタクレンジングの優先順位と実装手法
マスタクレンジングはデータ移行プロジェクトで最も工数を食う領域で、ここの先送りが失敗の最大要因です。優先順位と具体的な実装手法を整理します。
6つのマスタの優先順位
マスタ間には「上流→下流」の依存関係があります。下流のマスタからクレンジングしても、上流が汚いと意味がありません。優先順位は次の通り。
| 優先度 | マスタ | 役割 | クレンジング論点 |
|---|---|---|---|
| 1 | 取引先マスタ(Account) | 請求・支払の根本 | 重複統合、表記揺れ正規化、廃止判定 |
| 2 | 商品・品目マスタ | 販売・在庫・原価の根本 | 廃番判定、コード体系統一、BOM連動 |
| 3 | 勘定科目マスタ | 会計の根本 | 未使用科目廃止、補助科目整理、新会計基準対応 |
| 4 | 部門・プロジェクトコード | 分析の根本 | 組織変更反映、廃止部門の処理 |
| 5 | 従業員マスタ | 人事・給与・経費 | 退職者処理、人事情報の整合 |
| 6 | 取引マスタ(売上・仕入履歴) | 過去分析・税務対応 | 何年分を移行するかの判断 |
重複検出の実装パターン
取引先マスタの重複は、表記揺れ(株式会社/(株)/カブシキガイシャ/全角半角/前後空白)と人為的な重複入力の2要因が主です。実務では次の3段階で検出します。
- 第1段階(法人番号での突合):国税庁の法人番号公表サイトAPIで、13桁の法人番号をキーに突合。法人番号が判明しているレコードは99%以上の精度で重複検出可能。
- 第2段階(正規化マッチ):法人番号が無い場合、社名を正規化(株式会社→空、全角→半角、スペース除去、ひらがな化)して完全一致で突合。
- 第3段階(ファジィマッチ):上記でも漏れる場合、Levenshtein距離やトリグラム類似度(80%以上)で候補抽出し、業務担当者が目視確認。
SQLでの正規化の例:
-- 社名正規化キーの生成
SELECT account_id,
account_name,
LOWER(
REGEXP_REPLACE(
REGEXP_REPLACE(account_name, '株式会社|(株)|\(株\)|有限会社|(有)', ''),
'\s+', ''
)
) AS normalized_key
FROM old_erp_account;
-- 正規化キーでの重複検出
SELECT normalized_key, COUNT(*) AS dup_count,
STRING_AGG(account_id || ':' || account_name, ' | ') AS variants
FROM (SELECT ... 上記サブクエリ ...) t
GROUP BY normalized_key
HAVING COUNT(*) >= 2
ORDER BY dup_count DESC;
廃止判定の基準
未使用マスタは「削除」せず「廃止フラグ」を立てるのが原則。物理削除すると、過去の取引データから参照したときに孤児レコードが発生します。判定基準は業務でルール化:「過去3年取引なし → 自動廃止候補」「廃止候補から業務部門レビュー1回 → 廃止確定」のような2段階フローが現実的です。
AI/LLMを使ったマスタクレンジング自動化
最近は、Claude/GPT等のLLMにマスタ正規化を任せるパターンが増えています。「住所表記の正規化」「業種コードの推定」「商品名の表記揺れクラスタリング」など、ルールベースで書きづらい処理をLLMに任せる構成です。10万件規模のマスタなら、API呼び出しコスト数万円〜数十万円でクレンジングを自動化できます。
ただし、LLM出力の精度は100%ではないため、必ず業務担当者の確認フローを挟むこと。特に金額・税率・科目分類など、誤ると金額影響が出る領域では、LLMは「候補提示」、確定は人間の判断、という分業が安全です。
3. 主な主要移行ツール 機能・料金徹底比較
ERP移行で使う移行ツールは、(a) ERP標準の移行機能、(b) 汎用ETLツール、(c) iPaaS連携基盤、の3カテゴリ。それぞれ得意領域が違うため、適材適所で組み合わせるのが定石です。
| ツール | カテゴリ | 得意領域 | 料金目安 | 選ぶ判断軸 |
|---|---|---|---|---|
| SAP Migration Cockpit | ERP標準 | SAP S/4HANA への移行 | SAPライセンスに含む | SAP移行ならまず検討 |
| Oracle FBDI / EDM | ERP標準 | Oracle Fusion Cloud ERP移行 | Oracleライセンスに含む | Oracle ERPなら標準利用 |
| NetSuite SmartView / SuiteAnalytics | ERP標準 | NetSuite移行 | NetSuiteライセンスに含む | NetSuite移行で必須 |
| Informatica PowerCenter / IDMC | エンタープライズETL | 大規模・複雑な移行 | 年額500万円〜 | 大企業・複数SaaS統合 |
| Talend Open Studio / Cloud | OSS ETL | 中規模・柔軟性重視 | OSS無料 〜 Cloud年額100万円〜 | IT人材内製・コスト抑制 |
| DataSpider Servista | 国産ETL | 国内SaaS・基幹システム | 初期70万円〜+500万円〜 | 日本語UI・日本のSaaS連携重視 |
| Waha! Transformer | 国産ETL | 大量データ高速処理 | 年額135万円〜 | 大量バッチ処理・国産信頼性 |
| trocco | クラウドETL/ELT | クラウド型・DWH連携 | 月額10万円〜 | クラウドファースト・DWH統合 |
ツール選択の現実解:「ERP標準+汎用ETL」の組み合わせが大半のケースで最適です。ERP標準ツールはマスタの登録仕様(必須項目・コード桁数・参照整合)を熟知しているため、最終ロード段階で強みを発揮します。一方で、旧システムからの抽出・前処理・複雑な変換は汎用ETL(Informatica/Talend/DataSpider 等)の方が柔軟。両者を「前段=ETL、後段=ERP標準」で組み合わせると、設定コストと信頼性のバランスが取れます。
ツール選定の3つの判断軸
具体的にどれを選ぶかは、次の3軸で判断します。
- 軸1:移行先ERPの種類:SAP/Oracle/NetSuite なら標準ツールが第一選択。Microsoft Dynamics 365 / freee / マネーフォワード等は標準ツールが弱いため、汎用ETLが必要。
- 軸2:移行データ量:マスタ数万件+取引数百万件規模なら汎用ETL必須。マスタ1万件以下なら ERP標準+Excel/CSVでも回せる。
- 軸3:社内IT人材:ETLツールの設定はSQL/スクリプト知識が必要。内製人材がいない場合は、ベンダー支援前提のInformatica/DataSpiderか、ノーコードのtroccoが現実的。
4. 並行運用の3パターン設計
並行運用は、新ERPの本番運用に切り替える前に「旧ERPと新ERPを両方動かして整合性を確認する期間」のこと。設計次第でリスクが大きく変わります。3つの典型パターンを比較します。
パターンA:フル並行運用
旧ERPと新ERPを並列で完全稼働させ、業務部門が両方にデータ入力する方式。月次決算を両方で実施して差異を検証します。最も安全ですが、業務負荷が1.5〜2倍になるため期間は1〜3ヶ月が限度。大企業の基幹系移行、または上場企業のSOX対応が必要な場合に選ばれます。
パターンB:段階並行(モジュール単位)
「会計だけ先に新ERP、販売は旧のまま」というモジュール単位の段階切替。3〜6ヶ月かけて順次新ERPに移行します。業務負荷の山を分散できるためリスクが下がりますが、モジュール間の連携を「旧⇔新の橋渡し」で維持する追加コストが発生。中堅企業の現実解として最も多く選ばれるパターンです。
パターンC:Big Bang(一括切替)
並行運用なしで、ある日を境に旧ERPを止めて新ERPに完全切替する方式。期間とコストは最も少なくて済みますが、切替後にトラブルが起きた場合の業務停止リスクが極めて高い。小規模・単一拠点・業務停止許容(連休中の切替など)の条件が揃った場合のみ採用される手法です。
5. 業種別の固有事情とハマりやすい点
「ERPデータ移行」と一括りに言っても、業種ごとに難所が大きく違います。代表的な5業種の固有事情を整理します。
製造業(品目・BOM・原価マスタ)
製造業の難所は品目マスタとBOM(部品表)の整合。親品目に紐づく子品目(原材料・部品)の階層関係を維持しながら移行する必要があり、旧ERPのコード体系(例:12桁固定)から新ERPのコード体系(例:可変長+プレフィックス)への変換時にBOM参照が壊れる事故が多発します。BOM階層を維持するための「旧→新コード対応マスタ」の作り込みに、プロジェクト全体工数の20〜30%を割く覚悟が必要です。
卸売業(複数取引先・複数販売チャネル)
卸売業の難所は取引先マスタの重複と取引履歴の名寄せ。同じ取引先が「本社」「○○支店」「△△部門」と複数登録されているケースが多く、新ERPで取引先を1本化する際に、過去取引履歴をどの取引先に紐付けるかの判断が膨大な工数を生みます。法人番号での突合+業務担当者の手動確認を組み合わせるのが現実解。
サービス業(役務マスタ・契約期間管理)
サービス業の難所は役務(サービス)マスタの定義と契約期間管理。同じ「コンサルティング料」でも、月額固定/成果報酬/時間単価など契約形態が複数あり、旧ERPで自由記述で運用していた場合に新ERPの構造化フィールドへの変換が困難。契約マスタの整理と、サブスクリプション売上計上の前受金管理が頻出論点です。
金融業(勘定科目・規制対応)
金融業の難所は勘定科目の精緻さと規制対応。一般企業では「販管費」一本で済むものが、金融機関では「役務取引等収益」「特定取引収益」など細分化されており、移行先ERPがこの粒度に対応できるか事前確認が必須。加えて、金融庁の監督指針に沿った監査証跡の保存要件があり、移行ログを7〜10年間保管する設計を最初から組み込む必要があります。
小売業(SKU・販売実績・在庫)
小売業の難所はSKU(最小在庫管理単位)の膨大さと販売実績データ量。アパレル等でカラー・サイズ展開を含めるとSKUが10万〜100万件規模になり、汎用ETLでも数日かかる移行ジョブになります。販売実績データはPOSから取り込むため、過去1〜3年分でテラバイト級。差分移行戦略と並列ロードの設計が成否を分けます。
6. 年商規模別のコスト試算
ERPデータ移行の「いくらかかるのか」は、年商規模と移行範囲、社内IT人材の有無で大きく変動します。典型値を3規模で示します。
年商10億円規模:1,200万円・9ヶ月案件
移行データ量はマスタ数千件+取引履歴3年分。情シス1名+業務専任2名(兼務含む)+ベンダー支援で進行。人月コスト800万円、ツールライセンス(年額)200万円、並行運用人件費200万円で計1,200万円が目安。中小企業のERP刷新では、データ移行費がプロジェクト総額の30〜40%を占めるイメージです。
年商50億円規模:5,000万円・12ヶ月案件
マスタ数万件+取引履歴5年分。情シス3名+業務専任5名+ベンダーで進行。人月3,000万円、ツール800万円、並行運用1,200万円で計5,000万円。この規模では、マスタクレンジング専任チームを立てる判断が経済合理性を持ちます。
年商500億円超:1.8億円・18-24ヶ月案件
マスタ数十万件+取引履歴7-10年分。情シス10名超+業務専任20名+外部コンサル+実装ベンダー。人月1億円、ツール3,000万円、並行運用5,000万円で計1.8億円規模。大企業ではフル並行運用が必須となり、業務部門の負荷分散と並行運用人件費がコストの中心になります。
この試算はあくまで典型値で、実際は移行データの汚染度、IT人材の内製率、選定ツールで±30%程度の幅で動きます。RFPフェーズで3社以上のベンダーから見積を取り、自社条件で再計算するのが必須です。
7. 典型的な失敗パターン6つと回避策
実プロジェクトで毎回発生する失敗パターンを6つに整理します。事前に対策を組み込めば、再発を避けられます。
失敗1:マスタクレンジングの先送り
「マスタ整備は移行直前にまとめてやろう」という判断で、Phase 1〜2のクレンジング工数を圧縮するケース。Phase 3〜4で「想定より汚かった」事故が必ず起き、カットオーバーが3〜6ヶ月延びます。回避策:Phase 1のDQAで定量化された汚染度に基づき、Phase 2の体制と期間を確実に確保する。
失敗2:移行データ量の過小見積もり
「マスタ1万件と聞いていたが、実は隠れマスタを含めて5万件」「取引履歴は直近3年と思っていたが、税務要件で過去7年が必要」という事故。回避策:DQAで全マスタ・全テーブルの実件数をカウント。「実件数 × 移行ジョブ時間」を実測したパイロット移行で本番見積を確定する。
失敗3:過去データの全件移行
「念のため過去10年分全部移行しよう」と決めて、移行に6〜12ヶ月かかる事故。実際の業務利用範囲は直近3年程度で、過去データは参照系の別データベースに退避して、新ERPから検索だけできれば十分なケースが大半。回避策:「業務利用」「税務保存」「監査対応」「分析用」で必要保持期間を分け、新ERPに入れるのは業務利用範囲のみに絞る。
失敗4:並行運用の業務負荷過小見積もり
フル並行運用を選んだ結果、業務部門の入力工数が1.5〜2倍になり、現場が回らなくなる事故。月末月初の決算業務が両ERPで二重実施され、経理部の残業時間が3〜4倍になることも。回避策:パターンB(段階並行)を第一候補に、フル並行は1ヶ月限定で設計。並行運用期間中の業務部門の追加人件費を、最初からプロジェクト予算に組み込む。
失敗5:マッピングルールの文書化不足
「旧の項目Aを新の項目Bに移し、Cが10未満なら0埋め」のような変換ルールを口頭・属人で運用し、文書化していない事故。本番後に「なぜこの数字が違うのか」を追えなくなり、監査対応で大きく時間を取られます。回避策:項目マッピング表をスプレッドシート+Wikiで管理し、レビュー履歴と承認者を明記。マッピングの変更は必ず文書化された手順で。
失敗6:カットオーバー後のサポート体制不足
本番切替直後の1〜2週間は、業務部門から「これどうやって入力するの?」「データが見つからない」という問い合わせが集中します。サポート体制を組まずに切替すると、情シスの電話対応が業務を停止させる事故が起きます。回避策:カットオーバー前後の2週間は、業務部門の現場に情シス・ベンダー担当者を常駐配置。FAQと操作マニュアルを事前配布。
8. ERP移行後の継続マスタ統合戦略
移行プロジェクトが終わってもデータ統合の課題は続きます。新ERPと既存のSalesforce・kintone・会計SaaS等との連携をどう維持するか、移行直後から設計しておくべきです。とくに「ERP本体はSAP/Oracle/NetSuite等の重い基幹系、フロント業務はSalesforceやkintone」というハイブリッド構成では、マスタ同期の継続運用が課題になります。
当社では、kintoneプラグイン形式の Salesforce 連携プラグイン を提供しており、ERP移行後のフロント業務(営業・受発注・問合せ)でのデータ運用を、kintoneとSalesforce間で双方向同期します。移行時の重複統合ルールを継続適用できるため、せっかくクレンジングしたマスタが運用2年目で再び汚れる事態を防げます。
データ統合のツール選定全般については以下の記事も参考になります。
データ統合ツール 比較|ETL・iPaaS・役割分担でコストダウンを実現する選定ガイド
9. まとめ:ERPデータ移行の成否を分ける3つの原則
本記事で扱った内容を、現場の意思決定に直結する3原則として整理します。
- 原則1:マスタクレンジングを先送りしない。プロジェクト最初の30日でDQAを実施し、Phase 2に必要な期間と体制を確実に確保する。
- 原則2:移行ツールは「ERP標準+汎用ETL」の組み合わせを第一候補に。社内IT人材と移行データ量で具体ツールを決める。
- 原則3:並行運用はパターンB(段階並行)を基本に、フル並行は1ヶ月限定で設計。業務部門の負荷増を予算に組み込む。
そして、移行プロジェクトが終わった後の「データ統合の継続運用」までを最初から見据えること。これを怠ると、せっかくの移行効果が運用2年目で薄まります。
10. よくある質問(FAQ)
Q. ERP移行プロジェクトの期間はどのくらいが標準ですか?
年商規模で大きく変動します。10億円規模で9ヶ月、50億円規模で12ヶ月、500億円超で18-24ヶ月が典型値。データ移行はこの期間の60-70%を占めるため、移行作業だけで最短6ヶ月以上は見込んでください。
Q. 過去データは何年分移行するべきですか?
業務利用は直近3年、税務保存は法定の7年、分析用は10年が一般的。すべて新ERPに入れる必要はなく、税務・分析用は新ERP外の別データストア(DWH・アーカイブ)に退避し、必要時に検索できる構成が現実的です。
Q. 移行ツールは内製で運用できますか?
Excel/CSV+ERP標準ツールであれば内製可能。Informatica/DataSpider等の汎用ETLは、初期構築をベンダー支援、運用フェーズで内製、という分業が多いです。社内にSQL+スクリプトを書ける人材がいるかが分かれ目です。
Q. マスタクレンジングは業務部門と情シス、どちらが担当すべきですか?
業務部門が主担当、情シスがツール・データ抽出を支援するのが原則。「廃止するか残すか」「重複をどう統合するか」の判断は業務ルールであり、情シスでは決められません。業務部門に専任担当を置けるかが、プロジェクト成功の鍵です。
Q. 並行運用なしで切り替える(Big Bang)リスクは?
本番切替後にデータ不整合が発覚した場合、業務が停止します。中小企業で連休中に切替するなど、業務停止許容期間を確保できるケース以外は推奨しません。大企業は法令・株主・取引先への影響もあるため、必ず並行運用を組み込みます。
Q. 移行プロジェクトでベンダーを選ぶ基準は?
3つの軸で評価します。(1) 同じERPでの移行実績件数、(2) マスタクレンジング工数の見積もり根拠の明確さ、(3) 並行運用支援の体制有無。とくに(2)で「経験則で○○人月」とだけ答えるベンダーは要注意です。汚染度の定量化に基づく見積もりが提示できるベンダーを選んでください。
関連ピラー
- 【完全マスター】Microsoft Access 移行ガイド 2026
- 【完全マスター】ERP移行 完全ガイド 2026
- データ統合ツール 比較|ETL・iPaaS・役割分担でコストダウンを実現する選定ガイド
- Salesforce×kintone連携 完全ガイド|方式・主要ツール7選比較・コスト試算
ERP データ移行プロジェクトで AI ツールをマスタクレンジングやマッピング設計に活用する場合、旧 ERP の取引先・品目マスタをどの範囲で AI に読み込ませるか、変換スクリプトの実行ログをどう保持するかが内部統制の確認ポイントになります。移行ツール選定から AI 活用を組み込んだ並行運用設計まで、自社環境に合わせた進め方は Claude Code 導入支援 でもご相談いただけます。