受発注システムのデータ移行手順｜5工程と法令要件

◆監修・編集責任者　小園 将隆　2026年8月17日

B2B EC-COLUMN

受発注システムのデータ移行とは ― 5工程で進める標準プロセス

受発注システムのデータ移行とは、旧システムが保持する取引先・商品・価格・受注などのデータを新システムの項目定義に合わせて抽出・変換・投入する作業です。投入後に内容の一致を確認するところまでを含みます。IPA（独立行政法人情報処理推進機構）はこれを非機能要求の6大項目の1つ「移行性」と位置づけています^*1。

受発注システムのデータ移行とは、旧システムの項目を新システムへ移し替え一致を確認する作業である

データ移行は、単にファイルをコピーする作業ではありません。旧システムの取引先マスタ・商品マスタ・受注履歴などを、新システムが定義する項目に合わせて変換し、投入後に内容が一致していることを確認するまでが移行の範囲です。IPAの非機能要求グレード2018は、この一連の作業を「移行性」という非機能要求の大項目に置いています^*1。そのうえで、移行データ量・移行データ形式・変換ルール数・リハーサル回数・ユーザーとベンダーの作業分担といった項目で具体化することを求めています^*1。

手順は5工程 ― 棚卸から本番移行・検収まで

本記事では、①移行対象の棚卸と範囲確定、②移行方式と時期の決定、③変換設計、④移行リハーサル、⑤本番移行と突合・検収、の5工程に沿って解説します。各工程で「決めること」「作るもの」「確認すること」を具体的に示し、抽象的な段取り論では終わらせません。

BtoC ECのデータ移行と何が違うのか ― 取引条件が取引先ごとに異なる

BtoC ECのデータ移行は、主に会員情報・商品情報・注文履歴を対象とします。これに対し受発注システムでは、取引先ごとに価格・掛率・与信枠・締め日・支払条件が異なります。旧システムでは備考欄や手運用で吸収していたこれらの条件が、移行の過程で初めて表に出てくる点が、BtoB特有の難しさです。

移行は「非機能要求」である ― IPAは移行性を6大項目の1つに置いている

IPAの非機能要求グレード2018は、非機能要求を6大項目で整理しています^*1。可用性・性能/拡張性・運用/保守性・移行性・セキュリティ・システム環境/エコロジーであり、移行性はその1つです。移行を「後工程の作業」ではなく「事前に要件として合意すべき項目」として扱う枠組みであり、本記事はこの分類を骨格に据えます。

なお、国内のBtoB-EC市場規模は514兆4,069億円、EC化率は43.1%（2024年）に達しています^*6。既存システムからの移行需要は、今後も一定規模で発生すると見込まれます。

受発注システムの入れ替え全体の段取りは、リプレイス全体の6ステップを整理した別記事で解説しています。本記事はそのうちのデータ移行工程を1本に展開したものです。

工程1 移行対象データの棚卸と範囲確定

最初の工程は、何を移行するかを項目レベルで洗い出すことです。抽象的に「マスタとトランザクションを移す」で止めると、後工程で漏れが発覚します。

受発注システムで移行対象になる7項目

受発注システム固有の移行対象は、次の表の粒度まで下ろして棚卸します。

何年分を移すか ― 全件移行は前提ではない

受発注データの移行で最も迷いやすいのが、過去の受注データを何年分移すかという判断です。国税庁の電子帳簿保存法一問一答（令和7年6月）は、電磁的記録の検索機能についてこう回答しています^*3。「変更前のシステムを用いること等により検索機能が確保されているのであれば、現在使用しているシステムにより検索ができなくても差し支えありません」^*3。この回答は検索機能の確保についてのものであり、過去データの保存要件そのものを免除するものではありません。ただし、旧システム側で検索機能を確保する選択肢がある以上、新システムへ全件を移行することが前提条件ではないという設計上の含意を読み取れます。

「移行しない」と決めたデータをどう扱うか

移行しないと判断したデータは、消去するのではなく、旧システムを参照専用として残すか、検索可能な形式で出力・保存する対応が現実的です。国税庁の一問一答も、変更前システムでの検索機能確保を選択肢として示しています^*3。

棚卸の出力は3つの数字になる

棚卸の結果は、最終的に移行データ量・移行データ形式・移行媒体種類数という3つの項目に整理されます^*1。移行データ量はレベル区分として1TB未満・1PB未満・1PB以上という3段階が示されており^*1、この段階に応じて移行方式やリハーサルの規模も変わってきます。

