CRM移行・乗り換えガイド｜HubSpotへのデータ移行と定着支援の進め方

CRM移行は、データを移すだけでなく、業務プロセスと運用ルールを整えるプロジェクトです。現状の使い方を見直し、移行後に定着する仕組みまで設計します。

「今のCRMに情報は蓄積されているのに、必要なデータをすぐ見つけられない」
「表計算ソフトとCRMの両方を更新していて、どちらが正しい情報かわからなくなる」
「移行後に営業活動が混乱したり、現場に使われなくなったりしないか不安」

CRM移行とは、既存CRMの顧客情報や取引情報を新しいCRMへ移し、業務プロセスや運用ルールも移行先に合わせて設計し直す取り組みです。データをコピーするだけではなく、何を残し、どのように結び付け、誰がどう使うかを決めることが重要です。

本記事はStartLinkの「HubSpot完全ガイド」関連記事です。

この記事でわかること

CRMを乗り換える前に整理したいデータや業務の範囲、移行元ごとの設計上の違い、移行後の定着までを順に解説します。移行計画を具体化する際の確認材料として活用してください。

• 移行プロジェクトの流れ — 現状分析から環境構築、移行テスト、定着支援まで、作業のつながりを整理できます。
• 移行元CRMごとの設計ポイント — データ構造や自動化の違いに応じて、移行先で再設計する内容を把握できます。
• データ設計と検証の考え方 — 項目の対応付け、重複や欠損の確認、関連付けの検証方法を説明します。
• 段階的な移行と定着の進め方 — 優先順位を決め、小さく始めて運用を広げる方法を確認できます。

CRM移行は業務プロセスの再設計から始める

CRM移行では、現行システムの情報をそのまま新しい環境に再現することが目的ではありません。手作業の表計算や複数の台帳に分散している情報を整理し、営業活動から顧客管理までの流れを扱える形にすることが出発点です。移行対象と運用上の課題を明確にしてから、データと仕組みの設計に進みます。

移行の目的と対象業務を決める

まず、なぜ乗り換えるのかを業務上の課題として記述します。例えば、次のような課題です。

• 情報の分散 ── 顧客情報が複数の場所に分かれている
• 基準のばらつき ── 取引状況を担当者ごとに異なる基準で管理している
• 履歴の追いにくさ ── 活動履歴を追いにくい

次に、対象とする業務を決めます。整理する点は次のとおりです。

• 移す情報 ── コンタクト（個人）、会社、取引、チケットなど、どの情報を移すか
• 対象に含める業務の範囲 ── 問い合わせから商談、受注後の顧客対応までを対象に含めるか

現行データと利用状況を棚卸しする

移行元のオブジェクト、項目、レコード、関連付け、入力ルール、自動化を一覧にします。使われている項目と使われていない項目を分け、移行が必要な情報と、統合・整理する情報を判別します。

項目の棚卸しでは、名前だけで判断せず、入力される値や利用場面も見ます。

• 同じ意味の項目が複数ある場合 ── 統合候補とする
• 利用目的が説明できない項目 ── 移行対象に含める理由を確認する
• 運用実態がわかる担当者への確認 ── 設計資料と実際の入力内容のずれを洗い出す

移行先で実現する状態を定義する

移行先では、コンタクトや会社の情報を取引に関連付け、営業活動の履歴とともに確認できる構成を検討します。取引はパイプラインの各段階で状況を表し、受注後の顧客管理や請求に関わる情報へつなげます。HubSpotの機能を個別に設定するのではなく、業務フロー上でどこを支えるかを決めることがポイントです。

移行後の画面やレポートで何を判断したいかも定めます。例えば、次のような目的によって、必要な項目や入力タイミングが変わります。

• 進行中の取引を把握する ── 取引の状況を確認する目的
• 担当者への引き継ぎ ── 引き継ぎに必要な情報を確認する目的

運用する人が迷わないよう、項目は用途に合わせて絞り込みます。

CRM移行プロジェクトをフェーズに分けて進める

移行プロジェクトは、現状分析、環境構築、データ移行とテスト、定着支援の順に進めます。各フェーズの成果物と次へ進む条件を決めておくと、データ移行後に要件の抜けが見つかる事態を減らせます。移行にかかる期間は、移行元の複雑さや対象範囲によって変わります。期間の目安は固定のスケジュールではなく、作業量を見積もるための参考にします。

4つのフェーズと確認する成果物

各フェーズは独立した作業ではありません。例えば、要件定義で決めたパイプラインの段階が変われば、取引データのマッピングやレポート設計にも影響します。仕様変更があったときは、関連する項目、移行テスト、研修資料も合わせて見直します。

作業を小さく区切って移行する

