帳合システムのデータ移行手順とは？対象データの整理から自動・手動の判断、本番切替の検証基準まで

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

B2B EC-COLUMN

帳合システムのデータ移行、まず何から手を付けるべきか

新しい帳合システムの稼働日が決まり、旧システムに入っている取引先マスタや商品マスタ、まだ出荷していない受注残をどう移すか、手が止まっていないでしょうか。
旧システムから出力して新システムに取り込むだけと考えて着手すると、取引先コードの重複や単価の例外が後から出てきて、売掛金残高が合わないまま月末を迎えることになりがちです。
進め方としては、移行対象データの洗い出しと整理、移行方式が自動ツールか手動かの選定、リハーサルでの突合、並行稼働を経た本番切替という順序になります。
この骨格は複数の一次情報で共通しており、あとは自社のデータ量と例外処理の多さに応じて各段階の中身を具体化していくことになります。

移行作業の全体の流れ

帳合システムは、取引先や仕入先のルート、その上で流れる受発注を管理する仕組みです。
移行を任された段階で困るのは、作業そのものの難しさよりも、何から手を付ければ後戻りしないのかが見えないことではないでしょうか。
幸い、移行手順を示した資料は複数あり、発行元も対象システムも違うのに、並べてみると骨格がよく似ています。

ERPベンダーのGRANDITは、データ移行を移行対象データの選定、移行先仕様の確認、移行方式の決定、移行ツールの選定、移行計画の策定、移行リハーサルの実施、本番移行という7つのステップで示しています¹。
一方、受発注管理システムの移行支援を行うriplaは、現行システムの仕様とデータ構造の棚卸しから始め、移行計画の策定、ETL基盤の選定と変換ルールの実装、リハーサル、並行稼働という流れを示しています²。

ステップの区切り方と呼び方は違いますが、どちらも「いま何があるかを把握する」「どうやって運ぶかを決める」「本番前に一度やってみる」「旧システムと並べて動かしてから切り替える」という順番で並んでいます。
つまり、最初に手を付けるべきは移行ツールの選定でもスケジュールの作成でもなく、旧システムに何がどういう形で入っているかを確かめる作業です。

ただし、ここで挙げた2件はいずれも特定の帳合システム製品の公式な移行手順ではありません。
GRANDITはERP導入時のデータ移行一般を扱った内容であり¹、riplaは受発注管理システムに絞った実務の流れです²。
自社が導入する製品のベンダーから移行手順書が出ている場合は、そちらの指定を優先したうえで、抜けている観点をこの骨格で補うという読み方が現実的です。

各段階で確認すべきこと

全体の流れを押さえたうえで、見落としやすいのが移行先仕様の確認が早い位置に置かれている点です¹。
移行対象を選んだ直後、まだツールも計画も決めていない段階で、新システム側がどんな形のデータを受け付けるのかを確かめておく、という順序になっています。

これは、旧システムの中身だけを見て移行対象を固めても、新システムに入らない形であれば作業が振り出しに戻るためです。
たとえば取引先コードを旧システムでは8桁で運用していたのに、新システムの取引先コードが6桁までしか持てないとすれば、コードの付け替えという作業が丸ごと増えます。
商品コードの体系、単価を取引先別に持つのか商品別に持つのか、納期や締め日をどの単位で保持するのかといった点も、後から気づくと変換ルールの作り直しにつながります。

棚卸しの側も、項目名を一覧にするだけでは足りません²。
旧システムからどの形式で出力できるのか、出力に件数の上限はあるのか、画面には出ているのに出力に含まれない項目はないのか。
ここが曖昧なまま計画を立てると、移行直前になって「その項目は手で拾うしかない」と判明します。

移行計画の策定では、作業の担当と日程に加えて、どの時点のデータを移すのかという基準日を決めておくことになります¹。
受発注は日々動き続けるため、基準日を決めずに作業を始めると、抽出した後に発生した受注をどう扱うかが宙に浮きます。
同時に、今回は移行しないと決めたデータについても、なぜ移行しないのか、代わりにどこで参照するのかを記録に残しておくと、後の節で触れる取りこぼしの防止につながります。

