クラウドデータ移行の手順とは?移行ツール・整合性検証・大容量転送の実務を実装者向けに解説

クラウドデータ移行は、オンプレミスのファイルサーバーやデータベース、ストレージに蓄積したデータを、AWS・Azure・Google Cloudなどのクラウド環境へ移送する作業を指します。この記事では、移行対象データの分類から、AWS DataSync・AWS DMS・Azure Data Box・Storage Transfer Serviceといった移行ツールの選定基準、業務停止時間と整合性を両立させるCDCレプリケーションの設計、回線帯域から試算する大容量転送と物理搬送の使い分けまで、移送を実装する担当者の視点で手順をまとめた実務ガイドです。どの容量・帯域・停止許容時間ならどの方式を採るべきか、採用条件と見送るべき場面も条件付きで言い切ります。

まとめ：クラウドデータ移行の方式選定と実務手順の結論

クラウドデータ移行の設計は「データ容量」「回線帯域」「停止許容時間」の3つの数字を先に確定させると、方式がほぼ機械的に決まります。数TB以内で帯域に余裕があるならネットワーク経由のオンライン転送、数十TBを超えて転送日数が週単位に伸びるならAWS SnowballやAzure Data Boxなどの物理搬送デバイス、データベースで業務停止がほぼ許されないならCDC（変更データキャプチャ）による継続レプリケーションが基本線です。100Mbpsの実効帯域で10TBを送ると理論値でも10日前後かかる計算になり、この試算だけで経路の選択は大きく絞れます。

手順面の要点は2つあります。1つは、移送そのものより前に転送経路と切り替え方式を決め、リハーサルで転送速度と手順を実測しておくことです。もう1つは、移送後の件数照合・チェックサム検証を計画に組み込み、検証が終わるまで移行元データを消さないことです。移行の失敗は「送れなかった」よりも「送ったつもりのデータが欠けていた・古かった」という形で現れます。以下、対象データの分類から順に掘り下げます。

クラウドデータ移行の全体像と移送対象データ・転送経路の基本整理

はじめに、何を・どの経路で送るのかという全体像を固めます。移行対象の種類によって使うツールも手順も変わるため、自社のデータがどれに当たるかを最初に仕分けておくと後工程がぶれません。

ファイルサーバー・データベース・仮想マシンで異なる移行対象データの3分類

移行対象は大きく3つに分かれます。第一に、ファイルサーバーや NAS 上の非構造化データです。文書・画像・設計データなどで、移行先はAmazon S3やAzure Blob Storageのようなオブジェクトストレージ、またはAmazon FSxなどのマネージドファイルサービスになります。第二に、データベースです。OracleやSQL Server、MySQLなどのRDBが典型で、単純なファイルコピーでは移せず、ダンプ・リストアかレプリケーションという専用の手順を踏みます。第三に、仮想マシンイメージやアプリケーション一式で、これはデータ移行というよりサーバー移行の領域です。

この3分類で難易度と停止時間の性質が変わります。ファイル系は容量が大きい代わりに転送中も業務を続けやすく、データベースは容量が小さくても更新が止まらないぶん切り替え設計が難しくなります。本記事は前者2つ、つまりファイル系とデータベースの移送手順が中心です。

システム移行プロジェクト全体とデータ移送プロセスの切り分けと本記事の範囲

クラウド移行のプロジェクトは、対象システムの棚卸し、移行方式（リホスト・リプラットフォームなど）の決定、移行先の構成設計、データ移送、切り替え、運用移管という流れで進みます。計画立案から費用感、移行方式の比較といったプロジェクト全体の進め方はクラウド移行の進め方で発注者視点から解説しているため、本記事はそのなかの「データ移送」工程だけを実装の解像度で受け持ちます。

切り分けを明確にすると、データ移送は「移行先の器が設計済みであること」を前提に始まる工程です。移行先のリージョン・ストレージクラス・ネットワーク接続が未確定のまま移送ツールの検討に入ると、転送先の変更で作業がやり直しになります。クラウドの基本構成やAWSの各サービスの位置づけから確認したい場合はクラウドとは・AWSとはが上位概念の整理に向いています。

ネットワーク転送と物理搬送という2つの転送経路の構造と選び分けの前提

データをクラウドへ運ぶ経路は2系統しかありません。1つはインターネットまたは専用線を経由するネットワーク転送（オンライン転送）で、転送用のエージェントやサービスを使ってデータを送ります。もう1つは物理搬送（オフライン転送）で、クラウド事業者から専用のストレージデバイスを借り、データをコピーして返送し、事業者側でクラウドストレージへ取り込んでもらう方式です。