移行対象データの範囲を要件定義書やRFP（提案依頼書）にどう書くかは、RFPの作り方を扱う別記事で解説しています。

中項目	小項目の例	自社で決めること
移行時期（D.1）	システム移行期間、システム停止可能日時、並行稼働の有無	いつまでに、どのタイミングで移すか
移行方式（D.2）	拠点展開ステップ数、業務展開ステップ数	段階的に移すか、一斉に移すか
移行対象・機器（D.3）	設備・機器の移行内容	端末・周辺機器も含めて移行するか
移行対象・データ（D.4）	移行データ量、移行データ形式、変換ルール数	何を、どの形式で、どれだけ変換するか
移行計画（D.5）	リハーサル範囲・環境・回数、作業分担	誰が何を確認し、何回試行するか

工程2 移行方式と時期の決定

移行対象が固まったら、次に移行の方式と時期を決めます。ここでの決定が、後続のリハーサル計画や本番移行の体制に直結します。

決めるべきは3つ ― 移行期間・停止可能日時・並行稼働の有無

IPAの非機能要求グレード2018は、移行時期に関する項目として、システム移行期間・システム停止可能日時・並行稼働の有無の3点を挙げています^*1。受発注システムの場合、停止可能日時は締め請求のタイミングと直結するため、業務部門との合意が欠かせません。

段階的に移すか、一斉に移すか

移行方式は、拠点展開ステップ数・業務展開ステップ数という考え方で整理できます^*1。業務展開ステップ数のレベル区分は4段階未満・6段階未満・10段階未満・10段階以上という4段階が示されており^*1、対象拠点や業務範囲が広いほど段階数は増えます。段階を増やせば1回あたりのリスクは下がりますが、並行稼働の期間が延び、運用負荷は増える傾向があります。なお、並行稼働そのものの設計や切替（カットオーバー）の詳細な手順は、本記事の範囲外としています。

切替日は締め請求サイクルから逆算する

受発注システムの切替日は、月次の締め日・請求サイクル・繁忙期を踏まえて逆算するのが実務上の基本です。締め処理の最中に切り替えると、請求データの整合性確認が複雑になるため、締め処理が完了した直後のタイミングを選ぶ運用が現実的です。

工程3 変換設計 ― 項目とコード体系の対応づけ

変換設計は、データ移行の中核をなす工程です。旧項目と新項目をどう対応させるかを決めなければ、投入作業に着手できません。

項目対応表（マッピング表）を作る

旧項目・新項目・変換ルール・変換不能時の扱いを1行ずつ整理した対応表を作成します。以下はひな型の例です。

旧システムの備考欄・手運用に埋まった条件が、ここで初めて表に出る

取引先ごとの特別な価格条件や例外運用は、旧システムでは備考欄や担当者の手運用で吸収されているケースがあります。変換設計の段階でこれらを1つずつ拾い上げないと、新システムの項目に収まらないまま移行後にトラブルとして表面化します。

取引先コード・商品コードをどう揃えるか

コード体系の統一方針も、移行時にしか決められない判断の1つです。選択肢の1つとして、GLN（企業・事業所識別コード。国内外の企業間取引で組織や場所を一意に識別するGS1識別コード）があります^*5。GLNは、GS1事業者コード・ロケーションコード・チェックデジットから成る13桁のコードです^*5。事業者・部門・物理的な場所・電子的な場所の4区分を設定対象とし、一般財団法人流通システム開発センター（GS1 Japan）が運営しています^*5。社内採番を維持するか、標準コードへ寄せるかは、取引先数や連携先の多さに応じて判断する選択肢であり、どちらかを一律に推奨するものではありません。

名寄せの判断は業務側が行う

同一取引先の重複登録、旧社名での登録、部署統合後の扱いといった名寄せの判断は、システム側で機械的に決められるものではありません。営業・業務部門が実態を確認したうえで、最終判断する体制が必要です。

変換の複雑さは変換ルール数で見積もる

変換設計の複雑さは、移行ツールの複雑度として変換ルール数で見積もることができます^*1。レベル区分は10未満・50未満・100未満・100以上の4段階が示されており^*1、この数がベンダーの見積もり工数を評価する物差しになります。

移行を内製で対応する場合、旧システムのデータ構造の理解に加え、変換ロジックの設計・検証、業務部門との調整という複数の役割が必要になります。自社の数字でこの工数を確かめるには、無料相談で要件を整理するのが近道です。

工程4 移行リハーサル

移行リハーサルは、本番移行の前に想定される問題を洗い出す工程です。範囲を絞りすぎると、本番でしか気づけない問題が残ります。