移行前に洗い出し・整理しておくべきデータとは

マスタデータとトランザクションデータの違い

移行対象を洗い出すとき、旧システムの画面やテーブルを順に眺めていくと、どこまでが対象なのか判断が付かなくなります。
GRANDITは移行対象となるデータを、製品や取引先のマスタのように変わりにくい基本情報であるマスタデータ、受注や発注、売上といった取引実績であるトランザクションデータ、仕訳ルールや承認フローなど業務ルールを定義する設定データの3種類に分類しています¹。

この分け方が役に立つのは、種類によって移行のしかたも難しさも変わるからです。
マスタデータは件数が多くても形が揃っていることが多く、整理さえ済めば機械的に運びやすい性質があります。
トランザクションデータは日々増え続けるため、どこで区切るかという判断が必要になります。
設定データは値そのものを運ぶというより、新旧で仕組みが違えば同じ形では持ち込めないため、移行先の仕様確認と一体で考える対象になります。

帳合システムに引き付けると、洗い出す範囲はもう少し具体的になります。
riplaは受発注管理システムの移行対象として、受注履歴、発注履歴、取引先マスタ、商品マスタ、単価マスタ、与信情報、取引条件を挙げ、これらを全件移行するかどうかは業務継続性で判断するとしています²。
単価マスタや与信情報、取引条件は、取引先ごとに例外を抱えやすく、後から「この取引先だけ別の条件だった」と出てくる部分でもあります。
項目名は製品によって呼び方が変わるので、自社の帳合システムでこれに相当するものがどこに入っているかを読み替えながら確認していくことになります。

取引先マスタ・商品マスタの名寄せ・重複統合

洗い出しが済んだら、どこから整理するか。
riplaは販売管理システムの移行について、マスタデータの名寄せと重複統合を最優先で行い、取引先マスタの重複統合や商品コードの体系変換を経てから、受注残や未出荷のデータを移行する順序を示しています³。
名寄せとは、同じ実体なのに別々に登録されているデータを突き合わせて一つにまとめる作業のことです。

この順序に理由があるのは、受注残が取引先と商品を指し示しているからです。
仮に、同じ取引先が本社と支店で別コードとして登録されていて、担当者が変わったときに新しいコードを作ってしまった履歴があるとします。
この状態で受注残を先に移してしまうと、統合後に「どちらのコードにぶら下げるべきか」を一件ずつ判断し直すことになります。
先にマスタを整えてから取引を載せれば、この二度手間は起きません。

商品コードの体系変換も同じ構図です。
旧システムの商品コードに、途中から桁数や採番ルールを変えた跡があると、新システムの体系へ機械的に置き換えられない行が残ります。
変換表を作って一対一で対応させ、対応が付かない行を先に潰しておかないと、その後の工程で同じ行が何度も引っかかります。

整理の過程では、統合してよいのか判断が付かない組み合わせも出てきます。
名前はほぼ同じだが住所が違う、取引条件だけが異なる、といったものです。
この判断は移行担当者だけでは決められないことが多く、営業部門や与信を管理している部門に確認する時間をあらかじめ見込んでおくほうが、日程は現実に近づきます。

過去データはどこまで移行するか

取引履歴をどこまで運ぶかは、移行の作業量を大きく左右します。
全件移行するかどうかは業務継続性で判断するというのが基本的な考え方です²。
つまり、過去のデータがなくなったとき、明日からの業務が止まるのかどうかが分かれ目になります。

目安として示されているものもあります。
riplaは販売管理システムの移行について、直近1〜2年分の月次集計データ、具体的には取引先別売上と商品別売上を新システムへ移行するのがよいとしています³。
これは明細を全件運ぶのではなく、集計された形で持ち込むという考え方です。
販売管理システムを対象にした目安なので、帳合システムで前年同月比や取引先別の実績をどう使っているかによって、必要な粒度は変わります。