選び分けの支配変数は「容量÷実効帯域＝転送日数」です。回線が細い拠点から数十TBを送る場合、ネットワーク転送では週単位から月単位の日数がかかり、その間の差分管理も膨らみます。転送日数が業務上許容できる期間を超えるなら物理搬送に切り替える、というのが基本の考え方です。具体的な試算とデバイスの選択肢は次章で扱います。

AWS・Azure・Google Cloudの移行ツールと移送方式の選定基準

経路と対象が決まったら、ツールを選びます。主要3クラウドはいずれもファイル向け・データベース向け・物理搬送の3系統を公式サービスとして提供しており、まず公式ツールから検討するのが定石です。

ファイル・オブジェクト向け転送サービス3種の機能と対応環境の比較

ファイルサーバーやオブジェクトストレージのデータ移送には、各クラウドの転送サービスを使います。2026年時点の主要な選択肢は次の通りです。

選定は移行先のクラウドで決まるため比較で迷う場面は少なく、確認すべきは移行元プロトコル（NFS/SMB）への対応と、転送後検証・差分同期の有無です。とくに差分同期は、初回の全量転送後に更新分だけを再転送して切り替え直前の差を小さくする機能で、業務を続けながら移すファイル移行では実質的な前提機能になります。移行先となるオブジェクトストレージやファイルストレージの種類と使い分けはクラウドストレージとはで整理しているため、器の選定と合わせて確認してください。

スキーマ変換とCDCに対応するデータベース移行サービスの選定基準

データベースの移送には、AWS DMS（Database Migration Service）、Azure Database Migration Service、Google CloudのDatabase Migration Serviceという同種のマネージドサービスを使います。いずれも初回の全量ロードに加えて、CDC（Change Data Capture＝変更データキャプチャ）による継続レプリケーションに対応しており、移行元の更新を移行先へ流し続けながら切り替えタイミングを選べる点が共通の価値です。

選定基準は3つあります。第一に、移行元と移行先のエンジンの組み合わせに対応しているかです。OracleからPostgreSQLへのような異種間移行では、スキーマやストアドプロシージャの変換ツール（AWSならSchema Conversion Tool）を併用する前提で工数を見積もります。第二に、CDCが移行元のログ読み取りを要求する点です。Oracleの REDO ログやMySQLの binlog へのアクセス権限と設定変更が必要になり、本番DBへの設定変更をいつ入れるかが調整事項になります。第三に、LOB（大きなオブジェクト列）や無主キー表など、レプリケーションが苦手とするデータの有無です。ここに引っかかる表は、ダンプ・リストアでの個別移送に切り出したほうが安全に運べます。

数十TB超で候補になる物理搬送デバイスと帯域からの転送日数試算

ネットワーク転送の所要日数は「容量(TB)×8÷実効帯域(Gbps)÷86,400秒」で概算できます。目安として、実効100Mbpsで1TBなら1日前後、10TBで10日前後、100TBでは3ヶ月規模です。実効帯域は契約帯域の5〜7割程度で見積もり、業務時間帯の帯域制限を入れるならさらに伸びます。この試算が許容期間を超えるとき、物理搬送が候補になります。

2026年時点で提供されている主なデバイスは、AWS Snowball Edge（1台で80TB級の使用可能容量を持つモデルを提供）、Azure Data Box（100TB級の標準モデルのほか、小容量のDisk、ペタバイト級のHeavy）、Google CloudのTransfer Appliance（数十TB〜300TB級のモデル）です。いずれも耐タンパー筐体と暗号化を備え、発注から返送・取り込み完了まで2〜4週間程度を見込みます。物理搬送は「輸送期間中のデータ更新分をどう追いつかせるか」が設計課題になるため、搬送で大部分を運び、残りの差分だけネットワークで同期するハイブリッド構成が実務の定番です。

ダウンタイムと整合性を両立させるデータ移送プロセスの設計手順

ツールが決まったら、移送プロセスを設計します。焦点は「業務をどれだけ止められるか」と「移行先のデータが正しいことをどう証明するか」の2点に集約されます。

停止許容時間から決める一括停止方式と段階移行方式の切り替え設計

切り替え方式は停止許容時間から逆算して決めます。週末や夜間にシステムを止められるなら、業務停止→最終バックアップ→転送→検証→切り替えという一括停止方式（ビッグバン方式）が最も単純で、手順の分岐が少ないぶん失敗要因も減ります。停止できる時間内に「最終差分の転送＋検証」が収まるかをリハーサルで実測し、収まるならこの方式を選んでください。