リハーサルで決める4つのこと

IPAの非機能要求グレード2018は、リハーサルに関する項目として、リハーサル範囲・リハーサル環境・リハーサル回数・外部連携リハーサルの有無を挙げています^*1。リハーサル回数のレベル区分は1回・2回・3回・4回・5回以上の5段階が示されており^*1、対象データ量や連携先の数に応じて回数を検討します。リハーサル不足のまま本番移行に進むと、受発注データの不整合が業務開始後に判明し、請求誤りや出荷遅延につながりかねません。

本番データを使うかどうか

リハーサル環境の設計では、本番データを使うかどうかも論点になります^*1。取引先担当者の氏名や連絡先は個人データに当たるため、リハーサルで本番データを使う場合は個人情報保護法の観点での確認が必要です。

移行先がクラウドの場合、個人データの委託該当性を判断する

個人情報保護委員会は令和6年3月25日、クラウド利用に関する注意喚起を公表しました^*4。この中で、クラウドサービスの利用が個人データの取扱いの委託（個人情報保護法第27条第5項第1号）に該当するかどうかを判断する必要があると示しています^*4。委託に該当する場合は、委託先に対する必要かつ適切な監督義務を負います（同法第25条）^*4。移行先が新システムのクラウド環境である場合、この判断を移行計画の中で行っておく必要があります。

切り戻しをリハーサルに含めるか

リハーサル範囲を検討する際は、移行後に元の状態へ戻す「切り戻し」の手順を含めるかどうかも合わせて決めます^*1。切り戻しの可否を事前に確認しておくと、本番移行中にトラブルが発生した場合の対応判断が速くなります。

工程5 本番移行と突合・検収

本番移行は、計画どおりにデータが移し終えられたことを確認するまでが工程の範囲です。移行作業が完了した時点で終わりではありません。

最終的な移行結果の確認は、ユーザーが実施する

IPAの非機能要求グレード2018は、移行のユーザーとベンダーの作業分担に関する項目を定めています^*1。そこでは、最終的な移行結果の確認はレベルに関係なくユーザーが実施すると明記されています^*1。移行作業をベンダーに委託していても、確認そのものは発注側の責任で行う前提です。

何を突き合わせるか

突合の観点としては、件数・金額・期間・取引先数を旧システムの帳票と照らし合わせる方法が現実的です。件数だけでなく金額まで一致させることで、変換ルールの見落としに気づきやすくなります。

移行後の初回連携で基準日を合わせる

基幹システムと連携している場合、移行後の初回連携で基準日をどう合わせるかが論点になります。連携方式そのものの詳細は、基幹システム連携を扱う別記事で解説しています。

移行中のトラブルに備える

移行計画には、トラブル対処の規定の有無という項目も含まれます^*1。対応体制と対応方針をあらかじめ規定しておくことで、想定外の事態が起きたときの判断が速くなります。

ユーザーとベンダーの作業分担をどこで線引きするか

作業分担の線引きは、移行データ量・変換ルール数・リハーサル回数といった項目の水準に応じて変わります^*1。分担をあいまいにしたまま進めると、確認漏れの責任の所在が不明確になりやすい点に注意が必要です。

データ移行で外せない法令要件

受発注システムのデータ移行では、電子帳簿保存法と個人情報保護法の要件を踏まえる必要があります。ここでは、税務・法務の個別判断ではなく、確認すべき要件の所在を示します。

電子帳簿保存法 ― 移行時も改ざん防止措置が必要

国税庁の電子帳簿保存法一問一答（電子取引関係、令和7年6月）は、電子データを保存しているシステムを新システムへ変更する場合の措置を回答しています^*2。データ移行に当たっても改ざん防止措置を講ずる必要があります^*2。タイムスタンプを引き継ぐなどの対応ができない場合もあります。その場合でも、データ移行時における訂正削除の防止に関する事務処理規程を制定し遵守すれば、改ざん防止措置の要件を満たすとされています^*2。

ただし留保があります。同じシステムでスキャナ保存データと電子取引データを併せて保存している場合が留意点です。両方のデータをまとめて新システムに移行しようとするときは、この方法は認められないとされています^*2。この留保に該当するかどうかは、移行対象データの種別を工程1の棚卸段階で切り分けておくと判断しやすくなります。

移行前のシステムでの保存要件を説明できるようにしておく

国税庁の一問一答は、移行前のシステムにおいて、どのように電子データ保存の要件を満たしていたのかを説明できるようにしておくことが望ましいとも述べています^*2。移行後に税務調査等で確認を求められた際に備え、旧システムの運用ルールを示す資料を残しておく対応が必要です。

