システムリプレイスのデータ移行手順|計画・リハーサル・切り戻しのチェックリスト

システムリプレイスでデータ移行を任されたものの、「何から計画すればよいか」「本番で不整合が起きたらどう戻すか」と不安を感じているエンジニアやリーダー向けの記事です。データ移行は、ファイルやレコードをコピーするだけの作業ではありません。対象の棚卸し、変換ルール、検証、リハーサル、切り戻しまでを一つの工程として設計する必要があります。本記事では、移行計画を作る順序、実行手順、失敗しやすい点、完了判定のチェック項目を実務で使える形に整理します。


フリーランス案件を探す

データ移行で最初に決める5つの項目

最初に決めるのはツールではなく、移行の境界です。対象が曖昧なままスクリプトを作ると、後から関連テーブルや添付ファイルが見つかり、設計をやり直すことになります。次の5項目を移行計画書の冒頭に置きましょう。

  • 対象:データベース、ファイル、画像、ログ、マスタ、権限情報のうち何を移すか
  • 変換:項目名、型、文字コード、タイムゾーン、コード値をどう対応付けるか
  • 停止条件:サービス停止の可否と、更新を止められる時間帯
  • 完了条件:件数、金額合計、ハッシュ値、参照整合性など何を一致させるか
  • 責任分界:抽出、変換、投入、業務確認、承認を誰が担当するか

対象一覧には「移行する・しない」だけでなく、保持期間、機密度、データ量、更新頻度、依存先も記録します。たとえば画像ファイルと管理テーブルが別々の場所にあっても、業務上は一組です。依存関係を図にすると、投入順序と検証範囲が見えやすくなります。

安全なデータ移行を進める7つの手順

  1. 現行データを棚卸しする:テーブル件数、容量、欠損、重複、想定外の文字を調査し、移行前から存在する不備を分けます。
  2. マッピング表を作る:移行元と移行先の項目、変換式、初期値、NULLの扱い、除外条件を一行ずつ定義します。
  3. 移行方式を選ぶ:一括移行、差分移行、段階移行から、停止可能時間とデータ量に合う方式を決めます。
  4. 移行処理を再実行可能にする:途中で失敗しても、二重登録を起こさず同じ手順をやり直せる設計にします。
  5. テスト環境で検証する:正常系だけでなく、欠損、重複、桁あふれ、文字化け、参照先なしなどの異常系を試します。
  6. 本番相当データでリハーサルする:所要時間、ボトルネック、監視方法、担当者間の受け渡しを計測します。
  7. 本番移行と業務確認を行う:技術的な一致確認に加え、検索、表示、更新、帳票など代表的な業務シナリオを確認します。

大切なのは、移行プログラムと同時に証跡を作ることです。開始・終了時刻、処理件数、エラー件数、再実行の有無、検証結果を自動で残せれば、障害時の調査と完了承認が速くなります。手作業が必要な工程は、コマンドや画面操作を手順書に固定し、実行者と確認者を分けます。

移行方式を選ぶ判断基準

一括移行は、サービスを停止し、全件をまとめて移す方式です。構成が単純で整合性を保ちやすい一方、データ量が多いと停止時間が長くなります。停止可能時間内に抽出・変換・投入・検証が終わるかを、リハーサルの実測値で判断します。

差分移行は、事前に大部分を移し、本番切り替え時には更新分だけを反映します。停止時間を短くできますが、追加・変更・削除を正しく捕捉する仕組みが必要です。更新時刻だけに頼ると取りこぼしや時刻ずれが起きるため、更新履歴や変更データの取得方法を設計します。

段階移行は、機能、利用者、地域などの単位で切り替える方式です。影響を限定しやすい反面、旧システムと新システムが並存します。どちらを正とするか、同期は一方向か双方向か、段階ごとの終了条件は何かを明文化しなければなりません。

