リプレイス時のデータ移行計画：移行リハーサルと切り戻しの準備

リプレイスのデータ移行を失敗させないための計画は、「何を移すか」「どう変換するか」「何度リハーサルするか」「失敗したらどう戻すか」の四つを、開発と同じ重さで早い段階から決めておくことに尽きます。移行対象の選定、変換ルールの定義、データの整備、移行ツールの準備、複数回のリハーサル、本番移行、移行後の検証、そして切り戻しの手順。この一連の流れを計画書に落とし、関係者が同じ手順書を見て動ける状態を作れば、切り替え当日の不確実性は大きく下がります。

データ移行が難しいのは、旧システムのデータが「旧システムの都合」で作られているからです。項目の意味、コードの体系、文字の扱い、日付の形式、削除の扱いなど、新旧で考え方が違う部分は必ずあります。さらに、長年の運用で、想定外の値や重複、入力ルールの変化による表記の揺れが蓄積しています。これらは実際にデータを移そうとして初めて見つかることが多く、開発の終盤に移行を考え始めると、日程が一気に崩れます。

この記事は、システムのリプレイスを控えた事業責任者、情報システム担当者、プロジェクトの推進担当者に向けて書いています。データ移行計画に含めるべき項目、移行対象と変換ルールの決め方、リハーサルの進め方、切り戻しの準備、よくある失敗とチェックリストを順に整理します。

データ移行計画に含めるべき項目

まず、データ移行計画書に何を書くべきかを整理します。計画書は開発会社だけが持つものではなく、発注側も内容を理解し、判断に参加すべき文書です。

これらのうち、移行対象と旧データの扱いは、法令上の保存義務や監査対応にも関わることがあります。帳簿や取引記録の保存期間などは業種や書類によって異なるため、最新の情報を公的機関や専門家に確認したうえで決めてください。

データ移行という言葉からは「データをコピーする作業」を想像しがちですが、実際には上の表の大半が判断と準備の作業です。コピーそのものは、準備が整っていれば短時間で終わります。

移行対象の選び方：すべてを移す必要はない

最初に決めるのは、何を移すかです。旧システムのデータをすべて移すのが最も安全に見えますが、実際には移す量が増えるほど、変換の手間、整備の手間、検証の手間、移行にかかる時間が増えます。目的に照らして、移す範囲を意識的に決めることが大切です。

データは大きく次の三種類に分けて考えると判断しやすくなります。

• マスタデータ：顧客、取引先、商品、社員など、業務の基礎となるデータ。原則として現在有効なものを移す。
• 残高・状態のデータ：在庫数、売掛金の残高、契約の状態、ポイント残高など、切り替え時点の状態を表すデータ。正確に移すことが最も重要。
• 履歴データ：過去の取引、問い合わせ、操作の記録。どこまで遡って移すかを業務上の必要性で決める。

履歴データは、すべてを新システムに移すのではなく、直近の一定期間だけを移し、それより古いデータは参照用の別の仕組みに保管する選択肢もあります。たとえば、旧データをファイルや簡易的な検索画面で参照できるようにしておけば、新システムには必要な範囲だけを移せます。利用頻度の低い過去データのために、変換と検証に多くの時間を使うのは得策ではありません。

逆に、残高や状態のデータは、一件でも誤ると業務や顧客に直接影響します。移行対象の選定では、「どのデータが誤ると誰が困るか」を基準に、検証の厳しさにも差をつけてください。

変換ルールの定義とデータの整備

移行対象が決まったら、旧システムの項目を新システムのどの項目に、どのように移すかを定義します。この対応表が変換ルールです。

変換ルールは、次のような形の表で整理すると、業務部門も内容を確認できます。

ここで重要なのは、例外の扱いをあらかじめ決めておくことです。変換ルールに当てはまらないデータは必ず出てきます。そのたびに場当たり的に判断していると、リハーサルのたびに結果が変わり、検証が終わりません。「当てはまらないものは一覧に出力し、業務部門が手で補正する」といったルールを決めておけば、例外の件数を把握しながら作業を進められます。

