1 データ移行の概要
1.1 データ移行の目的
データ移行とは、データが保持されている場所・管理方式・参照方法・表現形式を、計画的に別の環境へ移し替える行為である。単なる複製ではなく、移行先で業務や分析が継続可能な状態を作ることが目的となる。
1.1.1 システム更改による移行
老朽化した基盤やアプリケーションから新しい基盤へ移行する際、データの引き継ぎは中心課題となる。新旧でスキーマやアクセス手段が異なるため、項目対応、型変換、参照のつなぎ直しまでを含めて設計する必要がある。
1.1.2 クラウド移行による移行
オンプレミスからクラウドへ移る場合、ネットワーク構成、ストレージ形態、利用可能なデータサービスが変わる。移行は性能や運用体制にも影響するため、データ所在、権限モデル、暗号化方式などを合わせて整理する。
1.1.3 データ形式・構造の統一
複数部門やシステムでばらばらだった形式を統合し、データモデルを標準化する。統一により検索性、集計の再現性、分析の一貫性が高まる一方で、過去データの表記ゆれや定義差を解消する変換設計が不可欠となる。
1.1.4 運用・性能・コスト最適化
移行を契機に、保存コストや処理効率を見直す。例えば、参照頻度に応じたデータ配置、インデックスの再設計、不要な履歴の整理などが対象となる。移行後の性能要件を満たすことが、費用対効果の前提になる。
1.2 データ移行の範囲と対象
移行は「何を」「どこへ」「どの粒度で」動かすかを確定させることで成立する。範囲が曖昧なまま進めると、後段の検証や切替で問題が顕在化しやすい。
1.2.1 対象データの種類（基幹、ログ、マスタ、履歴など）
基幹データは業務の実行に直結し、ログは調査や監査に必要となる。マスタは参照の軸で、履歴は時系列の追跡に関わる。加えて、関連する派生データや集計結果がある場合は、再生成するのか移送するのかを決める必要がある。
1.2.2 対象システム（保存先・参照先・連携先）
移行先の保存先だけでなく、参照側のアプリケーション、連携先の外部システム、バッチ処理の起点なども考慮する。あるデータを移すことで連携仕様が変わる場合、インターフェースと運用手順を同時に整える。
1.2.3 移行単位（全量、差分、バッチ単位）
全量移行は初回にまとめて引き継ぐ方式で、準備期間が長くなりがちである。差分移行は変更分を追加し、切替までの整合を保ちやすい。バッチ単位では、処理ウィンドウを意識して段階的に移すため、時間制約と相性が良い。
1.3 成功基準（品質・制約・可用性）
成功とは「移したこと」ではなく、移行後に定義した条件を満たした状態を指す。品質、性能、可用性のバランスを、測定可能な指標に落とし込む。
1.3.1 データ品質（正確性・完全性）
正確性は値の対応関係が成立していること、完全性は必要な行や項目が失われていないことを意味する。加えて、必須項目の欠落やコード体系の取り違えなど、業務上重大な誤差を特定できる設計が求められる。
1.3.2 性能要件（移行時間・検索応答）
移行時間は段階移行や夜間実行の可否に直結する。移行後の検索応答は、インデックス設計や分割方式に依存するため、移行前後で測定し比較する。更新処理やバッチ時間も含めた評価が必要になる。
1.3.3 可用性要件（ダウンタイム、並行稼働）
切替時にサービスが停止しない設計や、停止時間を限定する設計が重要となる。並行稼働を採用する場合は、二重更新や不整合が起きないよう同期方針と責任分界を明確にする。
2 移行計画と設計
2.1 現状調査と要件定義
計画は調査から始まる。対象のデータ構造、利用状況、参照関係、運用制約を把握し、移行で守るべき条件を文章化する。
2.1.1 データ棚卸し
データ棚卸しでは、テーブルやファイル、項目、更新頻度、利用目的、参照元の一覧を作成する。併せて、アーカイブ済みデータの所在や、暗黙的な依存関係（アプリコード側の前提）も明らかにする。
2.1.2 データ品質評価
欠損率、重複率、型逸脱、表記ゆれ、過去定義とのズレを評価する。評価結果は変換ルールや例外処理の設計に反映され、検証の重点領域を決める材料になる。
2.1.3 業務要件と参照整合性要件
業務要件は「いつ・誰が・何を使うか」を明確にする。参照整合性要件は、主従関係や必須キーの有無、時点整合の要否を含む。履歴データの扱いでは、過去参照の再現性も検討対象となる。
2.1.4 移行スケジュールと制約条件
締切、稼働時間、作業可能曜日、利用できる人員、外部調整の余地を整理する。データの取得元がバッチ依存の場合は、実行順や抽出窓の制約が移行方式に影響する。
2.2 移行方式の選定
方式選定は、時間、品質、リスクのバランス問題である。要件定義で定めた成功基準に基づき、採用候補を比較する。
2.2.1 全量移行
全量移行は初期投入が大きくなるが、設計が単純になりやすい。品質ゲートを強く設定すれば、移行後の状態を一度に確定できる。ただし、データ量が多い場合は時間制約と負荷が課題になる。
2.2.2 差分移行
差分移行は、切替までの整合を維持しやすい設計を取りやすい。変更検知の手段（更新日時、イベントログ、論理削除の扱いなど）を確立することで、取りこぼしを減らせる。
2.2.3 並行稼働と最終切替
並行稼働では、旧環境と新環境を一定期間同時に動かす。最終切替では、以後どちらを正とするか、同期の最終ポイントを明確にし、利用者への影響を最小化する。
2.2.4 方式選定の判断基準
判断基準には、許容ダウンタイム、データ量、変更頻度、参照依存の強さ、回復可能性が含まれる。特にロールバックの難易度は重要で、復旧手段が現実的な方式を選ぶ。
2.3 変換設計（マッピングとルール）
変換設計は移行の中核である。項目対応、値の意味、重複の解消、関連データのつながりを一貫したルールとして定義する。
2.3.1 スキーマ変換（項目・型）
項目名だけでなく、桁数、文字コード、日時の解釈、nullable条件などを扱う。新スキーマ側で制約が増える場合は、事前にデータを整形して違反を減らす設計が必要になる。
2.3.2 値変換（コード体系、正規化、表記ゆれ）
コード体系が異なる場合は対応表を作り、未知値の扱い（エラーにする、既定値にする、別列に保持するなど）を決める。表記ゆれでは、正規化方針（大文字小文字、全角半角、空白、略称）を統一する。
2.3.3 重複排除・統合ルール
同一人物や同一商品に見えるデータが複数存在する場合、統合キーと優先順位を定める。完全一致のみでなく、許容できる類似判定を用いる場合は誤統合のリスクを評価し、例外の救済経路を確保する。
2.3.4 関連データの整合性設計
関連があるデータ群では、同時に変換するか、順序を制御するかを決める。キー再生成を行う場合は、参照先の整合が壊れないように変換単位とID体系を設計する。
2.4 移行アーキテクチャ
アーキテクチャ設計は、再実行性、監視性、拡張性を左右する。変換処理を一枚岩にせず、役割分担ができる構成が望ましい。
2.4.1 移行パイプライン設計
抽出、変換、ロード、検証、反映の各段をパイプラインとして定義する。途中で失敗しても、どこから再開できるかを設計に織り込むと、作業の手戻りが減る。
2.4.2 ETL/ELTの適用方針
ETLは変換を抽出側または専用処理で行い、ロード時の負荷を抑える。ELTは格納後に変換を行うため、処理基盤の性能を活かしやすい。選択は変換コストと、ターゲット環境の能力に依存する。
2.4.3 バッチ処理とストリーミングの方針
差分同期が必要なら、一定間隔のバッチまたはイベントベースのストリーミングが候補となる。後者は設計が複雑になりやすいが、切替までの遅延を小さくできる場合がある。
2.4.4 監視・ログ設計
監視では、処理量、失敗率、到達時間、外れ値などを可視化する。ログは追跡性が重要で、データの出どころ（抽出時刻やバッチID）を紐づけると検証が容易になる。
3 実装・実行・検証
3.1 データ抽出
抽出段階は、以後の整合に影響する。抽出条件、読み取り一貫性、再実行性を意識して設計する。
3.1.1 抽出方式（クエリ、ファイル、API）
クエリ抽出は対象範囲の制御がしやすい。ファイル出力は手順が単純な一方で、整合性の保証方法を別途必要とする。API抽出は変更検知と相性が良いが、レート制限や応答遅延を考慮する。
3.1.2 抽出時の整合性確保
同時更新がある環境では、スナップショットや一貫した時点条件を用いる。論理削除を含む場合は、抽出基準を明確にして、後段での取り違えを防ぐ。
3.1.3 タイムスタンプと再実行性
抽出には、再実行時に同じ範囲が取れるよう基準時刻や版管理を設定する。タイムゾーンの扱い、同一時刻での順序性、後追いデータの吸収方法も決めておく。
3.2 データ変換とロード
変換はルールの実装であり、ロードは性能と整合性の実現である。両者を分離して評価できる構成が望ましい。
3.2.1 変換処理の実装方針
変換はバリデーションと組み合わせると事故が減る。例外値は隔離領域に退避し、後で修正できる仕組みを設けると運用が安定する。
3.2.2 ロード手順（バルクロード、逐次投入）
バルクロードは大量投入に向くが、失敗時の切り分けが難しくなりがちである。逐次投入は細かな制御が可能で、検証を挟む設計と相性が良い。
3.2.3 トランザクションとリトライ
リトライの単位は重要で、粒度を誤ると重複が生まれる。整合性制約を満たす順序（親→子など）を守り、失敗時は影響範囲を最小化する。
3.3 検証（テストと品質確認）
検証は単体ではなく、段階ごとのゲートとして設計する。移行全体の不確実性を段階的に下げていく。
3.3.1 構造検証（スキーマ一致）
列数、型、制約、インデックスの有無などを比較する。差異が許容される場合は条件を明文化し、許容外なら処理を止める。
3.3.2 内容検証（行数、分布、サンプル照合）
行数の一致だけでなく、分布（件数、長さ、カテゴリ比率）を確認する。サンプル照合では、代表例に加えて境界条件（最小、最大、欠損が多い区分）も選ぶ。
3.3.3 整合性検証（外部キー、参照整合）
外部キー制約が存在する場合は、参照先の欠落や不正対応を検出する。履歴では時点整合の検査が必要になることがあり、再現可能な基準で確認する。
3.3.4 性能検証（移行後の検索・更新）
移行後の検索応答や更新時間を測る。特に主要クエリについて、インデックスやパーティションの影響が反映されているかを確認する。
3.4 移行の切替手順
切替は短時間で多くの変更が起きるため、手順書の精度が成否に直結する。事前にシミュレーションして、意思決定のタイミングを揃える。
3.4.1 最終差分取り込み
最終差分は、切替時刻付近で発生する変更を取り込む工程である。取り込み基準（どの時刻を境にするか）と、反映の優先順位を定め、再実行時の重複を抑える。
3.4.2 切替の手順書と手順確認
手順書には担当、実行順、確認項目、停止基準、連絡経路を含める。実施前にリハーサルを行い、理解の差を縮めることが望ましい。
3.4.3 後続バッチ・連携の調整
切替後のバッチは入力元の変更に影響される。連携先の参照仕様も確認し、受付側の互換性（新旧の同居期間など）を調整する。
3.5 ロールバックと復旧
移行には失敗の可能性があるため、復旧計画を先に決める。判断基準と影響範囲を明確にし、止める勇気を支える。
3.5.1 ロールバック条件
条件は、品質検証の不合格、重大な整合性崩れ、性能逸脱、連携障害など具体的に定める。感覚的な判断にせず、測定結果で決める。
3.5.2 復旧手順と影響範囲の管理
復旧は旧環境へ戻すだけでなく、切替で変更した設定や一時的なデータを元に戻す作業を含む。影響範囲を限定するため、変更点の一覧管理が役に立つ。
3.5.3 進捗報告と判断基準
進捗は定期報告と、重要イベント時の即時報告に分ける。判断基準を共有しておくことで、現場での意思決定が遅れにくくなる。
4 セキュリティ・運用・ガバナンス
4.1 セキュリティ設計
移行はデータが動く局面であり、漏えいリスクが上がりやすい。機密性、完全性、可用性を同時に守る設計が求められる。
4.1.1 データ取り扱い（機密、個人情報、秘匿）
機密区分に応じて、抽出範囲、利用者、保管場所を制限する。個人情報が含まれる場合は、同意や利用目的に沿った扱いと、追跡可能な処理記録を整える。
4.1.2 暗号化と鍵管理
転送中と保管中の両方で暗号化を行い、鍵のライフサイクル（発行、ローテーション、失効）を運用手順に組み込む。鍵へのアクセス権は最小限にし、監査で追跡できるようにする。
4.1.3 アクセス制御（最小権限、監査ログ）
移行作業者、検証担当、システム自動処理の権限を分ける。監査ログは、誰がいつどのデータへアクセスし、どの操作を行ったかを残すために必須となる。
4.2 データ品質の継続管理
移行後も品質は監視されるべきである。移行は一度限りの作業でも、データは継続的に変化する。
4.2.1 ルールベース検証の運用
検証ルールを定期実行し、逸脱を早期発見する。欠損率や参照切れ、コード体系の異常出現など、業務に直結する項目を優先する。
4.2.2 障害時の監視とアラート
アラートは通知先と重要度を適切に設計する。ノイズが多いと形骸化するため、閾値や再通知条件を調整し、対応可能な頻度に抑える。
4.2.3 監査可能性（証跡、レポート）
証跡はデータ起点で追えることが望ましい。移行後も、品質検証の結果や修正履歴がレポートとして残ると、説明責任の負担が軽くなる。
4.3 コンプライアンスと記録
規程や契約に沿った記録の管理が重要になる。技術作業だけで終わらせず、意思決定の根拠を残す。
4.3.1 合意事項・要件の文書化
要件と判断根拠は、変更が起きても再確認できる形で保存する。特に例外ルールや許容差は、後から検証するための材料となる。
4.3.2 チェンジ管理と承認フロー
変換ルールや切替手順の変更は、誰が承認し、いつ反映するかを管理する。承認ログが整っているほど、手戻りが減る。
4.3.3 保存期間と廃棄手続き
移行に使ったデータやログにも保存期間が必要である。目的達成後の廃棄を手順化し、廃棄の証明や削除範囲の確認を行う。
4.4 運用引継ぎとドキュメント
運用への引き継ぎは、手順と判断の両方を渡すことが目的である。属人性を減らすために、ドキュメントを具体にする。
4.4.1 運用手順書
運用手順書には、定期作業、障害時対応、エスカレーション条件、再実行手順を含める。実際に使える粒度で記載し、曖昧な表現を避ける。
4.4.2 問い合わせ対応（既知の差異）
移行では、完全な同一性が難しいケースがある。既知の差異（値の丸め、表記の正規化など）を一覧化し、問い合わせ時に説明できる形にする。
4.4.3 移行後のチューニング計画
性能や検索性は初回で最適化しきれない場合がある。観測値に基づき、インデックス再設計や分割方針の見直しを行う計画を置く。
5 よくある課題と対策
5.1 欠損・不整合データへの対応
欠損や不整合は、品質の根幹に関わる。原因を分類し、ルール化して対処することで再発を抑える。
5.1.1 欠損値の扱い（補完、除外）
欠損のままにするのか、既定値を入れるのか、別扱いの列へ保存するのかを定める。補完では根拠（補完元や計算方法）を保持し、意思決定が追跡可能な形にする。
5.1.2 参照整合性の復元
参照先が欠けている場合は、復元可能なデータを補うのか、整合性制約を緩和するのかを判断する。どちらにせよ、業務影響を前提に慎重な設計が必要になる。
5.1.3 重複データの整理
重複は集計結果や表示に影響する。削除基準や統合ルールを明確にし、後から追跡できるよう処理ログを残す。
5.2 性能・時間制約への対策
移行は時間との戦いでもある。ボトルネックを特定し、処理を現実的に収める工夫を行う。
5.2.1 並列化とスロットリング
並列化は処理時間を短縮できるが、対象システムの負荷増加が副作用となる。スロットリングにより、抽出元やネットワークの過負荷を抑えつつ進める。
5.2.2 バッチ時間の最適化
バッチの粒度、再実行の戦略、前処理の有無を調整する。不要な全件再計算を避け、増分処理が可能な設計に寄せると効果が大きい。
5.2.3 インデックス戦略
インデックスは検索性能を高めるが、ロード性能を下げることがある。ロード中の作成タイミングや、必要最小限から段階的に増やす計画が有効になる。
5.3 人的ミスと手戻りの抑制
ミスは防ぐだけでなく、早期に検知することが重要である。手順と検証を組み合わせて被害を最小化する。
5.3.1 チェックリスト運用
チェックリストは、実行前後の確認事項を標準化する。特に切替時には、必要な観測値を漏れなく確認するための手段として機能する。
5.3.2 自動検証の導入
自動検証は再現性を高める。検証対象を絞り、すべきことを自動化しすぎない設計が実務上の現実解になる。
5.3.3 手順の標準化
複数人で作業する場合、解釈の余地を減らすことが重要である。標準化された手順により、同じ状況なら同じ判断を下しやすくなる。
5.4 失敗パターンから学ぶ
典型的な失敗は、設計不足、ルールの曖昧さ、切替計画の甘さに集約されやすい。事前に学習して予防する。
5.4.1 事前検証不足
検証が軽いと、切替後に不具合が顕在化しやすい。特に参照整合や境界条件のテスト不足は重大化しやすい。
5.4.2 変換ルールの曖昧さ
ルールが文章や口頭に留まると、実装者ごとの差が出る。例外時の扱いが決まっていない場合、現場判断がばらつき品質が下がる。
5.4.3 切替計画の不備
切替時の確認項目が不十分だと、問題に気づく前に影響が広がる。復旧手順が手元にない、あるいは判断基準が曖昧だと復旧が遅れる。
6 事例・パターン集（学習用）
6.1 小規模移行の進め方
小規模では、設計を過剰にせずとも成功しやすいが、最低限の検証は必要である。学習目的では、全体像が見える構成が向く。
6.1.1 代表的なデータセット
対象はユーザー管理、商品情報、設定値など限定した範囲が代表的である。依存関係が少なく、参照先が明確なデータを選ぶと評価が進めやすい。
6.1.2 最小構成での検証
最小構成の検証では、スキーマ一致、主要項目のサンプル照合、整合性チェックを優先する。完全な網羅は難しくても、重大な誤差の兆候を捉えることが焦点になる。
6.2 大規模移行の進め方
大規模では、リスクが広がるため段階管理が必須となる。小さく作って確かめ、段階的に拡大する発想が有効である。
6.2.1 工程分割と段階移行
工程を抽出、変換、ロード、検証のまとまりに分け、単位ごとに完了基準を設ける。段階移行では、最初に低リスク領域から開始し、学びを次へ反映する。
6.2.2 品質ゲートの設計
品質ゲートは処理の通過条件である。構造、行数、分布、参照整合、性能の順に段階を作ると、問題の所在が特定しやすくなる。
6.3 運用しながらの移行
運用を止めずに進める場合、二重更新や遅延が課題となる。並行稼働と同期設計が中心になる。
6.3.1 並行稼働の設計
並行稼働では、どのデータが新旧のどちらで更新されるのかを整理する。参照側は一時的に両方に対応させるのか、切替前後でルーティングを変えるのかを決める。
6.3.2 差分同期の考え方
差分同期では、変更検知の基準と反映順序を一貫させる。遅延や欠落が起きたときの再同期方針（再抽出、再計算、整合修復）を設計に含める。
6.4 形式変換を伴う移行
形式変換があると、値の意味が変わり得るため、変換ルールの妥当性検証がより重要になる。
6.4.1 正規化・非正規化の選択
正規化は重複を抑え整合性を保ちやすい。非正規化は読み取り性能や運用簡便性を優先できるが、更新時の整合維持が課題になる。用途と更新頻度を踏まえて選ぶ。
6.4.2 コード体系の統一
コード体系の統一では、対応表と例外処理が鍵となる。未知コードの扱い、旧コードの参照方法、変換後の追跡性（元コードをどこまで保持するか）を明確にする。