データ移行とは？データ移行の種類や方式、実際の移行手順について解説
データ移行とは、企業や組織が保持するデータを古いシステムから新しいシステムへと移すプロセスのことです。
システム刷新やパッケージ導入時などに欠かせない工程であり、データマイグレーションとも呼ばれます。
データ移行は4種類存在しています。
- ストレージ移行
古いストレージシステムから新しいストレージシステムへ、物理的もしくは仮想的にデータを移動するプロセス - データベース移行
データベースを異なるプラットフォームへ移行するプロセス - アプリケーション移行
ソフトウェアアプリケーションを別のプラットフォームへ移行するプロセス - ビジネスプロセス移行
業務フローや運用プロセスそのものを効率化・刷新するプロセス
また、データ移行には3つの方式が存在しています。
- 一斉移行方式
全てのデータを短期間で一括して移行する方式です。
迅速な移行が可能ですが、移行元システムと移行先システムの両方を一時的に停止する必要があります。 - 段階的移行方式
データを段階的に移行する方式です。
部分的な移行を行う手法のため、一斉移行方式と異なり、システム停止を回避できるメリットがありますが、全体のプロセスには時間がかかってしまい、本格運用までの期間が長いというデメリットがあります。 - 並行稼働方式
一斉移行方式と段階的移行方式の要素を合わせた移行方式です。
データごとにどちらの方法で移行するか選択し、相互のデメリットを最小限に抑えることが可能です。しかし、計画や管理が難しいというデメリットがあります。
実際にデータ移行を進める際は、下記のような手順を踏みます。
- データ移行方針の検討
プロジェクト要件やテスト方針書を踏まえ、データ移行の対象範囲、役割、スケジュールを検討し内容について開発ベンダと合意を得ます。
なお、開発ベンダとの合意事項をまとめた文書はデータ移行方針書と呼びます。
※検討事項：対象となるテーブル、データ項目、データ量、移行方法、移行リハーサルの実施要否・実施方法…など
- 移行データの調査・クレンジング方針の策定
作成したデータ移行方針書を基に移行対象データに関する調査を行います。
また、移行対象データに関しては、クレンジングの要否を判定の上、クレンジング方針を策定します。
なお、クレンジングとはデータの中から、重複や誤記、表記の揺れなどを探し出し、削除や修正、正規化などを行ってデータの品質を高めることを指します。 - 移行元データ項目一覧の準備
2.の工程で明らかになった移行対象データを一覧化します。 - データマッピングの実施
3.の工程で一覧化した移行対象データを、新システムのデータベースへ移行する方法を定義します。 - データ移行計画書の作成
データ移行方針書を基に移行概要、移行対象、切り戻し時対応、スケジュール、移行体制・役割分担を具体化した移行計画書を作成し、決定事項について随時更新します。 - データ移行手順書の作成
データ移行計画書を基に、具体的なデータ移行の進め方を記載したデータ移行手順書を作成します。 - データ移行テスト計画書の作成・データ移行テストの実施
データ移行計画書、データ移行手順書を基に、データ移行範囲、移行方針、移行方法を具体化し、データ移行テスト計画書としてまとめます。
その後、データ移行テスト計画書をもとにテストを実施します。 - 移行リハーサル計画書の作成・移行リハーサルの実施
データ移行テスト結果とデータマッピングにて定義した内容との整合を確認したのち、不具合がなければ移行リハーサルの実施要否判断を行います。
移行リハーサルを実施する場合、移行計画書を基に移行リハーサル書を作成し、それに基づいて移行リハーサルを実施します。
※データ移行テストで不具合が発生した場合は、受入れテストまでに不具合の改修と再テストを実施します。また、コンティンジェンシープランの策定も重要なポイントです。
※移行リハーサルを実施しない場合、データ移行テストで使用したデータを受入テストで使用します。 - 受入テスト計画書の作成・受入テスト実施
受入テスト計画書(受入テストの目的、テスト対象・範囲、スケジュール、担当者、テスト管理の流れ)を作成します。
その後、受入テスト計画書を基に作成した受入テストシナリオ(受入テストを実際に行う際の手順書)を参照しながら受入テストを実施します。 - 本番移行判定・本番移行の実施
受入テストの結果、本番環境へ移行判定しても問題ないと判断された場合、本番環境へのデータ移行作業を実施します。
その後、新システムの稼働状況を確認し、問題がなければ新システムをリリースします。
よくある質問
データ移行計画を立案する際、発注者が確認すべき事項は何か？
データ移行計画を立案する際、発注者が確認すべき事項は、移行対象範囲の明確化、データ品質の事前検証、方式選定の妥当性、移行テストと検証体制の整備です。
これらを契約・受入基準と結び付けておくことが、後工程のトラブル防止につながります。
確認すべき主要事項
1. 移行対象範囲の明確化
・どのデータを移行するか（業務データ、マスタデータ、履歴データ等）を定義する。
・移行不要なデータの除外基準（廃棄ルール）も含めて明示しておくことが重要。
2. データ品質の事前検証
・移行元データに不整合や欠損がないかを早期に把握する。
・発注者が自部門にデータクリーニングを依頼する必要がある場合も想定しておく。
3. 移行方式の妥当性確認
・バッチ移行・段階的移行・リアルタイム移行など、どの方式を採用するかを確認する。
・運用への影響（停止時間や並行稼働の必要性）を踏まえた方式選定となっているかをチェックする。
4. テストと検証体制の整備
・データ移行テストの実施計画（移行テスト・移行リハーサル）が策定されているかを確認する。
・移行後のデータ検証（件数一致、整合性確認、業務シナリオによる確認）が明確に定義されているかを確認する。
5. 責任分担と承認フロー
・発注者・ベンダーそれぞれの役割（データ抽出、加工、投入、検証）を明確化しておく。
・トラブル時の対応窓口や承認権限を事前に定めることで混乱を回避できる。
データ移行計画は単なる技術作業ではなく、範囲・品質・方式・検証体制を発注者が主体的に確認し、契約条件や受入基準と紐付けて管理することが重要です。
これにより、移行後の不整合や運用トラブルを未然に防ぐことができます。
データの欠損や不整合を防ぐために発注者が担う役割は？
データの欠損や不整合を防ぐために、発注者が担う役割は、移行対象データの定義と品質確認、検証基準の設定、事前準備としてのデータ整備です。
ベンダーに任せきりにするのではなく、発注者自身が主体的にデータの責任を持つ姿勢が求められます。
発注者の主な役割
1. 移行対象データの定義と範囲確認
・どのデータを移行するかを明確に定義し、不要データや移行対象外のデータを整理する。
2. データ品質の事前確認（クリーニング）
・移行元データに誤記・重複・欠損がないかを事前に検証し、必要に応じて修正・統合を行う。
・発注者が業務部門と連携し、移行前に品質を担保しておくことが重要。
3. 検証基準の設定と承認
・移行後のデータ件数一致、整合性確認、業務シナリオに基づく照合基準を事前に定義する。
・発注者は「どの状態でデータ移行が完了とみなせるか」をベンダーと合意しておく。
4. 移行リハーサルやテストへの関与
・サンプルデータを用いたテスト移行を実施し、欠損や不整合の有無を発注者自身も確認する。
・本番移行の前に複数回検証することで、移行後トラブルの発生を低減できる。
5. 責任分担の明確化
・データ抽出・加工・投入の作業責任はベンダーにあっても、最終的にデータの正確性を確認・承認するのは発注者の役割です。
データの欠損や不整合を防ぐには、発注者が移行対象の定義・品質確認・検証基準を主体的に担い、承認責任を果たすことが不可欠です。
ベンダーの技術力に依存するだけではなく、発注者がデータオーナーとして関与することが、移行成功の鍵となります。
データ移行後の品質保証や監査に備えるため、発注者が準備すべきことは何か？
データ移行後の品質保証や監査に備えるため、発注者が準備すべきことは、移行結果の検証基準の明確化、証跡の記録・保管、監査対応を見据えたプロセスの設計です。
これにより、移行の妥当性を客観的に示し、将来的なトラブルや説明責任に対応できる体制を確立できます。
発注者が準備すべき具体的事項
1. 検証基準の事前定義
・データ件数の一致、項目ごとの整合性、業務シナリオを通じた正確性確認といった観点を定義しておく。
・「どの状態をもって移行が完了とみなすか」を明文化し、受入条件として合意しておく。
2. 移行プロセスの記録と証跡保管
・抽出・変換・ロード（ETL）の各工程でのログやエラーレポートを保存する。
・移行テストやリハーサル移行の結果も含め、監査時に提示できる形で管理する。
3. データ品質チェックリストの整備
・欠損や重複の有無、業務で利用する検索・参照機能での正常動作などを確認項目として整理する。
・発注者がチェックリストに基づき承認する仕組みを設けることが望ましい。
4. 監査対応を見据えた体制構築
・内部監査・外部監査で要求される可能性のある証跡（移行計画書、実施結果報告、承認記録）を事前に揃えておく。
・移行に関わった担当者や承認者の役割を文書化しておくと説明責任を果たしやすい。
5. トラブル対応フローの整備
・移行後に不整合が発覚した場合の是正手順や責任分担を定め、即応できる仕組みを準備しておく。
データ移行後の品質保証や監査対応を確実に行うためには、検証基準の明文化と証跡の体系的管理、監査対応を前提としたプロセス設計を発注者が主体的に準備することが重要です。
これにより、移行作業の透明性を確保し、トラブル対応及び監査対応を円滑に行うことができます。
あわせてこの用語と記事をチェック
パッケージ導入時の実装作業とその中でも発注者側が実施すべきこととは – IT調達ナビ (gptech.jp)
新システム稼働直前の受入テストや移行時に発注者側が実施すること – IT調達ナビ (gptech.jp)
この記事の編集者
大野 誠司
日本のIT変革の一助となりたいと考え（株）グローバル・パートナーズ・テクノロジーに新卒入社。 主に民間企業の情シス業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するというメディア運営業務にも携わる。