止められない、または対象が多すぎて一晩に収まらない場合は、部門別・システム別に分けて順次移す段階移行方式にします。段階移行は期間中に新旧環境が併存するため、どちらのデータが正か（マスタの所在）を移行単位ごとに明文化しておく必要があります。ファイルサーバーであれば、移行済み領域を移行元で読み取り専用に切り替えて二重更新を防ぐ運用が、併存期間の事故を減らす定石です。

CDCレプリケーションを使う無停止移行と切り替え当日の手順6段階

データベースで停止をほぼゼロに近づけたい場合は、CDCレプリケーションを軸に次の流れで進めます。

1. 移行先DBを構築し、初回の全量ロードを実行する
2. CDCを開始し、移行元の更新を移行先へ流し続ける
3. レプリケーション遅延が定常的に数秒〜数分に収まることを確認する
4. 切り替え当日、移行元への書き込みを短時間停止し、遅延ゼロ（差分追いつき）を確認する
5. アプリケーションの接続先を移行先へ切り替えて動作確認する
6. 移行元を読み取り専用で一定期間保持し、切り戻し経路を確保する

実際の停止は手順4〜5の数分〜数十分だけになります。注意すべきは手順6で、切り替え直後に問題が見つかった場合の切り戻しは「移行先で発生した更新を移行元へ戻す」逆方向の同期が要るため、切り戻し判断の期限（例：切り替え後24時間）をあらかじめ決めておかないと、戻ること自体が新たな移行作業になります。

件数照合・チェックサム・並行稼働比較で行う移行後データの整合性検証

移送が終わった状態は、まだ「送り終わった」に過ぎません。検証は3層で行います。第一が件数照合で、テーブルごとの行数・ファイル数と総容量を移行元と突き合わせる作業です。第二にチェックサム検証で、ファイルならSHA-256などのハッシュ比較、DBなら主キー範囲ごとの集計値比較を行います。AWS DataSyncのように転送後検証を内蔵するツールでも、DB移行では別途の照合が必要です。第三に業務検証で、主要な帳票や集計処理を新旧両環境で実行して結果を突き合わせます。

検証で不一致が出たときに原因を切り分けられるよう、移行元データは検証完了と切り戻し期限を過ぎるまで削除しないでください。この検証設計を含めたデータ移送の計画づくりは、移行元の構成調査から切り替えまでを一括で請け負うシステムマイグレーション・リプレイスのような受託サービスに委ねる選択肢もあります。自社に移行経験者がいない場合、検証項目の設計だけでも外部の実績あるひな形を使うと抜けが減ります。

データ容量・回線帯域・停止許容時間の3軸で言い切る移送方式の採用条件

最後に、ここまでの内容を選定基準として言い切ります。迷ったらこの章の条件に当てはめてください。

容量と帯域と停止許容時間の組み合わせで決まる移送方式の早見基準

典型的な組み合わせごとの推奨方式は次の通りです。

この表に載らない条件で判断に迷うのは「数TB規模だが帯域も停止時間も中途半端」なケースです。その場合は転送日数の試算を先に置き、試算が3営業日を超えるなら物理搬送側、収まるならオンライン側に倒すと決めておくと、検討が長引きません。移行先が専有基盤（プライベートクラウド）の場合は閉域接続の帯域設計から話が始まるため、プライベートクラウド移行で移行先側の設計論点を先に確認してください。

エグレス料金と双方向同期まで見据えたデータ取り出し設計の判断

クラウドへ入れる転送（イングレス）は主要3社とも原則無料ですが、取り出す転送（エグレス）は従量課金です。移行設計の段階で「戻す・二拠点で持つ」可能性を織り込んでおくと、後の選択肢が狭まりません。参考になる動きとして、2024年にGoogle Cloud・AWS・Azureの3社が、解約・移行を目的とするデータ持ち出しについて申請ベースでエグレス料金を免除する方針を相次いで発表しています（EUデータ法への対応を背景とした措置で、恒常的な運用トラフィックは対象外）。完全な撤退時の持ち出しコストは以前より下がった一方、日常的にデータを出し入れする構成では依然としてエグレス費が効きます。

判断として、分析用データなど社外・他クラウドから頻繁に参照されるデータは、エグレス費を月次で試算してから配置を確定してください。オンプレミスとクラウドで同じデータを双方向に同期し続ける構成は、転送費と整合性管理の両面で負債になりやすいため、恒久運用としては採らず、移行期間中の併存手段に限定するのが安全です。