対象範囲が広い場合は、全業務を一度に切り替える前に、優先度の高い部門やデータから段階的に進める方法があります。

1. テスト対象を決める
2. 実際の利用者が試す ── 入力から確認までを試します
3. 運用上の問題を修正する
4. 対象範囲を広げる

一括切り替えと段階的な移行には、それぞれ次の特徴があります。

どちらを選ぶかは、部門間の依存関係、データ更新の頻度、並行運用中の二重入力を防ぐ方法で判断します。

移行とトレーニングの順番を合わせる

トレーニングは、システムの説明を一度行って終わりにするのではなく、実際の業務手順に合わせます。担当者が日常的に行う、次のような作業を移行後の画面で練習します。

• コンタクトの確認
• 取引の登録
• ステージ更新
• 活動履歴の記録

入力ルールは、マニュアルだけでなくシステム側の項目やステージ設定にも反映させます。担当者の記憶や個人の工夫に依存させず、どの情報をいつ入力するかが画面上でわかるようにすると、引き継ぎ後も同じ流れを保ちやすくなります。

データマッピングと移行テストで品質を確かめる

マッピングは、移行元の項目を移行先のプロパティに対応付ける作業です。項目名を機械的に対応させるだけでは、選択肢や形式、関連するレコードの意味が異なる場合に不整合が生じます。データを移した後に業務で使えるかを基準に、項目ごとの扱いを決めます。

プロパティマッピングを設計する

マッピング表には、次の内容を記載します。

• 移行元 ── オブジェクトと項目
• 移行先 ── オブジェクトとプロパティ
• 値の変換ルール
• 必須かどうか
• 移行後の利用目的

移行しない項目についても、対象外とする理由を残すと、後から必要性を再検討できます。

例えば、移行元の「案件名」がHubSpotの取引名に対応する場合でも、値の付け方が担当者ごとに違っていれば、そのまま移すか整えるかを判断します。

• 選択肢の値が一致しない項目 ── 移行先の選択肢に合わせた変換表を作る
• 空欄の扱いや日付・数値の形式 ── 先に決める

関連付けと活動履歴の扱いを決める

コンタクト、会社、取引の情報は、それぞれを移すだけでなく、どのレコード同士を結び付けるかを設計します。

会社名の表記揺れやメールアドレスの欠落があると、意図した関連付けができないことがあります。共通の識別値があるかを確認し、照合に使う項目を定めます。

活動履歴やメモ、タスクなどは、移行元と移行先で扱いが異なる場合があります。次の点を決めます。

• 対象に含める履歴
• 移行後に参照する方法
• 移せない情報の保管先

履歴をすべて移すことが業務上必要なのか、参照頻度の高い情報に絞るのかも検討します。

公式インポート仕様に合わせてファイルを準備する

HubSpotへのインポートファイルはCSV、XLSX、またはXLS形式で、シートは1つにし、各列にプロパティへ対応するヘッダー行を設けます。複数オブジェクトを同時に取り込む場合は、ファイル内のレコード配置や共通識別値を使って関連付けを設定します（出典：インポートファイルの形式、複数オブジェクトのレコードをインポートする）。

以下の画面は、HubSpotのインポートで対象オブジェクトを選択する手順を示しています。

インポート前には、列とプロパティの対応、値の形式、重複判定に使う識別情報を確認します。特定の形式や追加機能が必要な場合は、対象オブジェクトと利用プランに応じた公式要件を確認してからファイルを整えます。

ファイルと処理量は契約ごとに異なります。HubSpot公式の通常インポートでは、次のとおりです。

後者の1ファイル当たりの行数上限は1,048,576行で、両者とも同時に開始できるインポートは最大3件です。

対象データの行数とファイル容量を先に数え、上限に近い場合は分割単位と実行順を計画します（出典：インポートファイルの形式と技術上限）。

値の照合では、次の点を確認します（出典：インポートファイルの形式と値の指定）。

• 選択肢プロパティの値 ── HubSpot側の定義済みラベルまたは内部値と合うかを検査する
• 既存レコードを更新するファイル ── 対象オブジェクトごとの一意の識別子を入れる
• 空欄の扱い ── インポートファイルの空欄は既存プロパティの値を消去しないため、空欄を「未入力」か「削除したい値」かに分け、後者は別の更新手段を検討する

テスト移行と本番後の照合を行う

本番の前に一部のデータで試行し、マッピングと関連付けを検証します。テスト対象には、通常のレコードだけでなく、次のデータも含めます。

• 空欄
• 重複
• 選択肢の例外
• 関連付けが複雑なデータ

問題があれば、変換ルールや対象範囲を修正してから再度試します。

本番移行後は、移行元と移行先の件数を比較するだけでなく、代表データを選んで次の点を確認します。