判断のしかたとしては、その履歴を誰がいつ見るのかを具体的に思い浮かべると決めやすくなります。
毎月の与信判断や単価交渉で前年の取引実績を参照しているなら、その参照に耐える粒度が必要です。
逆に、数年に一度の問い合わせ対応でしか開かないものであれば、新システムに載せるより、旧システムの参照環境や出力したファイルで確保するという選び方もあります。
どちらを選ぶにせよ、移行しないと決めたデータについて、代わりにどこを見ればよいのかを関係者へ伝えておくことが前提になります。

移行方式は自動変換ツールと手動移行のどちらを選ぶか

自動移行ツール(ETLツール)が向くデータ

自動で移すか手で入れ直すかは、移行全体で一つに決めるものではありません。
データの種類ごとに向き不向きが分かれ、同じプロジェクトの中で両方を使い分けることになります。

GRANDITは、大量データや反復登録にはベンダーが用意する移行ツールや連携可能なETLツール経由で登録し、それ以外はアプリケーション外の個別対応で登録するという使い分けを示しています¹。
ETLとは、旧システムからデータを抽出し、新システムの形式に変換し、登録するという一連の処理をまとめて担う仕組みのことです。
riplaの手順でも、ETL基盤の選定と変換ルールの実装が計画策定の次の工程に置かれています²。

自動化が効くのは、件数が多く、一件ごとの形が揃っているデータです。
取引先マスタや商品マスタは、数千件、数万件になっても変換ルールは同じものを使い回せます。
人が入力すれば時間もかかり、打ち間違いも一定の割合で混ざりますが、ルールを一度作ってしまえば、同じ処理を何度でも同じ結果で流せます。
リハーサルを複数回行う前提に立つと、この「何度でも同じ結果で流せる」という性質自体が重要になります。

ただし、自動移行ツールが旧システムのどの出力形式に対応するのか、一度に扱える件数の上限はどこかは、製品ごとに異なります。
今回確認した2件の資料は方式の考え方を示すものであって、特定の帳合システム製品の対応範囲を保証するものではありません。
旧システムの出力サンプルを用意したうえで、導入するベンダーに読み込めるかどうかを個別に確認する必要があります。

手動移行を選ぶべきケース

一方で、自動化しないほうが安全なデータもあります。
riplaは、受注残データについて、件数が限られる場合は自動変換より手動で確認しながら登録し直すほうが安全なケースがあるとしています³。

受注残は、まだ納品も請求も終わっていない、現在進行中の取引です。
分割で納品する約束になっている、今回だけ特別な単価が適用されている、納期の調整が電話でのやり取りだけで確定しているといった事情が、データの形に表れていないことがあります。
変換ルールは、データに書かれていることしか運べません。
件数が数十件程度に収まるのであれば、一件ずつ内容を見ながら登録するほうが、こうした事情を拾いながら進められます。

ここから導けるのは、件数の多さと例外の多さという二つの軸で見るという考え方です。
件数が多く形が定型的なものは自動、件数が限られていて一件ごとの事情が濃いものは手動、という置き方になります。
マスタは前者に寄り、進行中の取引は後者に寄る、というのが目安です。

手動を選んだ場合も、入力したら終わりではありません。
元の一覧と登録後の一覧を件数と金額で突き合わせる、入力者とは別の人が確認する、といった段取りを移行計画に組み込んでおくと、次の節で触れる残データの不整合を早い段階で見つけられます。
自動と手動のどちらを選んでも、突合の工程そのものを省くことはできません。

移行作業で起きやすい失敗とその防ぎ方

マスタ整理を後回しにした結果の手戻り

