システム開発のデータ移行費用の内訳｜件数・変換ルール・欠損・リハーサルで分解する

システム開発の見積書に「データ移行費　一式　◯◯円」と書かれている。あるいは「移行データ 50万件 × 単価」と、件数で計算されている。金額の大きさは分かるけれど、それが何の作業に対する対価なのか、件数が増えたら本当にその分だけ増えるのかは、見積書からは読み取れない——この記事は、その状態から一歩進むための手順書です。

先に立場を書いておきます。「件数で課金するのは間違いだ」とは書きません。 件数が費用の実態とよく対応する場面は実在します。ただし対応するのは「レコードが何行あるか」そのものではなく、その件数が引き起こす特定の作業です。判定の分かれ目は、件数が効く作業が見積書のどの行にあるかを特定できるかの一点にあります。特定できるなら、件数課金には説明がつきます。効く場所と効かない場所の切り分けは、記事の中ほどで行います。

以降では、移行費を6つの作業へ分解し、それぞれについて「件数が効くのか、効かないのか」を見積書と一次資料の両方から確認していきます。

TL;DR｜データ移行費は「件数」ではなく、件数が効く場所を特定して読む

• 「データ移行　一式」のままでは、金額の妥当性を検証できません。 移行費は棚卸し・マッピング設計・クレンジング・移行処理・リハーサル・照合という性格の違う6つの作業の合計で、このうち件数が効くのは一部です
• 国も、データ移行費を独立した経費区分として扱っています。 総務省の手順書に掲載されたデジタル庁提供の「経費試算シート」では、イニシャルコストの作業費が6区分に分かれ、そのひとつが「データ移行費」です（税抜き。掲載元は2023年9月29日版の手順書）。移行費を独立行にすること自体は、特別な要求ではありません
• 公的な手順書が挙げるデータクレンジングの検討事項6つには、件数の話が1つも出てきません。 項目の有無、履歴の管理方法、コード値のばらつき、必須データの欠損、必須データの誤り、桁数の差異——すべて「どんなデータか」の話です
• リハーサルは複数回が前提として書かれています。 同じ手順書は、最終データ移行について「それまでに複数回同じ手順でリハーサルを実施している前提であるが」と記載しています。リハーサル0回の見積もりは、安いのではなく、その工程が誰かの負担として残っています
• 件数が効くのは、機械の稼働時間・1件ずつの人手作業・保管と転送の実費の3か所です。 たとえばAWS Database Migration Serviceの課金は「使用したキャパシティについて時間単位」で、件数ではありません。件数は時間を通じて効きます
• 移行費が独立行になっているかどうかは、経理にも影響します。 会計の実務指針は「データをコンバートするための費用」を発生した事業年度の費用としています。一式に溶けていると、その区分の検討自体ができません
• 安い移行見積もりのほうが危険な場合があります。 リハーサル回数、照合の方法、現行ベンダーへ支払うデータ抽出費用のいずれかが抜けていると、金額は下がりますが作業は消えません

判断の材料が揃っていないと感じたら、手元の見積書を開発見積書のAIレビュー（登録不要）にかけて、移行に関する行がどう書かれているかを整理するところから始めてください。

見積書では、データ移行費がどう書かれているか

実際の見積書で、移行に関する行は次のどれかの形で現れます。金額の大小より先に、自分の見積書がどの型かを特定してください。 型によって、次に聞く質問が変わります。

最後の「行が無い」は、安く見えるだけに見落とされます。行が無いことは作業が不要という意味ではなく、発注側の作業になるか、後日の追加費用として現れるかのどちらかです。見積書全体で同じ現象が起きていないかは、見積書の「一式」を工程・成果物・工数へ分解する手順で確認できます。

公的な様式では、データ移行費は独立した経費区分になっている

「移行費だけ分けて出してください」という依頼が特別な要求なのかどうかは、公的な様式を見ると判断できます。