ツールによる一括移行を見送るべき場面と手作業移送に倒す失敗回避の条件

移行ツールが常に正解とは限りません。見送るべき場面を3つ挙げます。第一に、対象が数百GB以下でかつ一度きりの移送なら、ツールのセットアップより OS 標準のコピーやデータベースのダンプ・リストアのほうが速く終わります。エージェント導入やIAM設定の準備工数が、転送そのものより大きくなるためです。第二に、移行を機にデータを捨てたい場合です。ファイルサーバーの中身は実務では相当部分が数年間未参照のデータで、全量を同期ツールで運ぶと不要データの保管費まで移行後に引き継ぎます。アーカイブ基準を決めて仕分けてから運ぶほうが、移行後のストレージ費が下がります。

第三に、更新頻度が極端に高くレプリケーション遅延が追いつかないDBです。遅延が縮まらないままCDCで切り替えると、切り替え時の停止が結局長引きます。この場合は業務側と交渉して計画停止の枠を取り、一括停止方式に倒すほうが総リスクは小さくなります。無停止という要件を疑うことも、移送設計の一部です。

よくある質問

データ移送の計画時に実務でよく挙がる質問をまとめました。

クラウドへのデータ移行にはどれくらいの期間がかかりますか？

転送そのものは「容量÷実効帯域」で概算でき、実効100Mbpsなら1TBで1日前後、10TBで10日前後が目安です。ただし実務の期間はその前後の工程で決まり、対象データの棚卸しと仕分けに2〜4週間、リハーサルと検証に1〜2週間を見込むのが現実的です。数十TB規模で物理搬送を使う場合は、デバイスの発注から取り込み完了まで2〜4週間程度を転送期間として計画してください。

業務を止めずにデータ移行できますか？

データベースであればCDC（変更データキャプチャ）による継続レプリケーションで、停止を切り替え時の数分〜数十分まで縮められます。ファイルサーバーは差分同期を繰り返して最終差分を小さくし、切り替え時だけ書き込みを止める方式が一般的です。完全な無停止は切り戻し設計まで含めると難易度が上がるため、短時間の計画停止を確保できるならそのほうが総リスクは小さくなります。

データ移行ツールは何を基準に選べばよいですか？

移行先のクラウドの公式サービスをまず候補にし、①移行元への対応（NFS/SMB・DBエンジンの組み合わせ）、②差分同期・CDCの有無、③転送後検証の有無、の3点で確認します。ファイル系はAWS DataSyncやStorage Transfer Service、DB系はAWS DMSなど各社のDatabase Migration Service系が対応範囲の広い選択肢です。サードパーティ製ツールは、公式サービスが対応しない組み合わせ（特殊なNASや旧バージョンのDB）に限って検討すれば十分です。

移行後のデータが正しいことはどう確認しますか？

件数照合（行数・ファイル数・総容量）、チェックサム比較（ファイルのハッシュ値やDBの集計値）、業務検証（帳票・集計処理の新旧突き合わせ）の3層で確認します。転送ツールの検証機能はネットワーク転送の欠落を検出するもので、業務的な正しさまでは保証しません。検証が完了し切り戻し期限を過ぎるまで、移行元データは削除せず読み取り専用で保持してください。

一度クラウドへ移行したデータを別の環境へ戻せますか？

技術的には戻せますが、取り出し時のエグレス料金と転送日数が発生します。2024年以降、主要3社は解約・移行目的の持ち出しについて申請ベースの料金免除を発表しており、完全撤退時の障壁は下がりました。一方、日常的な出し入れは従量課金のままです。戻す可能性があるデータは、標準的な形式（オープンなファイル形式・移植性の高いDBエンジン)で保管し、特定サービス固有の形式への変換は必要最小限に留めておくと、取り出し時の変換工数を抑えられます。

関連記事

• クラウド移行の進め方：本記事が扱うデータ移送を含む、移行プロジェクト全体の計画・費用・切り替え手順を発注者視点で解説しています。
• クラウドとは・AWSとは：移行先となるクラウドの仕組み・料金・移行判断を事業者向けに整理した上位概念の記事です。
• クラウドストレージとは：移行先の器となるオブジェクトストレージ・ファイルストレージの種類と使い分けを実装目線で解説しています。
• プライベートクラウド移行：移行先が専有基盤の場合の方式選定と手順を扱う隣接記事です。
• システムマイグレーション・リプレイス：既存システムの調査からデータ移送・切り替えまでを一括で相談できます。