ここまでの順序を守るのが難しいのは、マスタの整理が地味で、しかも他部門への確認を伴うからです。
先に見える成果が出る作業を優先したくなりますが、riplaは、API設計とマスタデータの名寄せ・クレンジングを開発初期の段階から着手せず後回しにしたプロジェクトは、最終フェーズで大きなトラブルにつながりやすいとしています²。

後回しにしたときに何が起きるかは、これまでの説明からも想像が付きます。
変換ルールを作り込んだ後で取引先の統合が決まれば、そのルールと、ルールを使って動かしたリハーサル結果の両方をやり直すことになります。
しかも、こうした決定が出てくるのは移行の終盤、すでに稼働日が公表された後であることが多く、日程の余裕が最も少ない時期に作業が集中します。

防ぎ方は単純で、整理を先に済ませることに尽きます。
判断に他部門の確認が要る項目は、洗い出しの段階で一覧にして依頼を出し、返答の期限を移行計画の中に置いておく。
返答が揃わない項目がどれだけ残っているかを、日程の進み具合とは別に数えておくと、終盤に何が残るのかが早い段階で見えます。

残高・残データの不整合

移行が終わった後に表面化する失敗として、riplaは、売掛金残高のズレによる月次決算遅延、受注残データの消失による出荷停止、入金伝票を移行対象から外したことによる不一致を挙げています³。
いずれも、移行作業そのものが失敗したというより、移した結果が業務の数字と合わなかったという形で現れます。

売掛金残高のズレは、月次決算の段階で見つかります。
その時点では新システムがすでに動いているため、原因を探りながら通常の締め作業も進めるという状態になり、遅延が生じます。
受注残の消失は、もっと早く、しかも取引先に見える形で現れます。
出荷の指示が出せなければ、その日の出荷が止まります。

この二つに共通するのは、移行した件数が合っていても金額が合わない、あるいは金額が合っていても状態が合わないという性質です。
件数だけを確認して完了としないこと、そして残高や未処理の件数といった業務側の数字で突き合わせることが、リハーサルで確かめるべき内容になります。
突合の対象をどの数字にするかは、移行方式を決める段階で併せて決めておくと、リハーサルの手戻りが減ります。

対象データの取りこぼし

入金伝票を移行対象から外したことによる不一致は、少し性質が違います³。
これは変換の誤りではなく、そもそも対象として認識していなかったために起きています。

受発注を中心に考えていると、注文と出荷までは丁寧に洗い出せても、その後段にある入金や消込は視野の外に出やすくなります。
しかし売掛金の残高は、売上と入金の両方が揃って初めて正しい値になります。
片方だけを移せば、移行直後から残高が合わないことになります。

取りこぼしを防ぐには、データの一覧を眺めるのではなく、業務の流れに沿って追いかけるほうが確実です。
見積から受注、出荷、売上計上、請求、入金、消込という順に、それぞれの段階で作られる記録が新システムのどこに入るのかを対応させていくと、途中で行き先のない記録が見つかります。
そのうえで、移行しないと決めたものは対象外として理由とともに書き出しておくと、後から「入っていない」と言われたときに、判断漏れなのか意図した除外なのかがすぐ分かります。

なお、ここで挙げた失敗はいずれも支援会社1社が実務の経験から示したものであり、どのくらいの頻度で起きるかを統計的に示したものではありません²³。
自社で起こりやすいのはどれかを見極めるには、旧システムで日常的に手作業の補正が入っている箇所を洗い出しておくのが手がかりになります。

移行後、本番切替前にどのような検証を行うべきか

リハーサルの回数と合格基準

移行の手順を示した資料が揃って本番移行の手前にリハーサルを置いているのは、一度で成功する前提を取っていないからです¹²。
riplaは、最低2回はリハーサルを行い、2回目でエラーゼロを確認してから本番に臨むことを推奨しています²。