総務省の自治体情報システムの標準化・共通化に係る手順書【第3.0版】（令和5年〈2023年〉9月29日）には、デジタル庁が提供する「経費試算シート」が図表46として掲載されています。このシートは、イニシャルコストの作業費を次の6区分に分けています（いずれも税抜き表記）。

右の列は、手元の見積書と突き合わせるための欄です。空欄が残る区分が、次に聞く場所になります。

このシートは自治体が標準準拠システムへ移行する際に、ガバメントクラウドを使う場合と使わない場合の経費を比較するためのものです。民間企業の金額水準を示すものではありません。それでも、移行費・環境構築費・プロジェクト管理費を別々の行として立てるという区分の考え方は、そのまま民間の見積書にも当てはめられます。移行費を独立行にする依頼は、国の様式が前提としている粒度を求めているだけです。

同じ手順書は、予算要求の場面についてこうも書いています。

特に現行ベンダから、データ移行作業等で追加的費用が発生しないか、現行ベンダとの契約内容を確認する等、必要な経費の積算漏れがないか留意すること。 （前掲手順書 p.94）

つまり、新しく作る側の見積書に移行費が載っていても、それとは別に、現行ベンダーへ支払うデータ抽出の費用が発生することがあるという警告です。これは自治体に限った話ではありません。旧システムの契約に、契約終了時のデータ提供が無償で含まれているかどうかで、総額が変わります。この論点はベンダーロックインと保守費用の関係で詳しく扱っています。

データ移行費を実際に生む6つの作業

移行費は、性格の違う6つの作業の合計です。それぞれ、成果物も、コストが増える理由も違います。「件数が効くか」の列が、この記事の中心です。

1. 移行対象の棚卸し

「全部持っていってください」で始まる移行は、高くつきやすい始まり方です。10年分の受注履歴を全件運ぶのか、直近3年だけ運んで残りは参照専用で残すのかで、以降の5工程すべての規模が変わるためです。

ここで決まるのは件数ではなく、運ぶデータの種類の数です。基幹システム1本の移行と、基幹＋Excel台帳3種＋部門データベース2本の統合では、棚卸しの工数は大きく変わります。件数は同じでも、出どころが増えれば増えます。

2. マッピングと変換ルールの設計

旧システムの「顧客区分：1・2・3」を、新システムの「法人・個人・その他」へどう対応させるか。旧システムが日付を文字列で持っていたなら、どの形式として解釈するか。こうした対応表と変換規則を1本ずつ決めていく作業です。

この工程は、1件でも100万件でも作業量がほとんど変わりません。 決めるのは「ルール」であって「データ」ではないためです。ルールが30本なら30回、120本なら120回、仕様を決めて、実装して、確認します。見積書で「件数」しか変数になっていない場合、この工程が金額のどこに入っているのかを聞く必要があります。

3. データクレンジング

前掲の総務省手順書は、データクレンジング作業について想定される検討事項を、⑭データ移行の項（p.103）で次の6つとして挙げています。

この表を読むときに注目してほしいのは、6項目のどれにも「件数」が出てこないことです。書かれているのは、項目があるかないか、管理方法が違うか、コード値の種類が合っているか、値が欠けているか、値が誤っているか、桁が入りきるか。すべてデータの性質の話です。

なお、手順書は「以下のような検討事項が想定される」という書き方をしており、この6つは例示です。実際の移行では、これ以外の検討事項が出てくることもあります。

この手順書は自治体が標準準拠システムへ移行する場面を対象にしており、「データ要件」は国が定めた標準仕様を指します。民間の移行では、この「データ要件」の位置に新システム側の仕様が入ります。確認すべき事項の性質は変わりません。

同じ項で、この手順書は「これらについては、移行元・移行先のベンダ間において役割分担の調整が必要となる」とも書いています。クレンジングは、新システム側のベンダーだけでは終わらない作業です。見積書のどこに、誰の作業として入っているのかを確認してください。

4. 移行処理の作成と実行

抽出・変換・投入のプログラムを作り、実際に動かす工程です。6つのなかで、件数が最も直接的に効くのがここです。 ただし効き方は「1件いくら」ではありません。

