切り戻したら、7箱が11箱に。システム移行の前に決める照合と戻し方

たとえば、新システムへ切り替えた30分後、受注画面で不具合が見つかった。その間に入った注文は、旧システムのバックアップには入っていません。旧環境を復元するだけでは、その注文を受ける前の状態に戻ってしまいます。バックアップで何を戻せるかは、失ってよいデータと止めてよい時間から決まります（バックアップと復旧の考え方）。

切り戻しとは、問題が起きたときに旧システムで業務を再開することです。変更分を回収し、旧側へ反映して確かめる時間まで、停止できる時間の中に収めます。

戻した後も3件。ただし7箱が11箱になる

食品卸が9時50分に旧側の入力を止め、照合後の10時に新側の入力を始めます（想定例）。切替時の有効受注は3件、7箱、税別7,000円。各受注は1商品、単価は1箱1,000円で統一します。

10時に新側を開いた後も、受注業務は続きます。新しい注文が一つ届き、別の注文では数量の訂正が入り、もう一つは取り消されました。10時30分に不具合が見つかり、ここで旧側へ戻すと決め、新側の更新を止める想定です。

10時30分は判断と更新停止の期限、11時は旧側での再開を終える期限です。この間に、次の三つの変更を旧側へ反映して確かめます。

受注番号	切替後の変更	旧側へ戻す内容
O1004	新規受注を4箱で追加	同じ受注を重複させず、4箱・4,000円で登録
O1002	3箱を5箱に訂正	元の受注を5箱・5,000円へ更新
O1003	2箱の受注を取消	元の受注を取消にし、有効分の集計から除外

残るO1001は2箱・2,000円で変更なしです。旧側へ反映した後の期待値は、取消を含む全受注4件、有効受注3件、11箱、税別11,000円です。移行前と有効件数は同じでも、数量と金額は変わっています。9時50分のバックアップの7箱・7,000円を、そのまま再開時の正解にしてはいけません。

この例は出荷・通知を保留できる場合です。すでに実行した処理があれば、その記録も回収して再実行を防ぎます。戻すのに必要な時間は、自社の手順とデータ量で測ります。

記入表では「切替直前の7箱が正しく移ったか」と「切替後の変更を含む11箱に戻せたか」を別に記録します。判断者と二つの期限も、自社の停止可能時間に合わせて記入できます。

• 移行照合・切替後差分の記入表（Excel）
• 印刷して記入する（PDF）
• 記入例を見る（PDF）

新規だけ戻すと、11箱でも誤りが残る

2026年10月26日、上のO1001〜O1004と同じ数量を、切り戻し・復元の再現教材（Python）で計算しました。外部システムや顧客データは使わず、架空の受注状態を通常コードで更新しています。

旧側へ戻した内容	有効件数	数量・税別金額	残った誤り
切替前の控えだけ	3件	7箱・7,000円	新規・訂正・取消をすべて失う
新規O1004だけ追加	4件	11箱・11,000円	O1002は3箱、O1003は有効のまま
新規・訂正・取消を反映	3件	11箱・11,000円	この模型では受注ごとの状態も期待値と一致

新規だけ戻す案は、数量と金額が正解と同じです。訂正の増分2箱と、取消の減分2箱が相殺するためです。合計が合っても、O1002の5箱への訂正とO1003の取消が戻ったかを、受注番号で確認する必要があります。

全変更を同じ操作番号でもう一度反映しても、結果は3件・11箱のままでした。同じ番号の内容を99箱へ変えた要求は拒否しています。これはメモリー内の状態更新の確認であり、実際のDB移行・同時更新・切替時間・通知や出荷を検証したものではありません。

移すデータと残すデータを分ける

古いデータをすべて新システムへ入れると、重複や表記揺れまで持ち込みます。日常的に更新するデータ、参照だけする過去データ、保存期限を終えたデータを分けます。

