データ移行の費用と進め方ガイド｜旧システムから新システムへの安全な移行手順

経済産業省の「DXレポート」によると、日本企業の約8割がレガシーシステムを抱えており、その多くでデータ移行が喫緊の課題となっている。しかし、データ移行は「やってみたら想定外のトラブルが続出した」というケースが後を絶たない。本記事では、Access・Excel・オンプレミスDBからクラウドへのデータ移行について、費用相場・具体的な進め方・リスク対策を体系的に解説する。

目次

1. データ移行が必要になる5つのタイミング
2. データ移行の全体プロセス
3. 移行元別の注意点と手順
4. データ規模別の費用相場
5. データクレンジングの実務
6. 並行運用と切り替え戦略
7. よくある質問

データ移行が必要になる5つのタイミング

データ移行が必要になる典型的なタイミングは以下の5つである。

1. 基幹システムのリプレイス: ERPの入れ替え、自社開発システムの刷新
2. クラウド移行: オンプレミスサーバーからAWS・Azure・GCPへの移行
3. M&A・事業統合: 複数企業のシステム統合
4. SaaS導入: Excel・Accessからkintone・Salesforce等への切り替え
5. 法制度対応: インボイス制度、電子帳簿保存法への対応に伴うシステム変更

いずれのケースでも、データ移行はシステム導入プロジェクト全体の中で最もリスクが高い工程の一つであり、十分な計画と検証が不可欠である。

データ移行の全体プロセス

ステップ1: 移行対象データの棚卸し（2〜4週間）

まず現行システムに格納されているデータの全体像を把握する。テーブル一覧、データ項目、データ量、データの鮮度（最終更新日）、利用頻度を調査する。この段階で「移行するデータ」と「移行しないデータ（アーカイブまたは廃棄）」を仕分けることが重要である。

ステップ2: マッピング設計（2〜4週間）

旧システムのデータ項目と新システムのデータ項目の対応関係（マッピング）を定義する。データ型の変換ルール、コード値の変換テーブル、結合・分割のルールも合わせて設計する。

ステップ3: データクレンジング（2〜8週間）

移行前にデータの品質を改善する工程である。重複データの統合、欠損値の補完、表記ゆれの統一、不正データの修正などを行う。この工程が最も工数がかかり、全体の30〜40%の期間を占めることも珍しくない。

ステップ4: 移行ツール開発・設定（2〜4週間）

ETL（Extract・Transform・Load）ツールの設定、またはカスタム移行プログラムの開発を行う。大量データの場合はバッチ処理の設計、差分移行の仕組みも構築する。

ステップ5: テスト移行（2〜4週間）

本番データの一部または全量を使ってリハーサルを行う。移行後のデータ件数照合、サンプルデータの目視確認、新システムでの業務テストを実施する。最低2回、できれば3回のリハーサルを推奨する。

ステップ6: 本番移行と検証（1〜2週間）

本番移行は休日・連休を利用して実施するケースが多い。移行後のデータ検証、ロールバック手順の確認、ユーザーによる最終確認を経て切り替え完了となる。

移行元別の注意点と手順

Excelからの移行

Excelファイルからの移行は、一見シンプルに見えるが以下の落とし穴がある。

• 表記ゆれ: 同一データが異なる表記で入力されている（例：「（株）」と「株式会社」）
• データ型の不統一: 同じ列に文字列と数値が混在
• 非正規化データ: 1セルに複数の値がカンマ区切りで格納
• マクロ依存の計算結果: VBAの計算結果が値として残っているが再現不能
• 複数ファイルの分散: 担当者ごとに別ファイルでデータが管理されている

Accessからの移行

Access（.mdb/.accdb）からの移行では、以下の点に注意が必要である。

• テーブルリレーション: 参照整合性の設定がDBレベルで定義されている場合と、VBAコードで制御されている場合がある
• クエリとレポート: データだけでなく、業務で使用しているクエリやレポートの再現も必要
• マクロ・VBA: Access特有のマクロやVBAコードは新システムで再実装が必要
• 同時接続制限: Accessは同時接続10〜15ユーザーが限界であり、これが移行のきっかけになることが多い