参考になるのが、移行ツールの公開料金体系です。AWSのDatabase Migration Service 料金ページ（2026年8月24日取得）は、課金についてこう記載しています。

DMS 移行オプションでは、レプリケーションインスタンスを使用するかサーバーレスオプションを使用するかにかかわらず、使用したキャパシティについて時間単位でお支払いいただきます。

課金軸は「時間」であって「件数」ではありません。 同ページはさらに「AWS DMS へのデータ転送はすべて無料」とし、同じアベイラビリティーゾーン内のAmazon RDSやAmazon EC2インスタンスのデータベースとAWS DMSとの間の転送も無料としています。ただしこれには続きがあり、「ソースデータベースを、AZ やリージョンの異なるターゲットデータベースや AWS 外のターゲットデータベースに移行する場合は、標準 AWS データ転送料金が適用されます」と明記されています（表示価格は税抜き。日本の請求先には別途消費税）。

ここから読み取れるのは、件数の効き方が2段階だということです。件数は処理時間を伸ばし、処理時間が費用になる。 そして構成によっては、運ぶ経路そのものにも実費がかかる。「1件あたり◯円」という単価が独立して存在しているわけではありません。

処理時間が伸びると、金額とは別の制約も出てきます。移行当日にシステムを止められる時間には上限があります。土日で終わらないなら、差分移行（先に大半を移しておき、当日は変更分だけを移す）や分割移行（対象を分けて複数回に分ける）を設計しなければならず、設計の工数が増えます。 件数が費用に効く経路として、この設計工数は見落とされがちです。

5. リハーサル

本番と同じ手順を、本番前に試す工程です。前掲の総務省手順書（p.104）は、最終データ移行についてこう書いています。

最終データ移行は、それまでに複数回同じ手順でリハーサルを実施している前提であるが、ネットワークの帯域影響等、リハーサル時と異なる要因が原因で作業スケジュールが遅延するリスクがないか、あらかじめ職員と標準準拠システム提供ベンダの作業関係者内で十分にリスク確認と対策の検討を行う。

「複数回同じ手順でリハーサルを実施している前提」という書き方に注意してください。これは推奨ではなく、そこまで済んでいることを当然のこととして次の段階を論じている文章です。あわせて、リハーサルを重ねてもなお本番で条件が変わりうる（ネットワークの帯域影響等）ことにも触れています。

リハーサル回数を決めるのは件数ではありません。決めるのは、移行当日に業務を止められる時間、失敗したときに戻せるか、関係する部署がいくつあるかです。件数が少なくても、止められる時間が2時間しかなければリハーサルは複数回必要になります。

見積書にリハーサルの行が無い、または「1回」となっている場合、それは費用が抑えられているのではなく、本番当日に初めて通しで実行することを意味します。 そのリスクを誰が引き受けるのかが、契約書に書かれているかを確認してください。

6. 照合・検証

運び終えたあと、内容が保たれているかを確認する工程です。同じ手順書は、移行作業完了後の確認観点例（図表64、p.105）として次の4つを挙げています。

確認するのはデータの整合性だけではないという点が重要です。件数が合っていても、処理速度が業務に耐えないなら移行は完了していません。移行後のバックアップが計画どおり取れるかも、移行完了の条件に含まれています。

照合には4つのやり方があります。①件数の突合 ②集計値の突合（金額合計など）③項目内容の全件突合 ④抽出したデータの目視確認です。①〜③は機械が処理するため件数は処理時間として効き、④だけが件数に比例して人の時間を消費します。見積書の照合の行がこの4つのどれを指しているかで、金額の意味が変わります。

「件数課金」は妥当か｜件数が効く3つの場所と、効きにくい4つの場所

ここまでの6工程を、費用を動かす要因という別の軸へ並べ替えます。要因と工程は1対1では対応しないので、各要因に対応する工程番号を添えました。この節が、見積書の「◯万件 × 単価」を読むための本体です。