変換の前に、旧データそのものを整える作業も必要です。重複している顧客の統合、表記揺れの統一、明らかな入力ミスの修正などがこれにあたります。データクレンジングは、旧システムで行うか、移行の途中で行うか、新システムに入れてから行うかを決めておきます。業務を知る人の判断が必要な作業が多いため、業務部門の作業時間を計画に入れておくことを忘れないでください。

データ移行の手順

データ移行は、次の手順で計画から本番まで進めます。

1. 旧データの調査：テーブルごとの件数、項目の意味、値の分布、品質の問題を確認する。
2. 移行対象の決定：マスタ・残高・履歴ごとに、移す範囲と旧データの保管方法を決める。
3. 変換ルールの定義：項目の対応表、コードの読み替え、例外の扱いを決め、業務部門と合意する。
4. データ整備：重複・表記揺れ・不正値の修正を、担当と期限を決めて進める。
5. 移行ツールの準備：抽出・変換・投入の処理を作り、何度でも同じ結果が出るようにする。
6. 検証方法の決定：件数、合計値、サンプルの目視確認など、合格基準を数字と手順で決める。
7. リハーサル：本番と同じ手順で移行し、時間、結果、手順書の不備を確認する。問題を直して繰り返す。
8. 本番移行：旧システムを停止し、最終データを移行し、検証し、切り替えの可否を判断する。
9. 移行後の確認：切り替え後の初回の締め処理や請求処理まで、データの整合性を見守る。

手順5の移行ツールは、手作業を極力減らし、何度実行しても同じ結果になるように作ることが重要です。手作業が多いと、リハーサルと本番で結果が変わり、リハーサルの意味が薄れます。どうしても手作業が残る場合は、手順書に一つずつ書き出し、誰がやっても同じ結果になるようにします。

移行リハーサルの進め方

リハーサルは、データ移行計画の中で最も効果の高い工程です。少なくとも一回、規模や重要度が高い場合は複数回行います。回数を重ねるごとに目的を変えていくと、効率的に不確実性を減らせます。

一回目のリハーサルは、変換ルールと移行ツールの不具合を見つけることが目的です。本番に近い量のデータを使い、変換エラーの種類と件数、例外として出力されたデータを確認します。ここで多くの問題が見つかるのは当然であり、むしろ見つからない場合は確認の仕方を疑うべきです。

二回目以降は、本番当日の段取りを確認することが目的になります。手順書どおりに作業し、各工程の所要時間を計測します。業務停止の時間内に収まらない場合は、事前に移せるデータ（マスタや古い履歴）を先に移しておき、当日は差分だけを移す方式を検討します。

最後のリハーサルは、本番と同じ担当者、同じ時間帯、同じ手順で行う通し稽古です。切り戻しの手順もこのときに実際に試しておくと、本番で迷わずに済みます。

リハーサルごとに確認すべき項目は次のとおりです。

• 移行にかかった時間と、各工程の所要時間
• テーブルごとの件数と、金額・数量の合計値が新旧で一致するか
• 例外として出力されたデータの件数と内容
• 移行後のデータで、主要な業務（受注、請求、検索など）が問題なく動くか
• 業務部門の担当者がサンプルを目視で確認し、違和感がないか
• 手順書に書かれていない作業や判断が発生しなかったか

切り戻しの準備：戻れる状態を残す

本番移行で想定外の問題が起きたとき、旧システムに戻せるかどうかで被害の大きさが変わります。切り戻しの準備は、使わずに済むことを願う保険ですが、省いてはいけません。

切り戻しの計画では、次の四点を決めておきます。

一つ目は判断基準です。「件数が一致しない」「主要業務が動かない」「移行が予定時刻までに終わらない」など、どの状態になったら切り戻すかを事前に決めます。当日の現場で判断基準を議論し始めると、時間だけが過ぎていきます。