• 現在利用中の顧客、商品、案件、在庫
• 未完了の受注、請求、申請
• 参照用に保管する完了履歴
• ファイルとして別保管する添付資料
• 移行対象外とする一時データ、重複、不要項目

対象外にした理由と閲覧方法も残します。移さないデータが消えたように見えないよう、保管場所と問い合わせ先を決めます。古いという理由だけで削除せず、業務上の参照や保存の要件を確かめてください。

未完了の受注を移すなら、その得意先や商品の情報も参照できる必要があります。受注だけを選んで得意先を除くと、明細があっても宛先を表示できません。対象は表ごとに選ぶとともに、互いの結び付きまで確認します。

変換規則を一項目ずつ固定する

同名の列でも意味を個別に確認します。空欄、文字の幅や表記の揺れ、コード、日付、単位、税込・税別、無効データの扱いを対応表にします。変換できない値は勝手に補わず、エラー一覧へ出して業務担当者が判断します。

たとえば旧側の「数量」が箱数、新側が個数なら、商品ごとの入数を使う変換が必要です。入数が分からない商品は判断待ちとして残し、何を確認すれば移せるかを書きます。日付も、受注日と出荷予定日を取り違えていないか確かめます。

重複した商品コードを一つにまとめる場合は、元のコードと統合先を追えるようにします。対応表には旧項目、新項目、変換規則、確認担当、判断待ちの内容を残します。変換の方法に加えて、未解決のデータを残したまま切り替えてよいかを決めます。

IPAの「ユーザのための要件定義ガイド 第2版」の関連資料は、成果物をプロジェクトの目的や状況に応じて選ぶ考え方を示しています。移行準備でも、対象業務に合わせて照合表と切替手順を選びます（出典：IPA 第4章関連資料（PDF））。

件数だけでなく業務上の総量を照合する

移行前後の行数が一致しても、金額や数量の符号が変わっていれば業務は合いません。照合項目を先に決め、旧側と新側から同じ条件で集計します。

• 対象別の件数
• 数量、金額、残高などの合計
• 状態別の内訳
• 親データに結び付かない明細の件数
• 変換エラー、除外、重複統合の件数

集計の基準日時、対象範囲、取消を含むか、数量の単位、税込・税別をそろえます。旧側を朝、新側を昼に集計すれば、移行の誤りと、その間の業務による増減が混ざります。比較元の出力と条件を保存しておくと、不一致の原因を追えます。

冒頭の例なら、10時の切替時点では7箱が正しく移っているか、11時の再開時点では変更を含む11箱になっているかを確かめます。総量が合っていても、別の得意先へ注文を結び付けている可能性は残ります。受注番号ごとの相手先・商品・明細も、この照合に含めます。

差分がゼロでない場合は、理由と対象を明細で説明できる状態にします。計画どおりの重複統合による件数減少と、原因不明の欠落は別に扱います。誰が、どの対象について差を認めたかを記録し、数量や金額への影響を確認します。

切替条件と切り戻し条件を対で決める

新環境へ切り替える条件だけでなく、旧環境へ戻す判断も事前に決めます。

• 照合差分が合意範囲内であること
• 主要な業務シナリオが完了していること
• 利用者と問い合わせ窓口が準備できていること
• 旧側へ戻せる期限を過ぎていないこと
• 切り戻し判断者と連絡方法が明確であること

当日は、旧側の入力を止め、最後の変更分を取り込み、照合してから新側へ切り替えます。画面入力だけでなく、定期処理や外部連携からの更新も対象です。切替後は新側を入力先とし、旧側は参照用にします。新旧の両方で更新が始まる運用を予定するなら、競合を解消する方法も必要になります。

「戻すかを決める期限」と「旧側で再開し終える期限」は分けてください。停止できる時間から、変更の回収、旧側への反映、照合、再開にかかる時間を引いて判断期限を決めます。再開期限の直前に戻すと決めても、作業が間に合いません。

切替後に入力した分を回収して戻す