個人情報保護法 ― クラウド移行先の利用は委託に該当するか

個人情報保護委員会の注意喚起は、クラウドサービス提供事業者が個人情報保護法上の個人情報取扱事業者に該当するかどうかの判断基準を示しています^*4。移行先が新システムのクラウド環境である場合、取引先担当者の氏名・連絡先といった個人データの取扱いが委託に該当するかを判断する必要があります。該当する場合は、委託先を監督する義務が生じます^*4。

移行の作業を外部に委託する場合、再委託の連鎖に注意する

個人情報保護委員会の注意喚起は、再委託に関する留意事項にも触れています^*4。移行作業の一部を外部のベンダーへ委託する場合、再委託先まで含めた監督体制を確認しておく必要があります。

内製で対応する場合に必要な知識と、外部委託との違い

データ移行を内製で完結させるには複数の知識が要ります。旧システムのデータ構造の理解、変換ルールの設計・検証スキル、電子帳簿保存法・個人情報保護法の要件確認です。これらを社内の限られた人員で兼務すると、通常業務と並行して進めることになり、進行管理の負荷が高くなります。専門パートナーに依頼する場合は、変換設計とリハーサル計画の立案を分担できる一方、内製の場合は自社の業務知識をそのまま反映しやすいという違いがあります。どちらを選ぶ場合も、リスクを最小化する観点から、移行対象の棚卸だけは自社で丁寧に行うことが前提になります。

まとめ：受発注システムデータ移行の3つの判断軸

本稿では、受発注システムのデータ移行を、IPAの非機能要求グレード2018が定める「移行性」の枠組みに沿って5工程で整理しました。要点を3つに集約すると次の通りです。第一に、移行対象は取引先別価格・与信枠・承認経路といった受発注固有の項目まで下ろして棚卸することです。第二に、過去データの全件移行は前提ではなく、検索機能の確保という選択肢が国税庁の一問一答で示されていることです^*3。第三に、電子帳簿保存法の改ざん防止措置と個人情報保護法の委託先監督という2つの法令要件を、移行計画の初期段階から織り込む必要があることです^*2*4。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

過去の受注データは何年分を移行すればよいですか。

保存すべき年数そのものは、本記事では確認できた一次情報の範囲を超えるため断定できません。ただし、国税庁の一問一答は、変更前のシステムで検索機能が確保されていれば、現在使用しているシステムで検索できなくても差し支えないとしています^*3。この回答をふまえると、全件を新システムへ移行することは前提条件ではなく、旧システムを参照用に残す選択肢もあります。

データ移行にはどのくらいの期間がかかりますか。

期間は移行データ量や取引先数などの個社条件に依存するため、一律の目安は示せません。IPAの非機能要求グレード2018が示す移行データ量・変換ルール数・リハーサル回数といった項目のレベル区分が^*1、見積もりを検討する際の物差しになります。

移行作業はベンダーに任せきりにできますか。

最終的な移行結果の確認は、レベルに関係なくユーザーが実施する項目とされています^*1。作業の一部をベンダーに委託する場合でも、突合・検収の判断そのものは発注側の責任で行う前提です。

移行リハーサルで本番データを使ってもよいですか。

本番データの使用可否はリハーサル環境の設計項目の1つです^*1。取引先担当者の氏名・連絡先などの個人データを含む場合、クラウド利用が委託に該当するかを判断し、該当する場合は委託先を監督する必要があります^*4。

旧システムはいつ止めてよいですか。

停止可否そのものを一律には断定できません。国税庁の一問一答が示す「変更前のシステムで検索機能を確保する」という選択肢を採る場合は^*3、旧システムを参照用として一定期間残す判断もあり得ます。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018 システム基盤の非機能要求に関する項目一覧」（2018年版）
2. *2　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】問92」（令和7年6月）
3. *3　出典：国税庁「電子帳簿保存法一問一答【電子計算機を使用して作成する帳簿書類関係】問14」（令和7年6月）
4. *4　出典：個人情報保護委員会「クラウドサービス提供事業者が個人情報保護法上の個人情報取扱事業者に該当する場合の留意点について（注意喚起）」（令和6年3月25日）
5. *5　出典：一般財団法人流通システム開発センター（GS1 Japan）「GLN（企業・事業所識別コード）」（公式サイト）
6. *6　出典：経済産業省「令和6年度 電子商取引に関する市場調査」（2025年8月26日公表）