オンプレミスDBからクラウドDBへの移行

Oracle・SQL Server・PostgreSQLなどのオンプレミスDBからクラウドDBへの移行では、以下が重要になる。

• 文字コード: Shift_JIS→UTF-8変換時の文字化け対策
• ストアドプロシージャ: DB依存のロジックの再実装
• パフォーマンス: ネットワークレイテンシの考慮
• ライセンス: BYOL（Bring Your Own License）の可否確認

データ規模別の費用相場

費用の構成要素

データ移行の費用は以下の要素で構成される。

費用項目	割合目安	内容
データ棚卸し・分析	10〜15%	現行データの調査・分析
マッピング設計	15〜20%	項目対応表、変換ルール設計
データクレンジング	20〜30%	データ品質改善
移行ツール開発	15〜25%	ETLツール設定・カスタム開発
テスト移行	15〜20%	リハーサル実施・検証
本番移行・切り替え	5〜10%	本番データ移行・最終検証

規模別費用一覧

データ規模	レコード数目安	期間	費用目安	適用例
小規模	〜10万件	1〜2ヶ月	50万〜200万円	Excel→SaaS、部門DB移行
中規模	10万〜100万件	2〜4ヶ月	200万〜800万円	Access→クラウドDB、部門システム統合
大規模	100万〜1,000万件	4〜8ヶ月	800万〜3,000万円	基幹システムリプレイス、ERP移行
超大規模	1,000万件超	6〜12ヶ月	3,000万円〜	グループ企業統合、大規模DB統合

上記はデータ移行単体の費用であり、新システムの開発費用は含まない。また、テーブル数やデータ間の関連の複雑さにより、同じレコード数でも費用が2〜3倍変動することがある。

データクレンジングの実務

クレンジング対象の4大カテゴリ

1. 重複データの統合

顧客マスタの重複は最も頻出する問題である。名寄せ処理では、会社名・住所・電話番号・メールアドレスなどの複数項目を組み合わせて同一性を判定する。完全一致だけでなく、あいまい一致（レーベンシュタイン距離やN-gram類似度）も活用すべきである。

2. 欠損値の補完

必須項目が空欄のレコードについて、補完可能なものは補完し、補完不可能なものは移行対象から除外するか、デフォルト値を設定する。補完方法は業務ルールに基づいて判断する。

3. 表記ゆれの統一

住所の表記（「1-2-3」と「一丁目二番三号」）、法人格の表記（「（株）」と「株式会社」）、半角・全角の統一など、データの正規化を行う。

4. 不正データの修正

書式エラー（メールアドレスのフォーマット不正）、範囲外の値（マイナスの在庫数）、論理矛盾（終了日が開始日より前）などを検出・修正する。

並行運用と切り替え戦略

一括切り替え（ビッグバン方式）

特定の日時を境に旧システムから新システムへ一斉に切り替える方式である。移行期間が短い反面、問題発生時の影響範囲が大きい。

段階的切り替え（フェーズドアプローチ）

部門や機能ごとに段階的に切り替えていく方式である。リスクを分散できる反面、新旧システム間のデータ同期が必要になり、技術的な複雑さが増す。

並行運用

一定期間、新旧両システムを同時に稼働させ、新システムの動作に問題がないことを確認してから旧システムを停止する方式である。最も安全だが、二重入力の負荷がかかるため、並行運用期間は2〜4週間が適切である。

切り替え方式	メリット	デメリット	推奨ケース
一括切り替え	短期間で完了	リスク大	小規模システム
段階的切り替え	リスク分散	期間長期化	大規模・多拠点
並行運用	最も安全	二重運用コスト	基幹システム

よくある質問

Q1. データ移行にかかる期間はどれくらいか？

データ移行の期間はデータの規模と複雑さにより大きく異なるが、一般的には小規模（10万件未満）で1〜2ヶ月、中規模（10万〜100万件）で2〜4ヶ月、大規模（100万件以上）で4〜12ヶ月が目安である。ただし、データクレンジングの工数が全体の30〜40%を占めるため、データの品質が低いほど期間は延びる。

Q2. 移行中にデータが消失するリスクはどう防ぐか？

