「いまのCRMは使いにくいから、HubSpotに乗り換えれば全部きれいになる」。移行プロジェクトの起点で、こう期待されることがよくあります。しかし結論を先に言えば、ツールを乗り換えても、データの汚れはそのままついてきます。重複した会社レコード、前株後株の表記揺れ、2年前に異動した担当者の名前。これらは移行作業のどこかで自動的に消えるわけではなく、何もしなければ新品のHubSpotにそっくり再現されます。移行とは器を入れ替える作業であって、中身を洗う作業ではないからです。本稿では、CRM移行という局面に固有の論点に絞って、「汚いまま移行して汚いCRMが完成する」を避けるために、移行前のクレンジングと識別子・プロパティ設計をどう組むかを整理します。
移行は浄化の機会であって、自動浄化ではない
まず押さえたいのは、移行は「データを見直す絶好の機会」ではあっても、「データが自動で浄化される工程」ではないという区別です。この2つを混同すると、移行後に同じ汚れを抱えたまま運用が始まります。
そもそも既存CRMのデータがどの程度汚れているのかは、各社の調査が共通して厳しい数字を示しています。データ品質ツールを提供するValidity社が2024年に公表したCRM管理者600名超への調査では、24%が「自社CRMデータのうち正確かつ完全なものは半分未満」と回答し、31%が「低品質なデータによって年間売上の20%以上を失っている」と答えています（参照：Validity「State of CRM Data Management in 2024」(2024)）。別系統の調査でも傾向は一致します。Experian社が2021年に公表した700名のデータ責任者への調査では、顧客・見込み客データのおよそ3分の1が不正確だと認識されており、「CRM/ERPのデータがクリーンで活用できる状態にある」と答えた組織は50%にとどまりました（参照：Experian「2021 Global Data Management Research」(2021)）。いずれもデータ品質ベンダーの調査であり、問題を大きく見せる動機がある立場である点は割り引いて読む必要がありますが、それでも「移行元のデータの半分前後は怪しい」という現場感覚と大きくはズレません。
ここで分岐が生まれます。移行前にこの汚れを洗うか、洗わずに運ぶか。洗わずに運べば、24%や3分の1という不正確さが、そのまま新環境の初期状態になります。新しいツールの管理画面は美しくても、開けば古い重複と表記揺れが並んでいる。これが「汚いCRMが新品で完成する」状態です。移行は、汚れを持ち越すか断ち切るかを選べる数少ないタイミングであり、その選択を意識的に行うことが第一歩になります。
項目マッピング設計が移行作業の本体
次に、移行作業で最も時間と判断を要するのは、ファイルの取り込みそのものではなく、どの列をHubSpotのどのプロパティに対応させるかという項目マッピングの設計です。ここが移行の本体だと考えてよいと思います。
HubSpotの公式仕様（2026年6月時点）では、インポート時にファイルの各列をHubSpotのプロパティへ手動でマッピングします。対応するプロパティがない列は「Don't import column」を選んで取り込みを見送ることができ、必要な列だけを選別して移せます（参照：HubSpot「Import objects」(2026)）。つまりインポートとは、既存CRMの項目を機械的に丸ごと写し取る作業ではなく、「何を、どの器に、どの粒度で入れるか」を1列ずつ決めていく設計作業です。
ここで日本のCRMには、マッピング前に正規化しておきたい固有の論点があります。
- 全角と半角の混在: 「ＡＢＣ商事」と「ABC商事」、「０３−」と「03-」。人の目には同じでも別の文字列として移ります。マッピング前に表記を寄せておかないと、移行後に検索や重複判定をすり抜けます。
- 社名表記の揺れ: 「(株)」「株式会社」「カブシキガイシャ」、前株と後株の混在。同じ1社が複数の表記で並んでいると、後述する重複判定の精度が落ちます。
- 部署・役職の自由入力: 「営業部」「営業課」「セールス」が混在し、役職欄に部署名が入っているようなケース。HubSpot側でプルダウンの選択肢プロパティに寄せるなら、移行前に値を整理しておくほど後が楽になります。
マッピング設計を「列をプロパティに割り当てる作業」とだけ捉えると、これらの正規化が後回しになります。実際には、マッピングの前段で値を揃えておくことこそが、移行品質を左右する工程です。
重複を作り込まない識別子設計
三つ目の論点は、移行のやり方しだいで重複は減らせるどころか増やせてしまう、という点です。だからこそ、何をもって「同じレコード」と判定するかを事前に設計しておく必要があります。
HubSpotのインポートには、重複を判定するための照合ルールがあります（2026年6月時点）。最優先されるのはHubSpotの内部ID（Record ID）で、これが一致すれば確実に同一レコードとして更新されます。Record IDがない場合、コンタクトはメールアドレス、会社は会社ドメイン名で既存レコードと照合されます。また「Prevent property overwrite」を使えば、既存の値を保護したまま空欄だけを埋める取り込みも可能です（参照：HubSpot「Import objects」(2026)）。
この仕様を踏まえると、重複を作り込まないための勘所が見えてきます。
- 照合キーを事前に決める: 会社をドメインで照合するなら、移行ファイルにドメイン列を整備しておく。メールやドメインが欠けているレコードは照合キーを失い、新規として重複登録されやすくなります。
- 複数ドメイン・部署別レコードの扱いを決める: グループ会社で複数ドメインを持つ企業や、部署ごとに別レコードを立てている運用は、統合すべきか分けるべきかを移行前に方針化しておく。曖昧なまま移すと、統合しすぎて履歴が混ざる、あるいは分裂したまま残る、どちらの事故も起こり得ます。
- 二度取り込みで重複を量産しない: 同じファイルを照合キーなしで二回流せば、レコードは単純に倍になります。テスト取り込みと本番取り込みの手順を分け、本番では照合キーを必ず指定する。これは設計というより事故防止の段取りです。
なお、HubSpotのインポートでは既存のメール・ミーティング・ノート・タスクといった活動履歴はインポートで更新できない点にも注意が必要です（参照：HubSpot「Import objects」(2026)）。活動履歴をどこまで、どう持ち込むかは別途の設計事項として、移行範囲の線引きに含めておくのが安全です。
移行後の品質劣化を設計で止める
四つ目に、移行をきれいに完了できたとしても、運用が始まれば入力ルールが緩いCRMは再び汚れていきます。だからこそ移行は、入力の仕組みそのものをリセットする好機でもあります。
Experian社が2022年に公表した調査（905名対象、2021年10月実施）では、「データがクリーンで活用できる」と答えた組織は44%と、前年の50%から低下しました。一方で同調査は、「データ品質を改善した企業の75%が年間目標を上回った」とも報告しています（参照：Experian「Quality data proves critical to business performance」(2022)）。データ品質は放っておけば下がる一方で、改善した企業には成果がついてくる。この非対称が示すのは、品質は一度の大掃除ではなく、入力時点で汚れを止める仕組みで守るものだということです。
低品質なデータが見えにくい形でコストを生むことも、繰り返し指摘されています。Gartnerは2020年時点で、低品質なデータが組織にもたらすコストを平均で年間1,290万ドルと見積もっています（参照：Gartner「Data Quality」(2020)）。これはマジック・クアドラントの参照顧客154社の自己申告にもとづく平均値であり、業種・規模で大きく振れる前提つきの目安ですが、1ドル150円換算で年間およそ19億円規模になります。日本企業にそのまま当てはまる数字ではないものの、「データの汚れはコストである」という方向感は共通です。
移行のタイミングで設計し直しておきたいのは、おおむね次の三点です。
- 入力ルール: 表記揺れを生む自由入力を、選択肢プロパティや必須項目に置き換える。移行で値を揃えた直後だからこそ、ルールを定着させやすい。
- 必須項目: 営業・マーケに本当に必要な項目を絞り、それだけを必須化する。何でも必須にすると現場が空欄回避のためにダミーを入れ、新たな汚れになります。
- 所有者設計: レコードの担当者（オーナー）の付け替えルールを決める。異動のたびに履歴が宙に浮くのを、運用ルールとして止めておく。
移行を「データを運ぶ作業」ではなく「入力設計を入れ替える作業」として捉え直すと、移行後の劣化スピードは目に見えて変わります。
Respectifyが移行で先に固める順番
ここまでの論点を、Respectifyが支援の現場で実際にどう順序立てているかとして整理します。私たちは移行案件で、ファイルの取り込みより前に三つを固めます。
第一に、移行範囲の線引きです。全レコードを運ぶのではなく、直近1年に活動のある企業・人を優先し、長く動きのないレコードはアーカイブ扱いにして移行対象から外します。母数を絞るだけで、後続のクレンジングもマッピングも軽くなります。第二に、表記ルールと照合キーの確定です。前株後株・全角半角のルールを1枚にまとめ、会社はドメイン、人はメールという照合キーを移行前に整備します。第三に、プロパティ設計です。既存CRMの項目をそのまま写すのではなく、HubSpot側で残す項目・選択肢化する項目・捨てる項目を決めてからマッピングに入ります。
この順番を踏むと、移行は「汚れを持ち越すリスク」から「汚れを断ち切る機会」へ反転します。すでに入っているCRMのデータ整備と再設計から始めて、そのうえでHubSpotへ移すという進め方は、CRMデータ整備から始める営業最適化の支援の中心的なテーマの一つです。なお、移行の前提となる「そもそも何を残すべきデータか」という観点は、別稿「AIの前にCRMの汚れを片付ける」でも扱っているので、クレンジングの優先順位に迷う場合はあわせてご覧ください。
まとめ
- 移行は浄化の機会ではありますが、自動浄化の工程ではありません。Validityの2024年調査では24%が「正確・完全なデータは半分未満」、Experianの2021年調査でも顧客データの約3分の1が不正確とされ、洗わずに運べばこの汚れがそのまま新環境の初期状態になります。
- 移行作業の本体は項目マッピングの設計です。HubSpotは列を手動でプロパティに割り当て、不要な列はスキップできます（2026年6月時点）。日本特有の全角半角・社名表記揺れ・自由入力は、マッピング前に正規化しておくのが要点です。
- 重複は移行のやり方しだいで量産できてしまいます。Record IDを最優先に、会社はドメイン、人はメールで照合し、Prevent property overwriteで既存値を守る設計を事前に固めます（2026年6月時点）。
- 移行後の劣化は入力設計で止めます。Experianの2022年調査では品質を改善した企業の75%が年間目標を上回った一方、Gartnerは2020年時点で低品質データのコストを年平均1,290万ドル（1ドル150円換算で目安およそ19億円）と見積もっています。入力ルール・必須項目・所有者設計をリセットする好機です。
- Respectifyは移行案件で、取り込みより前に移行範囲・照合キー・プロパティ設計の三つを固めます。順番を守ることが、汚れを断ち切る機会に変える鍵です。
ツールを乗り換えても、データの汚れは自動では消えません。自社のCRMをHubSpotへ移すときに何から手をつけるべきか迷う場合は、無料相談からお気軽にご相談ください。
