// シス担のミカタ
クラウド移行

データ移行 でーたいこう

マイグレーションETLデータクレンジングカットオーバーバックアップクラウド移行
データ移行について教えて

簡単に言うとこんな感じ！

引っ越しのとき家具を新居に運ぶみたいに、古いシステムのデータを新しいシステムにそのまま移し替える作業だよ。ただ「コピーするだけ」じゃなくて、不要なデータの整理や形式の変換も必要で、実はプロジェクトの中でも一番トラブルが起きやすい工程なんだ！

データ移行とは

データ移行（Data Migration） とは、現在使っているシステムやストレージに保存されたデータを、新しいシステム・クラウド・データベースへ移し替えるプロセス全体を指します。英語では “Migration”（マイグレーション）とも呼ばれ、システムリプレースやクラウド移行プロジェクトでは必ずと言っていいほど発生する作業です。

単なるコピー作業に思われがちですが、実際には「移行元のデータ形式を移行先に合わせて変換する」「不正確・重複・古いデータを整理（データクレンジング）する」「移行後のデータが正しいか検証する」といった複数の工程が必要です。データ量が多いほど、またシステムが古いほど難易度は上がります。

ビジネス的な観点では、データ移行の失敗は業務停止・データ消失・顧客への影響に直結するリスクがあります。「とりあえず新システムを入れたけどデータが使えない」という事態を防ぐために、移行計画は発注・選定の段階から必ず議題に上げるべき重要テーマです。

データ移行の流れと主な工程

データ移行は大きく5つのフェーズで進みます。

フェーズ主な作業ポイント
① 現状調査・棚卸し移行対象データの洗い出し、量・形式・品質の確認「何を移すか」を決める最重要フェーズ
② 設計・マッピング移行元と移行先のデータ項目の対応付け（フィールドマッピング）形式の違いや名称の違いを整理
③ データクレンジング重複・欠損・誤りのあるデータを修正・削除ゴミデータを新システムに持ち込まないために必須
④ 移行（本番・リハーサル）ツールやスクリプトでデータを実際に移送事前にリハーサル（テスト移行） を必ず実施
⑤ 検証・カットオーバー移行後のデータ件数・内容の確認、旧システムから切り替え問題があればロールバック（元に戻す）できる体制を用意

覚え方：「現・設・ク・移・検」

「現状調査→設計→クレンジング→移行→検証」の頭文字で「げんせつくいけん」。少し強引ですが、5つのフェーズを順番に覚えるのに役立ちます。

ETLとは？

データ移行の中核となる処理方式に ETL（イーティーエル） があります。

  • E（Extract）：抽出　→ 移行元からデータを取り出す
  • T（Transform）：変換　→ 形式・文字コード・項目名などを新システム向けに変換する
  • L（Load）：格納　→ 変換済みデータを新システムに書き込む

ETLはクラウド移行や基幹システム刷新でよく使われる考え方で、専用ツール（AWS Glue、Talend、DataSpiderなど）を使って自動化するのが一般的です。

歴史と背景

  • 1960〜70年代：メインフレーム時代からシステム更改のたびにデータ移行は存在していたが、専門的な方法論は確立されていなかった
  • 1990年代：ERPパッケージ（SAPなど）の普及とともに、異なるデータベース間の移行ニーズが急増。データ移行プロジェクトの失敗が多発し、方法論の整備が進む
  • 2000年代：企業合併・買収（M&A）の増加に伴い、複数システムのデータ統合（データ統合/コンソリデーション）が重要テーマに
  • 2010年代：クラウド移行（オンプレミス→AWS・Azure・GCPなど）の波が到来。リフト＆シフト（そのままクラウドに移す）戦略と合わせてデータ移行が急増
  • 2020年代：DX推進・基幹系クラウド化が加速し、データ移行は経営課題に直結するプロジェクトとして認識されるようになった。移行専門のマネージドサービス（AWS DMS、Azure Database Migration Serviceなど）も整備

移行方式の種類と比較

データ移行には、停止時間やリスク許容度に応じていくつかの方式があります。

データ移行方式の比較 ビッグバン移行 一括移行 ✔ 短期間で完結 ✔ 管理がシンプル ✘ 失敗時のリスク大 ✘ 業務停止時間が長い 向き: 小規模・データ量少 段階的移行 フェーズ分割 ✔ リスク分散 ✔ 問題の影響範囲が限定的 ✘ 旧旧・新新並行期間が発生 ✘ 整合性管理が複雑 向き: 中〜大規模 並行稼働移行 新旧同時運用 ✔ 安全性が最も高い ✔ 切り戻しが容易 ✘ コスト・工数が最大 ✘ 二重入力が発生 向き: 基幹系・高可用性要件 移行方式の選び方 リスク許容度・データ量・業務停止可能時間・予算の4軸で判断する 停止時間: 長い ／ リスク: 高 停止時間: 中 ／ リスク: 中 停止時間: 短い ／ リスク: 低

よくある失敗パターン

データ移行プロジェクトで発注側がはまりやすい落とし穴をまとめます。

失敗パターン原因対策
データが想定より汚れていた移行前の品質調査不足事前にデータプロファイリング（品質調査）を実施
移行後に件数が合わない検証基準を決めていなかった移行前に件数・チェックサムなどの検証基準を明文化
カットオーバー当日に時間切れリハーサルをしていない本番同等のリハーサルを最低2回実施
旧システムのデータ定義書がないドキュメント不備移行前に現行システムのデータディクショナリを作成
ベンダー任せにして認識ズレ発注側の関与が少ない発注側も移行対象データのオーナー確認に参加する

関連する規格・RFC

※ データ移行自体を直接規定するIETF RFC・ISOの単一規格はありませんが、関連する標準として以下が参照されます。

規格・番号内容
ISO/IEC 25012データ品質モデルの国際規格。移行データの品質評価基準として参照される
RFC 4180CSVフォーマットの事実上の標準。データ移行でよく使われるファイル形式を規定

関連用語

  • クラウド移行 — オンプレミスのシステムをクラウドに移転するプロジェクト全体
  • ETL — データの抽出・変換・格納を行うデータ処理方式
  • データクレンジング — 移行前に不正確・重複・欠損データを修正・整理する作業
  • カットオーバー — 旧システムから新システムへ正式に切り替えるタイミング・作業
  • バックアップ — データ消失に備えてコピーを保存しておく仕組み
  • リフト＆シフト — 既存システムをほぼそのままの構成でクラウドに移行する戦略
  • データベース — 構造化されたデータを管理・検索するためのシステム
  • 基幹システム — 企業の業務中枢を担う販売・会計・人事などの情報システム