二つ目は判断者です。切り戻すかどうかを決める人と、その人に連絡がつかない場合の代理を決めておきます。

三つ目は手順です。旧システムの再開、新システムへの入力の停止、利用者への連絡など、戻すための作業を手順書にしておきます。ロールバックの手順は、リハーサルで実際に試しておくのが理想です。

四つ目は期限です。切り替え後、どの時点まで切り戻しが可能かを決めます。新システムで業務が進み、新しいデータが積み上がった後に旧システムに戻すと、そのあいだのデータを旧システムに反映する作業が発生します。切り戻しの期限を過ぎたら、問題は新システム上で修正する方針に切り替えます。

旧システムのデータと環境は、少なくとも切り戻しの期限が過ぎるまで、すぐに再開できる状態で保管してください。

本番移行当日の体制と連絡の決め方

本番移行の当日は、限られた時間の中で多くの作業と判断が続きます。手順書があっても、誰が何をするか、問題が起きたら誰に伝えるかが曖昧だと、作業が止まります。当日の体制は、リハーサルの段階から本番と同じ形で決めておきます。

役割としては、全体の進行を管理し切り戻しの判断を下す責任者、移行作業を実行する技術担当、移行後のデータを業務の目で確認する業務担当、利用者や取引先への連絡を担う窓口担当の四つを置くのが基本です。少人数のプロジェクトでは兼務になりますが、責任者と技術担当は分けておくと、作業に追われて判断が遅れる事態を防げます。

連絡については、作業の開始と終了、各チェックポイントの結果を、決めた場所に時刻とともに記録していく形が有効です。チャットのスレッドや共有のシートに「何時に何が終わり、結果はどうだったか」を残しておけば、関係者が状況を把握でき、後で振り返るときの材料にもなります。また、予定より遅れた場合に、どの時点で責任者に判断を仰ぐかという中間の判断点も決めておきます。

利用者への周知は、業務停止の時間、切り替え後に最初にやること、問い合わせ先の三点を、数日前と前日に繰り返し伝えるのが基本です。切り替え直後の最初の数時間は、問い合わせが集中することを前提に、窓口の人数を厚くしておいてください。

具体的な場面の例：会員管理システムのデータ移行

架空の一般例として、ある会員制サービスの会社が、会員管理と課金の仕組みを新しいシステムに移す場面を考えます。会員データ、契約状態、ポイント残高、過去の決済履歴が移行の対象です。

この会社は、会員と現在の契約状態、ポイント残高を「誤ると顧客に直接影響するデータ」と位置づけ、全件を移して件数と残高の合計を厳密に検証することにしました。一方、過去の決済履歴は直近の一定期間分だけを新システムに移し、それより古いものは問い合わせ対応用の参照画面で見られるようにしました。

一回目のリハーサルでは、退会後に再入会した会員が同じメールアドレスで二件登録されているケースが多数見つかりました。業務部門と相談し、最新の契約を正とし、過去の契約は履歴として紐づける変換ルールを追加しました。二回目のリハーサルでは移行時間を計測し、業務停止の時間に収めるために、会員の基本情報を前日までに移し、当日は契約状態とポイント残高の差分だけを移す方式に変更しました。最後のリハーサルでは切り戻しの手順も試し、本番当日を迎えています。

データ移行でよくある失敗と避け方

移行の計画を開発の終盤まで始めない。 旧データの問題は移そうとして初めて見つかります。現行調査の段階でデータの品質を確認し、移行の工程を最初から計画に入れてください。

すべてのデータを移そうとする。 変換と検証の手間が膨らみます。データの種類ごとに移す範囲を決め、古い履歴は参照用の保管で済ませる選択肢を検討します。

例外の扱いを決めずに進める。 リハーサルのたびに判断が変わり、結果が安定しません。例外は一覧に出力し、補正の担当と期限を決めておきます。