件数・本数・台数・店舗数など、数量で単価が決まる見積もり全般に共通する判断枠組みは数量課金の見積もりをどう判断するかにまとめています。

件数が実際に効く3つの場所

1つ目は、機械が動く時間です（工程4）。 抽出・変換・投入の処理時間は件数に応じて伸びます。前述のとおり、移行ツールの課金軸自体が時間で設計されている例があります。そして時間が伸びることは、金額よりも先に移行当日の作業計画を制約します。停止できる時間枠に収まらなければ、前掲の差分移行・分割移行という別の設計が必要になります。

2つ目は、1件ずつの人手作業が残っている場合です（工程3・4・6）。 旧システムからデータを機械的に取り出せず、画面から1件ずつ書き出すしかない。紙の申込書をスキャンして入力する。添付ファイルの内容を目視で確認して分類する。こうした作業が残っていれば、1件あたりの単価は正当に成立します。 件数課金を見たら、まず「1件あたり単価が成立する人手作業が、この見積もりのどこにありますか」と聞いてください。答えられるなら、その部分の件数課金は説明済みです。

3つ目は、保管と転送の実費です（どの工程にも属さない実費）。 移行期間中は旧環境と新環境の両方が動くため、保管の実費が二重にかかります。加えて、環境をまたいでデータを運ぶ経路によっては転送の実費が発生します。前述のAWSの料金ページも、同一のアベイラビリティーゾーン（同じ地域内の別拠点）内では無料としつつ、AZ・リージョンをまたぐ場合とAWS外への移行には標準のデータ転送料金が適用されると明記しています。

ただしここだけは、効くのが件数ではなく「データ量」です。 添付ファイルや画像を持つデータは、件数が少なくても容量が大きくなります。見積書に保管・転送の実費が立っている場合は、件数ではなく何ギガバイトを前提にしているかを聞いてください。

件数が効きにくい4つの場所

この3つに加えて、名寄せ（同じ取引先や同じ人物のデータが複数の行に分かれているものを1つにまとめる作業）と重複判定があります（工程3の一部）。 ここは慎重に書きます。重複の候補を洗い出す処理そのものは、件数に対して単純比例より速く増えることがあります。ただし費用として大きいのは、機械が「判定できない」と返したものを人が見る作業で、その量は件数そのものではなく「判定できなかった率 × 件数」です。名寄せの見積もりを見るときは、件数ではなくこの率の見込みと、判定基準を誰が決めるかを聞いてください。

なお、工程1「移行対象の棚卸し」は、件数ではなく運ぶデータの種類の数で決まるため、この軸には現れません。

段階料金（〜10万件／〜100万件）をどう読むか

件数の段階料金が出てきたら、段差の理由を1つずつ聞いてください。 説明できる段差と、できない段差があります。

そして、料金体系にかかわらず有効な質問が1つあります。

件数がいまの見積もりの10倍になった場合、御見積の各行はそれぞれ何倍になりますか。

この質問は、後述の確認質問7として再掲します。工程別に答えが返ってくるなら、その見積もりは分解されています。「全体で10倍です」と返ってくるなら、変換ルール設計もリハーサルも件数比例で計算されていることになり、その根拠を聞く番です。

その料金体系が合理的といえる条件｜件数課金・一式・別途見積もりの3つ

件数課金にも一式表記にも、合理的なケースがあります。先に条件を書いておきます。 自分の見積書がこの条件を満たしているなら、内訳を出させることが目的化する必要はありません。

件数課金が合理的といえる条件は、次の3つが揃っている場合です。第一に、1件あたり単価の対象となる作業が特定されていること（前述の人手作業、または処理時間に連動する部分）。第二に、その単価に含まれない工程——棚卸し、変換ルール設計、リハーサル、照合——が別の行として立っていること（クレンジングと移行処理は件数が一部効くため、ここでは除いています）。第三に、件数の数え方が定義されていること。同じデータでも、テーブル行数で数えるのか、業務上の1件（1受注に10明細なら1件）で数えるのかで、数字が桁違いになります。