戻し方は、切替後にデータが変わったかで異なります。AWSの移行ガイダンスも、新しいデータがない場合と、切替後に取引やデータが増えた場合を分けています。後者では新環境から旧環境へデータを戻すことを検討しています（出典：AWS Cutover stage「Rollback」）。

変更がある場合は、まず新側の更新を止め、回収対象の終点を固定します。新規登録だけでなく、既存データの訂正・取消・削除も取り出します。新しい行だけを集める方法では、既存注文の変更を見落とします。

回収した内容と対象番号を保全し、旧側で受け取れる形式へ変換して反映します。受注番号などで重複を避け、訂正は対象を特定して直し、取消は取消状態まで戻します。旧側に存在しない項目や状態をどう扱うかも事前に決めておきます。更新日時だけで変更を取り出せるか、削除された記録も追えるかは、リハーサルで確かめます。

図1　切替後の変更を旧側へ引き継いでから再開します。変更なしとする場合も、定期処理や外部連携の更新を含めて照合します。

最後に、先ほどの照合項目を切替後の変更込みで確かめ、旧側で受注の登録・訂正ができることを試して入力を再開します。変更を取り出せない、旧側へ反映できない、再開期限に間に合わない場合は、その手順では切り戻せません。事前に決めた判断者へ状況を伝え、新側での修正、停止時間の延長、別の受付方法を選びます。

通知済みのメールや、すでに行った出荷は、データを戻しても取り消されません。送信・出荷の記録と照合し、二重の通知や出荷を防ぐ手順、必要な訂正連絡も用意します。

本番前に同じ手順でリハーサルする

本番相当の量、エラーを含むデータ、時間制限、担当者の引き継ぎまで含めて、当日と同じ手順で通します。作業時間、詰まった箇所、手順書との差を記録し、当日の担当表へ戻します。

食品卸の例なら、重複した商品コード、単位の違い、取消済みの受注も用意します。移す作業に加えて、新側で追加・訂正・取消を行い、それを旧側へ戻すところまで試します。途中で失敗した後、どこまで反映済みか確認して再開できるかも確かめます。

変更分の取出し・変換・反映と照合にかかった時間を測り、判断期限までに戻し始めれば再開期限に間に合うかを確認します。結果が合わない、時間を超える場合は、対象や手順、作業時間を見直してから当日を迎えます。

移行後の見守り期間まで計画に含める

切替直後は、入力できることに加えて、帳票、通知、夜間処理、外部連携を確認します。問い合わせを一か所へ集め、データ訂正は対象、理由、確認者を残す手順で行います。旧環境を残す期間と、参照・復旧に使う記録の保管方法も決めます。

計画書、対応表、照合結果、リハーサル記録、当日判断、移行後の課題を同じ単位で保管すると、次の追加移行や他社開発システムの保守引き継ぎで調べることにも使えます。

まず、切替後にも受け付ける注文と訂正を一件ずつ挙げ、旧側のどこへ戻すかを書き出してください。移行の相談には、現在の台帳とその例をそろえます。受注番号ごとの変更を旧側へ戻せるかが、復旧手順を決める材料になります。

サーバーの契約終了や保守の引き継ぎに伴う移設では、データだけでなく接続先や定期処理も移します。クラウド・サーバー移行では、移す対象、切替日、戻す条件をそろえて相談できます。

データ移行・統合と照合の相談内容

参考出典

• IPA「ユーザのための要件定義ガイド 第2版」第4章「成果物の勘どころ」関連資料（2019年、4.1.1・資料6〜8ページ、2026年9月15日確認）。成果物の選び方を参照。移行の具体的な復旧手順を保証する資料ではありません。（PDF）
• AWS Prescriptive Guidance「Cutover stage」Rollback（発行日・版番号表示なし、2026年9月15日確認）。切替後の変更有無による戻し方の区別を参照。具体的な方式はAWS環境の説明です。