• 項目値
• 会社とコンタクトの関連
• 取引ステージ
• 活動履歴

差異があれば、対象範囲と原因を記録し、修正後に再確認します。

移行元CRMごとに再設計する範囲を見極める

移行元CRMのデータ構造やカスタマイズの方法によって、再設計の範囲は変わります。標準項目を移せるかだけでなく、自動化、関連付け、独自の業務ルールを移行先でどう表現するかを確認します。移行元と同じ画面や機能を再現することではなく、必要な業務結果を保てるかを判断基準にします。

Salesforceから移行する場合

Salesforceのオブジェクトは、HubSpotでは次のように対応させる設計になります。

Salesforceの標準オブジェクト移行には公式のインポート機能を利用できます。移行の難易度は、データ量やカスタマイズの深さによって変わります。

Apexやプロセスビルダーで実現していた自動処理は、移行後も同じ動作になるとは限りません。次の点を整理し、HubSpotのワークフローなどで再構築する要否を決めます。

• 処理の起点
• 条件
• 更新する情報
• 通知先

複雑な関連付けや独自オブジェクトがある場合は、代表データで試行し、標準機能で扱える範囲を確認してから設計を確定します。

移行元とHubSpotの連携機能を使って段階的にデータを扱う方法もあります。HubSpot公式のSalesforce連携では、利用できる機能や必要な契約が機能ごとに定められています。

インポートや同期を使う場合は、目的のオブジェクトが対象か、契約要件を満たすかを公式資料で確認します（出典：Salesforceレコードのインポートと同期）。

詳細な検討には、SalesforceとHubSpotの連携・併用ガイド｜段階的移行か一括移行か判断する基準やSalesforce移行で失敗する原因と対策も参考になります。

kintoneから移行する場合

kintoneはアプリ単位でデータ構造を作れるため、同じ製品を利用していても企業ごとに構成が異なります。各アプリが顧客、会社、案件、活動のどれを表すかを確認し、HubSpotのコンタクト、会社、取引、カスタムオブジェクトなどへ対応付けます。

• アプリ間のルックアップや関連レコード ── HubSpotでの関連付けに置き換える設計が必要です
• テーブルフィールド ── そのまま対応する機能がないため、行の情報を別のオブジェクトとして扱うのか、項目を整理して一つのレコードに含めるのかを、利用目的から判断します
• JavaScriptカスタマイズ ── 実現している業務処理を分解してから、ワークフローや計算プロパティなどで代替できるかを評価します

個別のデータ設計は、kintoneからHubSpotへの移行ガイドで確認できます。

Zoho CRM、SHANONなどから移行する場合

Zoho CRMでは、CSVで項目を移せることと、業務フローまで引き継げることは別です。

手順の詳細は、Zoho CRMからHubSpotへの移行ガイドおよびSHANONからHubSpotへの移行ガイドを参照してください。

CSV移行を検討する場合

Microsoft Dynamics 365やPipedriveからの移行には、CSVインポートを使う方法があります。ファイルを取り込めるかだけではなく、レコードを一意に識別できるか、複数のオブジェクトを正しく関連付けられるかを確認します。

移行の複雑さは、次の点で見極めます。

• カスタマイズの深さ
• データ量
• 関連付けの複雑さ
• 並行運用の必要性

レコード数や移行期間は方法を選ぶ際の判断材料になります。ただし、環境ごとの差があるため、一律の境界として扱わず、試行移行と必要な処理量から方法を選びます。

• 標準的なCSVインポートで要件を満たせる場合 ── その方法を検討します
• 変換や関連付けの制御が難しい場合 ── APIや専用ツールを候補にします

定着を支える運用設計と段階的な改善

移行後の定着は、利用者に操作を覚えてもらうだけでなく、日々の業務の中で必要な情報が入力され、次の担当者が使える状態をつくることです。項目やルールを増やしすぎると入力の負担が増え、使われない情報が蓄積する場合があります。まず必要な業務に絞り、使いながら調整する設計が適しています。

入力項目とパイプラインを絞る

営業パイプラインは、次の要素を軸に設計します。

• 取引ステージ
• ステージごとの受注確度
• 各ステージの定義
• ステージ移行時に必要なプロパティ

例えば、見積もり提示の段階で金額やクローズ日が必要なら、その段階に進む際に入力を促す仕組みを検討します。ステージ名だけを移行しても、各担当者が異なる基準で更新していれば、取引状況を比較できません。

既存の項目をすべて引き継ぐのではなく、営業活動に必要な情報と、レポートや判断に使う情報を分けて選びます。

システム上のルールで入力を支える

入力漏れを個人の注意だけに委ねず、プロパティ、ワークフロー、パイプラインの設定で支える方法を検討します。例えば、次のような仕組みです。