一式表記が合理的といえる条件もあります。すでに要件定義が終わり、移行対象一覧と変換ルール定義が別紙として存在していて、見積書の「一式」がその別紙を指している場合です。この場合、分解された情報は存在していて、見積書の表面に出ていないだけです。別紙を請求して、内容が上記6工程を覆っていれば、それ以上の分解は不要です。

もうひとつ、移行費が「要件確定後に別途見積もり」となっているケースも、それ自体は不合理ではありません。移行元データの実態を見る前に精度の高い金額は出せない、というのは実務的に正しい判断です。ただしこの場合は、確定の時期、確定までに実施する調査の範囲と費用、そして概算の上限が書かれている必要があります。3つとも無ければ、金額の上限が存在しない契約になります。これは、対象外欄と再見積もり条件をどう埋めさせるかという、開発費が後から増える条件の一般形と同じ構造です。

4状態で仕分ける｜説明済み・要確認・高リスク・判断不能

見積書の移行に関する記載を、金額の高い安いではなく状態で仕分けます。この表は、そのまま社内の稟議資料に転記できます。

高リスクと判断不能が1つでもある状態で、金額の比較をしても意味がありません。 比較しているのは金額ではなく、書き方の違いだからです。

同じ「データ移行費」でも、中身は同じではない

2社の見積書に、同じ「データ移行費」という行が並んでいるとします。金額が違ったとき、それが範囲の違いなのか単価の違いなのかを判別する方法を示します。以下は、書き方の差を見るために作った対比で、実在の見積書ではありません。金額は記載していません。

この表で分かるのは、A社が安いか高いかではありません。 A社の見積もりは、B社が6行で書いたもののうち何が入っているのかを判定できない、ということです。総額が低くても、リハーサルと照合が範囲外なら、その作業は消えたのではなく発注側に移っています。

相見積もりを取るときは、この確認項目の列だけを抜き出して全社へ同じものを送ってください。 そのまま条件そろえのシートとして使えます。開発会社を横並びで比較する手順全体は開発費用の相場と見積もり妥当性の判断にまとめてあります。

「安い」データ移行見積もりのほうが危険なとき

移行費の見積もりでは、高すぎることよりも抜けていることのほうが、結果として高くつきます。次の4つは、金額を下げますが作業を消しません。

1. リハーサルが0回または1回。 本番当日に初めて通しで実行することになります。当日に処理が想定時間内に終わらなかった場合、業務再開が遅れます。戻す判断（切り戻し。移行前の状態へ戻す作業です）をどの時点でするか、戻す作業に何時間かかるかが決まっていないなら、その日は上限のないリスクを負う日になります。

2. 照合が「移行後確認」の一言しかない。 移行の失敗は、当日ではなく数週間後に業務側で発見されることがあります。前掲の手順書も、運用テスト・研修の項で「システム更改後、データ移行内容やシステム間の連携において問題が発生することが多いため、事前に十分に運用テストを実施する（略）」と記載しています。発見が遅れるほど、修正のコストは上がります。 すでに新システムで更新されたデータと、移行し直したデータをどう突き合わせるかという別の問題が発生するためです。

3. 現行ベンダーへのデータ抽出費用が入っていない。 前述のとおり、公的な手順書が予算要求の留意点として名指ししている論点です。旧システムの契約に、契約終了時のデータ提供が含まれているか。含まれていない場合、抽出作業の見積もりは旧ベンダーが出します。この金額は、新システム側の見積もり比較では見えません。

4. クレンジングが「発注側で実施」となっているが、量が示されていない。 自社でやると決めたなら費用は下がりますが、社内の誰かの時間は消費されます。6検討事項のうちどれが自社作業で、対象が何件・何項目あるのかが示されていなければ、その負担量を見積もることができません。判断できるようになってから引き受けてください。

同じ抜け方は、移行以外の工程でも起きます。 テスト、セキュリティ対応、プロジェクト管理も、行が無いことは作業が不要という意味にはなりません。見積書全体で同じ確認をしてください。