回数が意味を持つのは、1回目と2回目で目的が違うからです。
1回目は、変換ルールが通らない行、必須項目が埋まらない行、桁があふれる行を洗い出すために流します。
ここでエラーが多く出ること自体は想定内で、問題はその後に修正が反映されたかどうかです。
2回目は、修正が効いたかを確かめる回になります。
ここでエラーが残るなら、まだ本番を迎える段階ではないという判断材料になります。

そのため、リハーサルを始める前に、何をもって合格とするかを決めておく必要があります。
エラー件数がゼロであることに加えて、前の節で触れたように、件数と金額の両方で旧システムと一致するかを確認の対象に入れておく。
基準を決めずに流すと、出てきた結果を見て「このくらいなら本番で直せる」と判断してしまい、切替後に同じ差異を業務の中で処理することになります。

並行稼働の期間と確認項目

リハーサルでエラーがなくなっても、そこで確かめられたのはデータが運べたことまでです。
運んだ先で日々の業務が回るかどうかは、旧システムと新システムを並べて動かす並行稼働で確認することになります。
riplaは販売管理システムの移行について、6〜8週間の並行稼働期間を設けることが多いとしています³。

この長さには意味があります。
受発注の日常業務は数日あれば一通り試せますが、売掛金の残高が正しいかどうかは月次の締めを通さなければ分かりません。
数週間の幅を取るのは、締め処理を含んだ一巡を新システム側でも経験するためです。
前の節で見た、月次決算の段階で残高のズレが見つかるという失敗は、まさにこの一巡を切替後に初めて通したときに起きます。

並行稼働の期間は、対象となるシステムの複雑さや移行のリスクによって幅があります。
同じ発行元の資料でも、受発注管理システムを対象にした場合と販売管理システムを対象にした場合とで示される目安は異なっており²³、単一の正解値があるわけではありません。
帳合システムで扱う取引条件や与信の例外が多いほど、確認に必要な時間は延びると考えたほうが無難です。

切替の可否をどう判断するかについては、riplaが具体的な基準を示しています。
売掛金残高の一致率が100%、つまり1円単位で一致していること、そして日次の受注処理・出荷処理の業務時間が旧システム比で120%以内に収まっていることです³。
残高を1円単位で見るのは、差額が小さいからといって丸めてしまうと、原因が別のところにある可能性を見逃すためです。
差額の大小は手がかりにはなりますが、それだけで原因を決めつけず、どの取引先のどの伝票で差が出ているかを明細まで下りて照合することになります。

業務時間を120%以内という形で見るのは、移行直後には操作の慣れの問題で時間がかかるのが当然だからです³。
旧システムと同じ速さを求めれば、いつまでも切替はできません。
逆に、この範囲を大きく超えているなら、慣れの問題ではなく、運用の手順やマスタの持ち方に無理がある可能性を疑う場面になります。
基準を満たさない項目が残っているなら、切替を急がず、原因を特定してから日程を引き直すという判断も選択肢に入ります。

移行の骨格は資料から掴めても、自社の取引先マスタにどれだけ重複があり、受注残のうち何件が例外を抱えているかは、実際のデータを見なければ分かりません。

現在お使いの帳合システムから出力できる項目とその形式をご提示いただければ、どこから整理を始めると手戻りが少ないか、自動で運べる範囲と手で確認したほうがよい範囲の当たりを一緒に整理できます。無料相談で要件を整理する

本番切替前チェック項目の目安

販売管理システムの移行で本番切替の可否を判断する際に見る項目を、残高が正確に引き継げているかと、日常業務が回る速さに戻っているかという二つの観点で並べています。

• 売掛金残高の一致率が100%であること（1円単位で一致）

• 日次の受注処理・出荷処理の業務時間が旧システム比で120%以内に収まっていること

• 並行稼働期間として6〜8週間を確保し、その間の処理を旧システムと突き合わせること

帳合システムで取引先ごとの取引条件や与信の例外を多く抱えている場合は、残高と業務時間に加えて、例外的な条件の取引が新システムでも同じ結果になるかを確認項目に足す判断になります。