• 通知 ── 特定の条件を満たしたときに担当者へ通知する
• 次の処理への進行 ── 必要な情報が揃った段階で次の処理に進める

ただし、移行直後に自動化を広げすぎると、想定外の通知や更新が起きた際に原因を追いにくくなります。

1. 重要度の高い業務ルールを一つずつ設定する
2. テストデータで動作を確かめる
3. 対象範囲を広げる ── 担当者が結果を確認でき、例外時の対応も決まったら広げます

使われ方を見て改善する

移行後は、次の点を定期的に確認します。

• 入力状況
• 利用者からの質問
• 手作業で補っている箇所

使われていない項目があれば、入力の目的やレポートでの必要性を見直します。運用上の困りごとは担当者個人の工夫で解決し続けるのではなく、共通ルールや設定に反映できるかを検討します。

失注した取引も、記録して終わりにせず、理由を分類して次の営業やマーケティングの改善に活用できます。

• 失注理由の記録 ── 適切に記録されれば、どの段階で商談が止まりやすいかを振り返れます
• 見直しの材料 ── 見込み顧客への情報提供や営業プロセスを見直せます

こうして、コンタクトへの対応から取引管理、顧客化後の業務へと情報をつなげます。

移行プロジェクトの費用と工数を整理する

移行にかかる費用は、CRMの利用ライセンスだけでなく、次のように分けて検討します。

• 要件整理
• データ整備
• 設計
• 移行作業
• テスト
• トレーニング

作業範囲を曖昧にしたまま見積もると、移行元のカスタマイズやデータ品質に応じた追加作業を把握しにくくなります。

費用や工数を抑えるには、移行対象を絞り、使われていない項目や不要な自動化をそのまま再現しないことが有効です。初期段階では、必要性の高い業務とデータから始め、利用状況を見ながら範囲を広げます。

よくある質問

CRM移行では、最初に何を整理すればよいですか？

まず移行の目的と対象業務を整理します。次に、現行CRMのオブジェクト、項目、利用状況、自動化、関連付けを棚卸しし、移行する情報と見直す情報を分けます。業務で使う場面が説明できる項目から設計すると、不要なデータまで引き継ぐのを避けやすくなります。

CRM移行中に旧CRMとHubSpotを並行運用すべきですか？

一括切り替えか段階的な移行かは、部門間の依存やデータ更新の頻度、並行中の二重入力を防ぐ方法で判断します。一括切り替えは移行日を明確にできますが、切り替え時の影響が集中します。段階的な移行は対象ごとに確かめやすい一方、並行運用のルールと終了条件を事前に決める必要があります。

データの欠損や誤った関連付けをどう見つけますか？

本番移行前に試行し、通常データだけでなく重複、空欄、値の例外、複雑な関連付けを含めて確認します。本番後はレコード件数に加えて、代表レコードの項目値やコンタクト、会社、取引の関連を照合します。差異が見つかった場合は原因と対象範囲を記録し、修正したデータを再度検証します。

移行後にチームへ定着させるにはどうすればよいですか？

利用者が行う業務手順に沿って、レコード確認、登録、ステージ更新、活動履歴の記録を練習します。入力項目は必要な業務判断に使うものに絞り、システム側のルールで入力を支えます。利用状況や質問を見ながら設定とマニュアルを更新し、担当者が変わっても同じ手順で運用できる状態を目指します。

まとめ

CRM移行は、データのコピーではなく、現状分析、データ設計、環境構築、移行テスト、切り替え、定着支援をつなげて進めるプロジェクトです。移行元によってオブジェクトや自動化の構造が異なるため、項目の対応だけでなく、関連付けや業務フローが移行後も機能するかを確かめます。入力項目とルールは必要なものに絞り、段階的に運用を広げることが大切です。

1. 現行CRMの棚卸し ── まずは、現行CRMのオブジェクトと項目を棚卸しするところから始めてください
2. 項目の仕分け ── 業務上必要な項目と移行対象外にする項目を分けます
3. 試行移行 ── 最後に優先度の高いデータでマッピングと試行移行を行います

結果を確認してから対象範囲を広げれば、移行後の業務に合わせて設計を調整できます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• CRM移行のデータ設計完全ガイド｜プロパティマッピング・データクレンジング・移行テストの実践
• SalesforceとHubSpotの連携・併用ガイド｜段階的移行か一括移行か判断する基準
• kintoneからHubSpotへの移行ガイド｜顧客管理・案件管理の移行手順とデータ設計
• Zoho CRMからHubSpotへの移行ガイド｜データ構造の違いと移行手順
• CRM乗り換え完全ガイド｜データ移行からチーム定着まで失敗しない手順