古い業務システムを新しくするとき、見積書の「開発費」「サーバー費」の欄は気にしても、「今までのデータをどう持っていくか」まで確認できている方は多くありません。いざ進み始めてから「データ移行は別途です」と言われ、予算が足りなくなる。そんな不安を抱えるのは自然なことです。
「システムの入れ替えで、古いデータの移行費用が見積もりに入っているか分からない。後から追加になるのか」
先に結論をお伝えします。データ移行の費用が見積もりに入っているかは、書面で確認しないと分かりません。そして「入っている」場合でも、どのデータをどこまで移すのかによって、後から追加になる余地が残ります。 追加を防ぐ鍵は、金額の大小ではなく「移行の範囲」を見積もりの段階で文章にしてもらうことです（執筆時点：2026年11月）。
この記事では、システム入れ替えのデータ移行（＝古いシステムに入っているデータを、新しいシステムで使える形にして移すこと）の費用を、見積もりでどう確認すればよいかを、チェックリストと質問例つきで解説します。
データ移行が「見積もりの盲点」になりやすい理由
理由1：データ移行は、問題が起きやすい工程だといわれている
経済産業省のレガシーシステムモダン化委員会の総括レポート（2025年5月）には、システムの移行やモダン化で一般的に問題が発生しやすいのはデータ移行であり、対象となるデータの質と量、管理の精度によって難易度が大きく変わる、という趣旨の記述があります。
📰 出典：経済産業省「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（2025年5月28日）
同じレポートでは、モダン化（＝古いシステムを今の技術や業務に合わせて新しくすること）を進める上での障壁として、「既存システムが複雑でモダン化が技術的に困難（データ移行やシステムの相互依存性の課題など）」を挙げた回答が31%（n=59）ありました。データ移行は、多くの企業がつまずきうる部分です。
理由2：データの状態は、開いてみるまで分からない
開発会社の側から見ると、古いシステムのデータは「中を見ないと作業量が読めない」ものです。同じ「顧客データ10万件」でも、きれいに入力されているものと、表記のゆれや重複、入力漏れが多いものでは、整える手間がまったく違います。
そのため、見積もりの時点では「データ移行一式」と大まかに書かれ、詳しい調査をしてから確定する、という進め方になることがよくあります。これは悪意ではなく、実際に見ないと分からないという事情によるものです。ただし、発注者の側からは「どこまでが含まれるのか」が見えにくくなります。
理由3：データ移行の作業は、複数の種類に分かれている
「データ移行」という一言には、実は複数の作業が含まれます。見積もりに入っているのがどれなのかを、分けて確認する必要があります。
| 作業 | 中身 |
|---|---|
| 現状の調査 | どこにどんなデータがあるか、形式や量を調べる |
| 移行の設計 | 古いシステムの項目を、新しいシステムのどの項目に対応させるかを決める（マッピング） |
| データの整理・変換 | 重複や表記のゆれを直し、新しい形式に変換する |
| 移行プログラムの作成 | データを自動で移すための仕組みを作る |
| リハーサル | 本番の前に試しに移し、結果を確かめる |
| 本番の移行と確認 | 実際に移し、件数や内容が合っているかを確かめる |
| 古いデータの保管・廃棄 | 移さないデータをどう扱うか |
この表のうち、見積書に具体的に書かれているのが1〜2行だけ、ということも珍しくありません。残りが「含まれる」のか「別途」なのか、確かめておくのが最初の一歩です。
後から費用が追加になりやすい4つのパターン
追加費用が出る理由は、おおむね次のように整理できます。誰かが悪いというより、前提がそろっていなかった結果として起きることがほとんどです。
パターン1：移行するデータの範囲が決まっていない
「全部のデータを移す」前提でいたのに、見積もりでは「直近3年分」だった、という食い違いです。過去の履歴を何年分、どの項目まで移すのかが書かれているかを確認します。
パターン2：データの質が想定より悪かった
調査してみたら、重複や入力のゆれが多く、整える作業が想定より増えた、というパターンです。見積もりの前提に「データの状態は良好とする」と書かれていないか、整える作業を誰が担うのかを確認します。発注者の側で整理する部分（例：不要なデータの削除、取引先名の統一）を引き受けることで、費用を抑えられることもあります。
パターン3：リハーサルの回数が足りなかった
本番前のリハーサルで不具合が見つかり、回数が増えるパターンです。リハーサルが何回分含まれているか、追加になる場合の条件は何かを聞いておきます。
パターン4：古いシステムの仕様が分からない
古いシステムの仕様書が残っていないと、データの意味を読み解くところから始めることになります。調査に時間がかかり、費用が増える要因になります。仕様の資料が無い場合は、入れ替えの前に整理する作業が必要になることを、あらかじめ覚悟しておくと安心です。
見積もり段階でできる、追加を防ぐ進め方
ステップ1：移行する・しないデータを一覧にする
最初に、発注者の側で「移すもの」「移さないもの」「迷うもの」に分けます。精密でなくて構いません。顧客、取引、在庫、帳票といった大きな単位で十分です。保存期間が法令で決まっているデータ（会計や税務の書類など）は、専門家や公式窓口で確認してください。
ステップ2：データの現物を、開発会社に見てもらう
見積もりの前に、サンプルのデータを開発会社に渡し（個人情報などは取り扱いの取り決めをしたうえで）、状態を見てもらいます。これだけで「データの質が想定より悪かった」リスクをかなり減らせます。
ステップ3：見積書に「範囲」と「前提」を書いてもらう
次の4点が、見積書や提案書に文章で書かれているかを確認します。
- 移行するデータの範囲（対象、期間、項目）
- 前提（データの状態、件数の目安）
- 含まれる作業（調査、変換、リハーサルの回数、本番の確認）
- 追加になる条件と、その場合の進め方（事前に相談があるか）
ステップ4：「調査してから確定する」場合は、確定の時期を決める
詳しい調査のあとに金額を確定する進め方もあります。その場合は、いつまでに確定するか、確定した金額が上限なのか、想定を超えたときに事前相談があるかを決めておきます。調査だけを先に小さな契約として出す方法もあります。
ステップ5：移行の確認を、誰がどう行うかを決める
移したあとに「合っている」と確かめるのは、実際に業務を行う現場の担当者です。件数の突き合わせと、実際の画面での確認の分担を、開発会社と決めておきます。確認の時間を現場が取れないと、日程の遅れから費用にも影響します。
やりがちな失敗
- 「データ移行一式」の中身を確認せずに契約してしまう
- 移行するデータの範囲を、口頭の説明だけで済ませる
- データの整理は開発会社がやってくれるものと思い込む
- 現場の確認時間を確保できず、本番直前に慌てる
- 古いシステムの保守契約が切れる時期と、移行の日程が合っていない
最後の点は見落とされがちです。古いシステムから最新のデータを取り出す作業が必要なときに、保守が終わっていると対応が難しくなることがあります。契約の期限は両方の契約書で確認してください。
発注者がやること チェックリスト
- ☐ 移すデータ・移さないデータを大きな単位で一覧にした
- ☐ 移行の作業内容（調査・変換・リハーサル・本番確認）の、どれが見積もりに入っているか確認した
- ☐ 移行の範囲（対象、期間、項目）が書面に書かれている
- ☐ 見積もりの前提（データの状態・件数）が書かれている
- ☐ リハーサルの回数と、追加になる条件が分かっている
- ☐ 現場でデータの確認を行う担当者と時間を決めた
- ☐ 古いシステムの保守契約の期限と、移行日程を照らし合わせた
- ☐ 保存期間が決まっているデータは、専門家や公式窓口に確認した
開発会社への質問例
打ち合わせでそのまま使える一文です。
- 「見積もりの『データ移行』には、調査・変換・リハーサル・本番の確認のうち、どこまでが含まれていますか」
- 「移行するデータの範囲は、対象・期間・項目で、どのように想定されていますか。書面に残していただけますか」
- 「データの状態が想定と違った場合、費用はどう扱われますか。追加になる前に相談をいただけますか」
- 「リハーサルは何回分含まれていますか。追加になる場合の条件を教えてください」
- 「データの整理で、私たちの側で先に進めておくと費用を抑えられる作業はありますか」
まとめ
- データ移行は問題が起きやすい工程で、費用も見積もりの段階では読みにくい
- 「一式」の中身を、作業の種類ごとに確認する
- 範囲と前提を書面にしてもらうことが、追加費用を防ぐいちばんの手段
- 発注者の側でできる準備（データの一覧、整理、確認の体制）が、費用と日程の両方に効く
後から追加になるかどうかは、契約や案件ごとの内容で変わります。個別の契約の判断は、弁護士など専門家に確認してください。最初の打ち合わせで5つの質問を使うだけでも、見積もりの中身がずっと見えやすくなります。
あわせて読みたい関連記事