方式選定では、実装の容易さだけでなく、許容停止時間、データの整合性、切り戻し時間、並存期間の運用負荷を比較してください。「停止できないから差分移行」と即断せず、複雑化によるリスクも含めて決めます。

よくある失敗と切り戻し対策

よくある失敗は、テストデータが少なすぎて本番の処理時間を読めないことです。本番相当の件数とファイルサイズで測定し、抽出、転送、変換、投入、検証を別々に計測します。最長時間だけでなく、余裕時間も移行枠に含めます。

次に多いのが、件数一致だけで完了と判断することです。件数が同じでも、コード変換の誤りや関連付けのずれは残ります。主キーの重複、必須項目の欠損、親子関係、金額・数量の合計、代表レコードの内容、ファイルのハッシュ値など、性質の異なる確認を組み合わせましょう。

切り戻しは「バックアップがある」だけでは不十分です。戻す判断をする時刻と責任者、復元に必要な時間、移行開始後に発生した更新の扱いまで決めます。実行前には、バックアップから実際に復元できることを確認してください。また、切り替え後に利用者が入力を始めると単純には戻せません。更新を解放する前に、技術確認と業務責任者の承認を完了させます。

  • 開始条件と中止条件が数値で定義されている
  • 移行処理を途中から、または最初から安全に再実行できる
  • エラー対象を隔離し、原因と再処理結果を追跡できる
  • 切り戻し手順をリハーサルし、所要時間を把握している
  • 連絡先、判断者、報告間隔が当日の手順書に記載されている

データ移行に関するよくある質問

Q1. データ移行テストは何回行えばよいですか?

A. 回数を固定するより、課題が解消され、所要時間と結果が安定するまで繰り返すことが重要です。少なくとも手順確認、本番相当データでの計測、当日体制を含む総合リハーサルを分けて考え、各回の目的と合格条件を設定します。

Q2. 本番データをテスト環境で使う際の注意点は?

A. 個人情報や機密情報をそのまま複製せず、社内規程に従ってマスキングや匿名化を行います。アクセス権、保管期間、削除手順も定め、必要な担当者だけが扱える状態にしてください。データの特徴を保ちながら安全性を確保することが必要です。

Q3. 移行後、旧システムはすぐ停止してよいですか?

A. 移行直後の照合や問い合わせ対応に必要な場合があります。参照のみで残す期間、アクセスできる人、データ更新を禁止する方法、最終的な廃止日を決めます。法令や社内ルールによる保存要件も確認し、曖昧なまま並存させないようにします。


フリーランス案件に無料登録する

まとめ

安全なデータ移行は、対象と完了条件を決め、マッピング、方式選定、実装、異常系テスト、リハーサル、本番確認を順番に進めることで実現できます。特に、件数以外の検証、再実行可能な処理、判断基準を含む切り戻し計画が重要です。まずは移行対象一覧と項目マッピング表を作り、停止可能時間と完了条件を関係者で合意してください。そのうえで本番相当データを使い、所要時間と復元手順を実測しましょう。

投稿者プロフィール

株式会社 SunSunTech
株式会社 SunSunTech
はじめまして。
株式会社SunSunTech代表取締役の鈴木と申します。

SunSunTechは、エンジニアが納得できるキャリアと報酬を得られるSES企業を目指して設立しました。

私は元々、エンジニアとして複数のSES現場で経験を積んできました。
その中で、「スキルに見合った評価が得られない」「給与の仕組みが不透明」といった業界特有の課題に何度も直面してきました。

こうした状況を変えるために、SunSunTechでは、透明性のある評価制度の導入、エンジニアファーストな案件選定など、"エンジニアが報われる仕組み"を徹底しています。

SES企業様とのパートナー連携においても、スピード・誠実・精度を大切にし、長期的に信頼される関係構築を目指しております。

エンジニアの未来を、本気で変えていく。
その想いに共感してくださる方、ぜひ一度お気軽にお声がけください。