移行費の行が分かれていないと、経理の区分が検討できない

ここまでは発注判断の話でしたが、移行費が独立行になっているかどうかは、経理処理の場面でも効いてきます。 見積書の粒度が、決算にそのまま影響する数少ない論点です。

企業会計基準委員会の移管指針第8号「研究開発費及びソフトウェアの会計処理に関する実務指針」（2024年7月。日本公認会計士協会の会計制度委員会報告第12号から移管されたもの）は、ソフトウェアの導入費用について次のように分けています。

第16項に挙げられているのはこの2つだけです。そして、資産計上された自社利用ソフトウェアの償却について、同指針第21項は「原則として5年以内の年数」としています（5年を超える場合は合理的な根拠が必要）。

つまり、同じ請求書のなかで、費用が2つの経路に分かれます。 設定作業や自社仕様への修正はソフトウェアの取得価額へ入って複数年で費用化される可能性がある一方、データコンバートの費用は発生した年度に費用として処理される。見積書で移行費が独立行になっていなければ、この区分を検討する材料がありません。

税務側の取扱いは、会計とは別の規定によります。国税庁の法人税基本通達 7-3-15の2の注1は、他の者から購入したソフトウエアについて「導入に当たって必要とされる設定作業及び自社の仕様に合わせるために行う付随的な修正作業等の費用の額は、当該ソフトウエアの取得価額に算入することに留意する」としており、実務指針第14項と同じ方向を向いています。続く7-3-15の3は「ソフトウエアの取得価額に算入しないことができる費用」として3つを挙げています。列挙されているのは、仕損じによる費用、研究開発費の額、そして製作原価のおおむね3%以内の少額な間接費・付随費用等で、データコンバート費用はこの3つに含まれていません。ただし同項の柱書は「次に掲げるような費用の額は」という書き方で、限定列挙ではありません。列挙されていないことが、ただちに取得価額へ算入すべきことを意味するわけではありません。

この記事は会計・税務の助言ではありません。実際の処理は、監査人および顧問税理士の判断によります。ここで伝えたいのは1点だけです。 移行費が「一式」に溶けている見積書では、経理部門が区分を検討することも、税理士に相談することもできません。内訳を分けてもらう依頼には、発注判断とは別に、この理由もあります。 ベンダーへ伝えるときは「経理処理の区分のため、移行費を独立した行として計上してください」と書けば、意図が正確に伝わります。

ベンダーへそのまま送れる確認質問10問

ここまでの論点を、コピーしてそのまま送れる形にしました。技術的な知識がなくても送れます。すべて送る必要はありません。 前掲の4状態表の「送る質問」列を見て、自分の見積書で「要確認」「高リスク」「判断不能」になった行に対応するものだけを選んでください。

そのまま送れるメール文面

いつもお世話になっております。

お送りいただいたお見積書について、社内の稟議と契約書の別紙作成に
あたり、データ移行に関する費用の内訳を確認させていただきたく存じます。
金額の妥当性を疑うものではなく、作業範囲と役割分担を明確にするための
確認です。下記についてご確認をお願いできますでしょうか。

1. 移行対象の一覧をご提示ください。対象となるシステム・テーブル
   （または帳票・台帳）・項目、および移行する年度範囲と、それぞれの
   概算件数を含めてください。あわせて、移行しないデータについても
   対象と理由をご記載ください。
   なお、現時点で移行費を確定できない場合は、確定できる時期、それまでに
   実施される調査の範囲と費用、および現時点での概算の上限額を、
   あわせてご教示ください。

2. 変換ルールの本数と、その定義書の納品有無をご教示ください。
   旧項目と新項目の対応表、およびコード値の変換規則が、成果物として
   納品されるかどうかを含めてください。