検証を「なんとなく見て問題なさそう」で済ませる。 件数と合計値の一致という機械的な確認と、業務担当者による目視確認の両方を、合格基準として事前に決めてください。

業務部門の作業時間を見込んでいない。 データ整備と検証には、業務を知る人の判断が欠かせません。通常業務と並行して行う時間を、上長の合意のうえで確保しておきます。

切り戻しの手順を試していない。 手順書があっても、実際に試していなければ当日に動けません。リハーサルで一度は実行しておきます。

データ移行計画のチェックリスト

• 移行対象をマスタ・残高・履歴に分け、それぞれの移す範囲を決めた
• 移さないデータの保管方法、参照方法、保管期間を決めた
• 法令上の保存義務など、保管に関わる制度を専門家や公的機関で確認した
• 旧項目と新項目の対応表と、例外の扱いを業務部門と合意した
• データ整備の担当、方法、期限を決めた
• 移行ツールは何度実行しても同じ結果になる
• 件数・合計値・目視確認の合格基準を決めた
• リハーサルの回数と日程を計画に入れ、各回の目的を決めた
• 移行にかかる時間を計測し、業務停止の時間内に収まることを確認した
• 切り戻しの判断基準、判断者、手順、期限を決め、リハーサルで試した
• 本番当日の作業の順番、担当者、連絡体制を手順書にした
• 切り替え後の初回の締め処理までの見守り体制を決めた

一括で移すか段階的に移すかによって、移行計画の組み立て方は変わります。判断の観点はシステム移行は段階的か一括かで整理しています。

よくある質問

Q. データ移行は開発会社に任せてよいですか？

移行ツールの作成や作業の実行は開発会社に任せられますが、移行対象の決定、変換ルールの合意、例外データの補正、検証の最終確認は発注側の判断が必要です。業務を知る人が関わらないと、データの意味を取り違えたまま移行が進む恐れがあります。

Q. リハーサルは何回行えばよいですか？

データの量と複雑さ、業務への影響の大きさで決めます。少なくとも、不具合を見つけるための回と、本番の段取りを確認する通し稽古の回は分けて行うのが望ましいでしょう。問題が多く見つかった場合は、回数を増やす前提で日程に余裕を持たせておきます。

Q. 旧システムはいつ停止してよいですか？

切り戻しの期限が過ぎ、移行後の初回の締め処理など重要な業務が新システムで問題なく完了したことを確認してからが目安です。停止後も、旧データを参照できる方法は残しておきます。

Q. 移行にかかる業務停止の時間を短くする方法はありますか？

マスタや古い履歴など変化の少ないデータを事前に移し、当日は差分だけを移す方法が一般的です。さらに短くしたい場合は、新旧のデータを同期させながら段階的に切り替える方法もありますが、仕組みが複雑になるぶん費用と検証の手間が増えます。

Otsumuに相談できること

移行するデータの種類が少なく、件数も多くなく、業務部門の担当者がデータの意味を把握している場合は、この記事の手順とチェックリストに沿って社内で移行計画を立てることも十分に可能です。表計算ソフトで対応表を作り、リハーサルを丁寧に行えば、外部に頼まなくても移行を成功させられるケースは多くあります。

一方で、旧システムのデータ構造が分からない、データの品質に大きな不安がある、業務停止の時間が短い、複数のシステムからデータを集めて移す必要がある、といった状況では、移行の設計とツールの作成に経験のある外部の力を借りたほうが安全です。データ移行の失敗は、切り替え後の業務と顧客対応に直接響くからです。

Otsumuは、システムリプレイスの一環として、旧データの調査、移行対象と変換ルールの設計、移行ツールの作成、リハーサルと切り戻しの準備、切り替え後の見守りまでを一気通貫で支援します。リプレイス全体の進め方はシステムリプレイスの進め方で紹介しています。費用は対象範囲に応じて個別にお見積もりします。

移行の計画をどこから立てればよいか迷っている段階でもご相談いただけます。30分の無料相談で、移行するデータと業務の状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01