この記事でわかること
- データ移行の全体像と進め方（5ステップ）
- データ移行で起きやすいトラブルと防止策
- 移行方式の種類と選び方（一括移行 vs 段階移行）
- データクレンジング（整理・クリーニング）のポイント
- データ移行の費用目安とスケジュール感
データ移行はなぜ難しいのか
新しいシステムを導入する際、旧システムのデータを移行する作業はプロジェクト全体の中でも特にリスクが高い工程です。
データ移行が難しい理由は以下の通りです。
- 旧システムと新システムでデータ構造が異なる
- 旧データに不整合や重複が含まれている
- 移行対象のデータ量が想定以上に多い
- 業務を止めずに移行する必要がある場合がある
- 移行後に「データが消えた」「数字が合わない」が発覚すると業務が止まる
しかし、正しい手順と十分なテストを行えば、データ移行の失敗リスクは大幅に減らせます。
データ移行の進め方（5ステップ）
Step 1：移行対象データの棚卸し
まず、旧システムにどのようなデータがあるかを洗い出します。
| 確認項目 | 具体例 |
|---|---|
| データの種類 | 顧客マスタ、商品マスタ、取引履歴、ファイル・画像 |
| データ量 | レコード数、ファイルの総容量 |
| データの品質 | 重複の有無、欠損値、フォーマットの統一度 |
| 移行の優先度 | 必須（顧客情報）/ あれば便利（過去3年以上前の履歴）/ 不要（一時データ） |
この段階で「すべてのデータを移行する必要があるか」を検討しましょう。古いデータや使われていないマスタは、移行せずにアーカイブする方が効率的な場合があります。
Step 2：移行設計
旧システムのデータを新システムのデータ構造にどう対応させるか（マッピング）を設計します。
- フィールドの対応表を作成（旧：「お客様名」→ 新：「company_name」）
- 変換ルールを定義（旧：「東京都」→ 新：都道府県コード「13」）
- 欠損値の扱いを決める（NULLにする？デフォルト値を入れる？）
- コード体系の変換（旧システムの商品コードと新システムの商品コードの対応）
Step 3：データクレンジング
旧データを移行前に「きれいにする」工程です。この工程を省くと、新システムに汚いデータが入り、運用に支障が出ます。
| クレンジング項目 | 具体的な作業 |
|---|---|
| 重複の排除 | 同じ顧客が複数登録されている → 名寄せして統合 |
| フォーマットの統一 | 電話番号が「03-1234-5678」「0312345678」「03（1234）5678」→ 統一 |
| 欠損値の補完 | 住所が途中で切れている → 補完または削除 |
| 不要データの削除 | 退会済み顧客、テストデータ、一時ファイルの除去 |
| 文字コードの統一 | Shift_JIS・EUC-JP → UTF-8に統一 |
Step 4：テスト移行（リハーサル）
本番移行の前に、最低2回はテスト移行を実施します。
- 1回目 — 移行プログラムの動作確認、エラーの洗い出し
- 2回目 — 1回目のエラーを修正した上での再テスト、所要時間の計測
- テスト移行後にデータの件数・金額の突合を行い、旧システムと一致することを確認
テスト移行はテスト工程の一部として計画に組み込みましょう。
Step 5：本番移行
テスト移行で問題がないことを確認した上で、本番移行を実施します。
- 移行日時を事前に決定（業務影響が少ない休日・夜間が理想）
- 切り戻し計画を準備（移行に失敗した場合に旧システムに戻す手順）
- 移行後の検証チェックリストを用意
- 移行後一定期間は旧システムも並行稼働させると安心
データ移行で最も重要なのは「テスト移行」です。本番一発勝負で移行するのは非常にリスクが高いです。テスト移行を2〜3回実施し、移行にかかる時間、発生するエラー、データの整合性をすべて検証してから本番に臨んでください。テスト移行の時間を確保するためにも、プロジェクトの早い段階から移行計画を立てることをおすすめします。
移行方式の比較
| 方式 | 概要 | メリット | デメリット | 向いているケース |
|---|---|---|---|---|
| 一括移行（ビッグバン） | ある時点で旧→新に完全切替 | シンプル、期間が短い | 失敗時のリスクが大きい | データ量が少ない、業務停止が許容できる |
| 段階移行 | 部門・機能ごとに段階的に切替 | リスクが分散される | 期間が長い、両システムの並行運用が必要 | 大規模システム、業務停止が許容できない |
| 並行稼働 | 一定期間、旧新両方を運用 | 問題があれば旧に戻せる | 二重入力の負担、コストが高い | ミッションクリティカルなシステム |
中小企業の場合は、一括移行＋短期間の並行稼働（1〜2週間）が現実的な選択肢です。
データ移行の費用目安
| 規模 | データ量の目安 | 費用目安 | 期間 |
|---|---|---|---|
| 小規模 | 数千〜数万レコード、CSVベース | 20万〜50万円 | 1〜2週間 |
| 中規模 | 数万〜数十万レコード、複数テーブル | 50万〜150万円 | 2〜4週間 |
| 大規模 | 数百万レコード以上、複雑な変換ルール | 150万〜500万円 | 1〜3ヶ月 |
データ移行費用はシステム開発費用の10〜20%程度が目安です。詳しい費用はシステム開発の費用相場まとめを参考にしてください。
レガシーシステムからのデータ移行はレガシーシステムの刷新ガイドで、他社システムからの移行はシステム引き継ぎガイドで詳しく解説しています。
データ移行チェックリスト：失敗しないための確認項目
データ移行プロジェクトで見落としがちな確認項目をチェックリスト形式でまとめました。
移行前の準備チェック
| チェック項目 | 確認内容 |
|---|---|
| 移行対象データの範囲を確定したか | マスタデータ・トランザクションデータ別に移行範囲を文書化 |
| データクレンジングの方針を決めたか | 重複・不整合・欠損データの処理ルールを策定 |
| コード体系のマッピングを完了したか | 旧→新のコード変換テーブルを作成し関係者でレビュー |
| 文字コード・日付形式の差異を確認したか | Shift_JIS→UTF-8変換、日付フォーマットの統一ルールを設定 |
| 移行ツール・スクリプトの選定を完了したか | ETLツールまたは個別スクリプトの開発方針を確定 |
移行実行時のチェック
| チェック項目 | 確認内容 |
|---|---|
| リハーサルを2回以上実施したか | 本番相当のデータ量でリハーサルし、所要時間を計測 |
| 件数の突合確認を行ったか | 移行元と移行先のレコード件数が全テーブルで一致 |
| 金額・数量の合計値を検証したか | 売上合計、在庫数量など主要な集計値のクロスチェック |
| 外部キー・リレーションの整合性を確認したか | 参照先が存在しない孤立レコードがないことを検証 |
| 切り戻し手順を準備・テストしたか | 移行失敗時に元の状態に復元する手順と所要時間を確認 |
業務システム全体の移行プロジェクト管理については、業務システム移行の注意点10選でフェーズ別のチェックリストを提供しています。データ移行はシステム移行プロジェクト全体の中でも特に工数がかかる工程のため、十分なリハーサル期間を確保してください。
まとめ
- データ移行は5ステップ（棚卸し→設計→クレンジング→テスト→本番）で進める
- テスト移行は最低2回実施し、件数と金額の突合で整合性を検証
- データクレンジングを省くと新システムに問題が持ち込まれる
- 中小企業は一括移行＋短期並行稼働が現実的
- 費用は開発費全体の10〜20%が目安
- 切り戻し計画を必ず準備する
「データ移行の進め方がわからない」「旧システムのデータが整理されていない」という方は、お問い合わせからお気軽にご相談ください。FUNBREWでは、クラウド移行を含むデータ移行の設計・実行をサポートしています。
よくある質問
データ移行にはどのくらいの時間がかかりますか？
データ規模・移行方式・テスト期間によって大きく異なります。数百万件規模のDBであれば移行処理自体は数時間〜数十時間、前後の準備・テスト期間を含めると1〜3ヶ月が一般的な目安です。週末や深夜など業務停止時間帯に実施するケースが多いため、スケジュール設計が重要です。
データ移行中に業務を止める必要がありますか？
完全停止（カットオーバー方式）と並行稼働（段階的移行）の2つのアプローチがあります。業務影響を最小化するには並行稼働が理想ですが、コストが高くなります。中小企業では週末の短時間停止によるカットオーバー方式が現実的なケースが多いです。切り戻し計画を事前に用意することが必須です。
データ移行で文字化けが発生するのを防ぐには？
文字コードの不一致（Shift-JIS vs UTF-8）が主な原因です。移行前に旧システムと新システムの文字コードを確認し、変換処理を明示的に行うことで防げます。特に古い基幹システムではShift-JIS（CP932）が使われていることが多いため、テスト環境でのサンプル移行を必ず実施してください。
データ移行後にデータ欠損を検知する方法は？
移行前後でレコード件数・合計金額・チェックサムなどを比較する「データ整合性チェック」が基本です。重要テーブルは移行前にカウント・サンプリングを行い、移行後に同じチェックを再実行して一致を確認します。差異があれば差分データを再移行するか、手動修正で対応します。
CSV移行とAPI移行の違いは何ですか？
CSV移行はデータをファイルに書き出して一括取り込みする方式で、シンプルで安価ですが大量データの処理に時間がかかります。API移行は新旧システム間をAPIで連携して都度同期する方式で、リアルタイム性が高く並行稼働向きですが実装コストが高めです。データ量・移行期間・予算を考慮して選択します。
データ移行の費用相場はいくらですか？
データ移行の費用は、規模・複雑さ・移行方式によって大きく異なります。中小企業の基幹システム移行であれば50万〜200万円、大規模システムでは300万〜1,000万円以上になることもあります。移行前の設計・テスト工数が全体の6〜7割を占めるため、「移行処理だけ」の安易な見積もりには注意が必要です。
データ移行に失敗したらどうなりますか？
最悪の場合、業務停止・データ損失・顧客対応遅延が発生します。これを防ぐために、切り戻し計画（ロールバック手順）を事前に策定し、移行前の旧システムデータバックアップを必ず取得することが必須です。また、段階的移行（一部部門から先行）で影響範囲を限定するのも有効な手段です。
データ移行を依頼する会社はどう選べばいいですか？
選定ポイントは4つです。①移行実績（同業種・同規模の事例があるか）、②移行計画の詳細度（切り戻し手順・テスト計画が明示されているか）、③データ保護の方針（移行データの暗号化・アクセス制御）、④保証内容（移行後の不具合対応はいつまで保証されるか）。料金の安さだけで選ぶのは非常にリスクが高いです。
この記事をシェア