3. データクレンジングについて、以下の6点それぞれの担当（御社／弊社／
   協議のうえ決定）をご教示ください。
   (1) 現行システムに無いが新システムで必要になる項目の取扱い
   (2) 履歴の管理方法が異なる項目の取扱い
   (3) コード値のバリエーションが異なる項目の取扱い
   (4) 新システムで必須となるデータの欠損
   (5) 新システムで必須となるデータの誤り
   (6) 項目桁数の差異
   弊社担当となるものについては、対象件数・対象項目数の見込みも
   あわせてご教示ください。

4. 移行リハーサルの回数、実施環境、使用するデータ、および本見積もりに
   含まれるかどうかをご教示ください。本番同等の環境で実データを用いて
   実施するのか、件数を絞った検証データで実施するのかを明記してください。

5. 移行後の照合方法をご教示ください。件数の突合、金額等の集計値の突合、
   項目内容の全件突合、抽出したデータの目視確認のうち、どれをどの範囲で
   実施するかをご記載ください。あわせて、照合で不一致が見つかった場合の
   再実行・再修正の費用の扱い（本見積もりに含まれるか、別途か）も
   教えてください。

6. 現行ベンダーからのデータ抽出・提供にかかる費用は、本見積もりに
   含まれていますか。含まれない場合、弊社が現行ベンダーへ確認すべき
   事項をご教示ください。

7. 移行件数が現在の見積もり前提の10倍になった場合、御見積書の各行は
   それぞれ何倍になりますか。工程ごとにご回答ください（変わらない行は
   その旨をご記載ください）。件数による段階料金を設定されている場合は、
   段差が生じる理由（処理日数の増加、人手確認の件数の増加、上位プランへの
   変更など）もあわせてご教示ください。

8. 御見積書に記載されている移行件数について、その数え方の定義を
   ご教示ください。データベースの行数で数えるのか、業務上の1件
   （例：1受注に明細10行がある場合に1件と数えるか10件と数えるか）で
   数えるのかを明記してください。

9. 本番移行当日に必要となるシステム停止時間の見込みと、その時間内に
   完了しなかった場合の対応をご教示ください。切り戻し（移行前の状態へ
   戻す作業）の可否、所要時間、判断のタイミング、および費用の扱いを
   含めてください。あわせて、移行完了後に旧システムのデータを保持する
   必要がある場合、その保持期間と費用の扱いについても教えてください。

10. 経理処理の区分のため、データ移行に係る費用を独立した行として
    ご計上ください。設定作業や自社仕様への修正作業とは分けて記載を
    お願いいたします。

お手数をおかけしますが、契約書の別紙として添付したく、書面での
ご回答をお願いいたします。

不要な項目は削除し、番号を振り直してから送ってください。

回答をどう読むか

返ってきた内容は、次の基準で仕分けます。金額ではなく、空欄が埋まったかどうかで評価してください。

「追加で確認が必要」側の回答が、悪い回答とは限りません。 移行元データの実態を見る前に答えられないことは実際にあります。その場合に確認すべきなのは、いつ答えられるようになるのか、そのための調査に費用がかかるのかです。調査自体が有償の作業になることもあり、それを発注するかどうかも経営判断の1つです。

回答が揃ってから、金額の議論に入ってください。 順序が逆になると、比較できない数字を比べることになります。

この記事のあとに進む順番

1. 見積書の移行に関する行が、前掲のどの型かを特定する。 型が決まれば、送る質問が決まります
2. 移行対象一覧と変換ルール定義（またはその予定）を出してもらう。 この2つが出てくれば、6工程の残り4つは会話ができるようになります
3. 4状態表で仕分ける。 「高リスク」「判断不能」が残っている間は、金額の比較をしない
4. 上の質問から、必要なものだけを選んで送る。 回答は書面で受け取り、契約書の別紙に添付できる形にしておく

移行費以外の行についても同じ確認が必要な場合は、開発見積書のAIレビュー（登録不要）で見積書全体を整理できます。ブラウザ内でテキストを抽出し、登録なしで、結果の閲覧までメールアドレスの入力なしに使えます。

根拠資料と適用条件

本記事で使用した資料と、その適用条件です。いずれも2026年8月24日に取得しました。

本記事で提示していないもの、およびその理由です。

よくある質問