本番移行前に必ずフルバックアップを取得する。また、ロールバック手順書を事前に作成し、リハーサルで検証しておく。移行後は件数照合（旧システムの件数と新システムの件数の一致確認）とサンプルデータの目視確認を行い、不整合があればロールバックする判断基準を事前に定めておくことが重要である。

Q3. データ移行を自社で実施することは可能か？

小規模かつ単純な移行（例：Excel→スプレッドシート、CSV一括インポート）であれば自社でも実施可能である。しかし、データクレンジングが必要な場合、異なるDB間の移行、業務を止められない場合などは、専門業者への依頼を推奨する。自社実施する場合でも、移行計画書の作成と最低2回のリハーサルは必須である。

Q4. データ移行後、旧システムのデータはいつまで保管すべきか？

法令で定められた保管期間がある場合はそれに従う（例：会計データは7年、雇用保険関係は4年）。法令上の義務がない場合でも、移行後最低1年間は旧データを参照可能な状態で保管しておくことを推奨する。旧システムの保守契約が終了する場合は、データをCSV等の汎用フォーマットでエクスポートしておくとよい。

Q5. クラウドへのデータ移行で、ネットワーク速度がボトルネックにならないか？

大規模データの移行では、インターネット経由のアップロードに数日〜数週間かかる場合がある。AWSであればAWS Snowball（物理デバイスでのデータ搬送）、AzureであればAzure Data Box、GCPであればTransfer Applianceなど、物理搬送サービスの利用を検討すべきである。100TB以上のデータ移行では、物理搬送が最もコスト効率が高い選択肢となる。

<!-- GXO_QUALITY_REWRITE_20260507_START -->

GXO実務追記: レガシー刷新で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、現行調査、刷新範囲、段階移行、ROI、ベンダー切替リスクを決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

論点	確認する内容	未整理のまま進めた場合のリスク
目的	売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか	成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲	対象部署、対象業務、対象データ、対象システムをどこまで含めるか	見積もりが膨らむ、または重要な連携が後から漏れる
体制	自社責任者、現場担当、ベンダー、保守運用者をどう置くか	要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

フェーズ	期間目安	主な成果物	GXOが見るポイント
事前診断	1〜2週間	課題整理、現行確認、投資判断メモ	目的と範囲が商談前に整理されているか
要件定義 / 設計	3〜6週間	要件一覧、RFP、概算見積、ロードマップ	見積比較できる粒度になっているか
PoC / MVP	1〜3ヶ月	検証環境、効果測定、リスク評価	本番化判断に必要な数値が取れるか
本番導入	3〜6ヶ月	本番環境、運用設計、教育、改善計画	導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

• 現行システムの機能、利用部署、データ、外部連携を一覧化したか
• 保守切れ、属人化、障害頻度、セキュリティリスクを金額換算したか
• 全面刷新、段階移行、SaaS置換、リホストの比較表を作ったか
• 移行中に止められない業務と、止めてもよい業務を分けたか
• 既存ベンダー依存から抜けるためのドキュメント/コード引継ぎ条件を決めたか
• 稟議で説明する投資回収、リスク低減、保守費削減の根拠を整理したか

参考にすべき一次情報・公的情報

• 経済産業省 DX政策
• IPA デジタルスキル標準・DX関連情報
• デジタル庁 標準ガイドライン群
• NIST Cybersecurity Framework

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

• 見積もり依頼前に、要件やRFPの粒度を整えたい
• 既存ベンダーの提案が妥当か第三者視点で確認したい
• 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
• 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
• PoCや診断で終わらせず、本番導入と運用改善まで進めたい

データ移行の費用と進め方ガイド｜旧システムから新システムへの安全な移行手順を自社条件で診断したい方へ

GXOが、現状整理、RFP/要件定義、費用対効果、ベンダー比較、導入ロードマップまで実務目線で確認します。記事の一般論を、自社の投資判断に使える形へ落とし込みます。

レガシー刷新ROI診断を相談する

※ 初回相談では営業資料の説明よりも、現状・課題・判断材料の整理を優先します。

<!-- GXO_QUALITY_REWRITE_20260507_END -->