システムの老朽化や業務拡大に伴い、既存のシステムをリプレースする際に必ず直面するのが「データ移行」です。しかし、「今使っているデータはそのまま新しいシステムで使えるのか」「いくらかかるのか」「どれだけ時間がかかるのか」——こうした疑問に対して、明確な答えを持っている発注者は多くありません。
データ移行は、開発会社が担う技術作業であると同時に、発注者が積極的に関与しなければ費用の肥大化やトラブルに繋がりやすい工程でもあります。「開発会社に丸投げしていたら、カットオーバー直前に想定外のデータ不整合が発覚した」「移行費用が見積にそもそも含まれていなかった」——そうした後悔は、事前の理解と確認で防げるものです。
本記事では、データ移行の基礎知識から移行方式の種類・リスク・費用・期間の目安まで、発注者として知っておくべき内容を整理します。開発会社と対等に議論し、プロジェクトを主体的に進めるための知識として活用してください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
データ移行とは――システム刷新で「今のデータ」に何が起きるのか
データ移行とは、旧システムに蓄積されたデータを新しいシステムへ移す作業のことです。単純にファイルをコピーするようなイメージを持たれることがありますが、実態はそれより複雑です。
なぜデータをそのまま移せないのか
旧システムと新システムでは、データの格納形式・テーブル構造・文字コードが異なるケースがほとんどです。たとえば、旧システムが「顧客コード + 顧客名」を1つのフィールドに格納していたとします。新システムで「コード」と「名前」を別々のフィールドで管理する場合、そのままでは新システムに取り込めません。
このような「旧形式から新形式への変換」を行う処理が、データ移行の核心です。変換ロジックを設計し、変換プログラムを開発し、変換後のデータが正しいかを検証する——この一連の作業に工数がかかります。
データ量が多ければ多いほど、また旧システムのデータ品質が低い（入力ゆれ・空欄・異常値が多い）ほど、移行作業の難易度と工数は上がります。
データ移行と「バックアップ」「データ整備」の違い
混同されやすいですが、以下は別の概念です。
- バックアップ: 障害発生時の復旧を目的に、同じ形式でデータをコピー・保存する作業
- データ整備（クレンジング）: 不要なデータの削除・重複の解消・フォーマットの統一など、移行前に行うデータの「掃除」
- データ移行: 旧システムから新システムへ、データを変換しながら移動させる作業
データ整備は発注者側の責任で行うことが多く、移行前の準備として必要です。この点については後のセクションで詳しく説明します。
データ移行の3つの方式――全件・部分・並行稼働
データ移行の方式は大きく3つに分類されます。どの方式を選ぶかは、開発会社が決めるのではなく、発注者の業務リスクと体制に基づいて意思決定すべき事項です。
一括移行（全件移行）――シンプルだがリスクが集中する
全てのデータを一度に移行し、旧システムを停止して新システムへ一気に切り替える方式です。
項目 | 内容 |
|---|---|
メリット | 移行作業がシンプルで期間が短い。コストを抑えやすい |
デメリット | 移行後にトラブルが発覚した場合、影響範囲が大きい。切り戻しが難しい |
向いているケース | データ量が少ない・業務への影響が限定的・テスト体制が十分に確保できる場合 |
一括移行を選ぶ場合は、移行リハーサル（本番と同等の環境で事前に移行を試す）を必ず実施し、問題を洗い出しておくことが重要です。
段階的移行――リスク分散だが運用が複雑
業務機能やデータの種類ごとに、複数回に分けて移行する方式です。
項目 | 内容 |
|---|---|
メリット | 各段階でリスクを分散できる。問題が発生しても影響範囲が限定される |
デメリット | 移行回数が増えるため工数・コストが上がる。旧新システム並存期間の運用が複雑になる |
向いているケース | データ量が多い・業務への影響が大きい・段階的に新機能を展開したい場合 |
並行稼働――最も安全だがコストと期間が増える
旧システムと新システムを一定期間並行して運用しながら、新システムの動作を検証した上で旧システムを停止する方式です。
項目 | 内容 |
|---|---|
メリット | トラブルが発生しても旧システムで業務継続できる。十分な検証期間を確保できる |
デメリット | 二重に運用するためコストと人員負荷が高い。データ不整合が起きやすい |
向いているケース | 基幹システムなど業務停止リスクが許容できない場合・初めてのシステム刷新 |
どの方式が適切かは「業務が止まったときのリスク」と「コスト・期間」のトレードオフで判断します。開発会社から提案を受けたとしても、最終的な方式の選択は発注者が事業判断として行うものです。
データ移行で起きやすいリスクと発注者が確認すべきポイント
データ移行プロジェクトで発生する問題の多くは、事前の合意不足と確認不足が原因です。以下のリスクを理解した上で、開発会社との契約・仕様確認の段階で対処しておくことが重要です。
データ欠損・変換ミスはなぜ起きるか
移行作業で発生しやすい問題のパターンを整理します。
- データ欠損: 移行対象の定義が曖昧で「移行しなくてよい」と判断されたデータが後で必要になる。または変換プログラムのバグにより一部データが失われる
- 変換ミス: 旧システムと新システムでデータの意味・形式が異なるにもかかわらず、変換ロジックが不完全なまま本番移行される。数値フィールドへの文字データ混入、日付形式の変換ミスなどが典型例
- 文字化け: 旧システムが使用している文字コード（Shift-JIS等）と新システム（UTF-8等）の違いで、日本語テキストが正しく表示されなくなる
- テスト期間の不足: 移行リハーサルを十分に実施しないまま本番移行し、本番環境で初めて問題が発覚する
発注者が開発会社と事前に合意すべき5つの確認事項
- 移行対象データの定義: どのデータを移行し、どのデータは移行しないかを文書で合意する。「過去5年分のデータのみ移行」「削除済みレコードは移行しない」など、境界を明確にする
- 変換ロジックの仕様書確認: 旧フォーマットから新フォーマットへの変換ルールが仕様書として文書化されているかを確認する。「開発会社に任せる」ではなく、変換ルールを発注者も理解・承認した上で進める
- 検証基準（受入基準）の合意: 移行後に何をもって「移行成功」と判断するかを事前に合意する。件数の照合・金額合計の一致・サンプル抽出での目視確認など、具体的な確認観点を定義する
- リハーサル（本番前テスト移行）の実施: 本番移行の前に同等の環境で移行を試し、問題を洗い出す機会を契約・計画に組み込む
- 切り戻し手順の合意: 本番移行後に重大な問題が発覚した場合、旧システムに戻す（切り戻す）手順と判断基準を事前に決めておく。カットオーバーの詳細についてはカットオーバーとは？システム切り替えで発注者が押さえるべきリスクと準備も参照してください
発注者が事前に準備すべきこと
データ移行の品質は、発注者側の準備状況に大きく左右されます。「移行は全部開発会社がやってくれる」という認識のままでは、想定外のコスト増加やトラブルにつながることがあります。
移行対象データの棚卸しとクレンジング
移行前に発注者側が担うべき重要な作業が、移行対象データの「棚卸し」と「クレンジング」です。
棚卸しとは、旧システムに蓄積されているデータの種類・量・形式・品質を把握する作業です。どのデータを移行し、どのデータは移行不要か（古いデータ・テスト用データ・削除済みデータなど）を整理します。
クレンジングとは、移行前にデータの品質を整える作業です。具体的には次のような内容が含まれます。
- 重複レコードの統合・削除
- 不完全データ（必須フィールドが空欄のレコード）の修正または削除方針の決定
- 表記ゆれの統一（「株式会社○○」「（株）○○」など）
- 使用している文字コード・フォーマットの確認
クレンジングを発注者側で事前に行うことで、移行費用を大きく削減できます。開発会社がクレンジングを担う場合はその分の工数が費用に上乗せされるため、発注者が対応できる範囲をあらかじめ整理することが重要です。
移行中の業務はどうする？業務継続計画（BCP）の考え方
データ移行の実施中、一時的に旧システムも新システムも利用できない「移行作業時間帯」が発生します。この期間の業務継続をどう担保するかを、事前に計画しておく必要があります。
一般的な対応策は以下のとおりです。
- 夜間・休日への移行スケジュール集中: 業務への影響が最小になる時間帯に移行作業を実施する
- 一時的なマニュアル運用: システムが停止している間は紙や表計算ソフトでの手作業対応を行い、システム復帰後に入力し直す
- 業務部門への事前周知: システム停止の日時と影響範囲を関係部門に周知し、業務調整（処理の前倒し・後回し等）を依頼する
システムの規模が大きいほど移行に伴う業務影響は深刻になります。特に基幹システムの場合、業務継続計画はプロジェクト計画の中で開発会社と明示的に議論すべき事項です。
データ移行の費用と期間の目安
「データ移行にかかる費用と期間がまったく分からない」という発注者は多くいます。ここでは、相場感をつかむための目安を整理します。ただし、費用・期間はデータ量・変換複雑性・移行方式によって大きく異なるため、あくまで参考値として理解してください。
費用の目安――規模別の相場と工数比率
データ移行費の一般的な目安は次のとおりです。
規模・難易度 | 費用の目安 |
|---|---|
小規模（データ量が少ない・変換ロジックが単純） | 10万〜100万円程度 |
中規模（テーブル数が多い・変換ロジックが複雑） | 100万〜500万円程度 |
大規模（データ量が膨大・複数システム間の連携移行） | 500万〜1,000万円以上 |
注目すべきは、データ移行費がシステム開発費全体に占める割合です。「データ移行費はシステム構築費全体の20%になる」と指摘する声もあり（出典: 日経クロステック「システム開発費の内訳は？」）、見積書の中で意外と大きな比重を占めます。
発注者が確認すべき重要な点: データ移行費が見積書に含まれていないケースがあります。「データ移行費用（見積範囲外）」と記載された見積書も実際に存在します。必ず見積書の内訳を確認し、データ移行作業がどの項目に含まれているかを明示してもらいましょう。
期間の目安――移行に必要な4つのフェーズ
データ移行作業は、以下の4つのフェーズに分けて考えます。
フェーズ | 内容 | 期間の目安 |
|---|---|---|
1. 調査・設計 | 移行対象の確定・変換ロジックの設計・移行仕様書の作成 | 2〜4週間 |
2. 開発・テスト（単体） | 変換プログラムの開発・単体テスト | 2〜6週間 |
3. リハーサル（結合テスト） | 本番同等環境での移行テスト・問題修正 | 1〜4週間（複数回実施が望ましい） |
4. 本番移行・安定化 | 本番移行の実施・動作確認・問題対応 | 移行当日〜2週間 |
合計では小規模で1〜2ヶ月、中〜大規模では3〜6ヶ月以上かかることも珍しくありません。
また、並行稼働を選択した場合はフェーズ4が長くなり、旧システムを停止するまでの期間（一般的に1〜3ヶ月程度）が追加されます。プロジェクト全体のスケジュールにデータ移行期間を十分に織り込んだ上で計画を立てることが重要です。
まとめ――データ移行で「後悔しない発注者」になるために
本記事で解説した内容を振り返ります。
- データ移行は技術作業だが、発注者の関与が必要: 移行対象の定義・変換ロジックの承認・受入基準の合意は発注者が担うべき役割です
- 移行方式（一括・段階・並行稼働）は発注者が意思決定する: 業務リスクとコストのトレードオフを理解した上で、事業判断として選択します
- 費用は見積書に必ず含まれているかを確認する: データ移行費が「別途見積」になっていないかを確認し、不明な場合は開発会社に内訳を求めましょう
- 発注者側の準備（データ棚卸し・クレンジング）が品質と費用を左右する: 事前にデータを整理しておくことで、移行費用を削減しトラブルを防げます
「開発会社に任せておけばよい」という受け身の姿勢から、「確認すべきことを確認し、準備すべきことを準備する」主体的な姿勢へ。その変化がシステム刷新プロジェクトの成否を大きく左右します。
データ移行と並んで重要なのが、カットオーバー（システム切り替えの本番作業）と、その後のシステム引き継ぎです。それぞれの詳細は以下の記事を参照してください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