要点の整理

判断の場面	押さえておくこと
着手の順序	洗い出しと棚卸しから始め、移行先の仕様確認を早い段階で済ませる
整理の優先順位	取引先・商品マスタの名寄せと重複統合を先に終えてから受注残を移す
移行方式の選び方	件数が多く定型のデータは自動、件数が限られ例外が濃いデータは手動
失敗の予防	業務の流れに沿って対象を追い、移行しないものは理由とともに残す
切替の判断	リハーサル2回目でエラーゼロ、並行稼働で残高と業務時間を確認

本番切替の可否は、残高が合うかどうかだけでなく、日々の受注処理が現場の手に馴染む速さで回るかまで見て決めることになります。 並行稼働で何を突き合わせ、どの数字が揃えば切り替えてよいと判断するのか、自社の締め処理や与信の運用に合わせた確認項目の立て方をご相談いただけます。

よくある質問

帳合システムのデータ移行にかかる期間はどれくらいを見込めばよいか

全体の期間を一律に示せる目安は、今回確認した資料の中にはありません。
ただし後ろの工程から逆算することはできます。
並行稼働は販売管理システムの移行で6〜8週間を設けることが多いとされ³、その前にリハーサルを最低2回行い、2回目でエラーゼロを確認してから本番に臨むことが推奨されています²。
1回目のリハーサルで出たエラーを修正する時間も必要なので、リハーサル開始から切替までだけで数か月規模になります。
これに先立つ洗い出しとマスタの名寄せは、他部門への確認を伴うため日程が読みにくく、ここをどれだけ早く始められるかで全体の長さが変わります。

移行作業はベンダーに依頼すべきか、自社だけで対応できるか

分担の考え方として、判断が必要な部分と、仕組みで処理する部分を分けると整理しやすくなります。
取引先マスタのどのコードとどのコードを統合するか、過去の実績をどこまで残すかといった判断は、業務の事情を知っている自社側でしか決められません。
一方、自動移行ツールが旧システムの出力形式に対応するか、一度に扱える件数の上限はどこかは製品仕様に依存するため、導入するベンダーへの確認が前提になります¹。
出力サンプルを用意して読み込めるかを早い段階で確かめておくと、自社で担える範囲と依頼すべき範囲が具体的に見えてきます。

過去の取引履歴は何年分を移行すればよいか

全件移行するかどうかは業務継続性で判断する、というのが基本的な考え方です²。
目安としては、販売管理システムの移行について直近1〜2年分の月次集計データ、具体的には取引先別売上と商品別売上を新システムへ移行するのがよいとされています³。
明細を全件運ぶのではなく集計した形で持ち込むという考え方なので、自社で前年実績をどの粒度で使っているかに合わせて読み替える必要があります。
新システムに載せないと決めたものについては、旧システムの参照環境や出力したファイルなど、代わりにどこを見るのかを関係者に伝えておくことが前提になります。

移行後、旧システムはいつまで残しておくべきか

少なくとも並行稼働の期間中は、突合の相手として旧システムが動いている必要があります³。
切替後にいつまで残すかについて数値の目安は確認できていませんが、判断の手がかりはあります。
一つは、新システムに移行しなかったデータをどこで参照するかで、旧システムでしか見られないなら、その参照が不要になるまで残す必要が出てきます。
もう一つは、売掛金残高のズレのように月次の締めを通して初めて見つかる不整合があるため³、原因を追うときに旧システムの明細を照合できる状態を確保しておくと確認が早く済みます。
保存義務のある帳票の扱いは、自社の保存方針と照らして別途確認してください。

1. 1　出典：GRANDIT株式会社「「データ移行」がERP導入成功の鍵！失敗しないための5つの鉄則とチェックリスト」（2026年）
2. 2　出典：株式会社ripla「受発注管理システム連携・移行で失敗しない5ステップ【担当者向け】」（2026年）
3. 3　出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年）