%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
CRMデータ移行では、顧客情報を取り込む前に、どの業務で何を使うかを決めます。情報源、項目の意味、レコード同士の関係、切替後の入力先を順に確かめることが、移行後も使えるデータを整える出発点です。
CRMデータ移行では、顧客情報を取り込む前に、どの業務で何を使うかを決めます。情報源、項目の意味、レコード同士の関係、切替後の入力先を順に確かめることが、移行後も使えるデータを整える出発点です。
「Excelの顧客一覧が部署ごとに分かれていて、どれを基準にすればよいかわからない」
「新しいCRMに取り込んだら、会社と担当者の関連が崩れそうで不安」
「移行は終わったのに、営業担当者がスプレッドシートも更新している」
こうした状況では、ファイルをそのまま取り込まず、情報源と利用目的を先に整理します。CRMデータ移行とは、既存システムにある顧客や取引の情報を、新しいCRMの項目と運用に合わせて整え、必要な関連付けを保ちながら移す作業です。
本記事は「CRM導入の進め方完全ガイド｜準備・ツール選定・データ移行・定着化の全ステップ」シリーズの一部です。
移行先をHubSpotにする場合の具体的な画面操作は本記事の各所で扱い、Salesforceからの移行に絞った手順はSalesforceからHubSpotへの移行完全ガイド、移行前に決めるマッピングの考え方はCRM移行のデータ設計にまとめています。
この記事でわかること
既存の表計算ファイルやCRMから移行する担当者に向けて、対象を決めるところから本番切替後の確認までを説明します。各段階で何を照合し、差が出たらどこへ戻るか、次へ進める条件は何かを整理します。HubSpotを移行先とする場合は、インポート前に確認したい公式資料も示します。
- 移行の全体像 — 棚卸し、マッピング、データ整備、テスト、本番切替の順序と、各段階の確認事項がわかります。
- 移行元ごとの進め方 — Excel、旧CRM、基幹システムについて、情報源、識別子、更新方法をどう確認するか整理します。
- 項目とデータの整え方 — 項目の用途、値の変換、重複候補を判断する方法を紹介します。
- 移行後の活用設計 — コンタクト、会社、取引の関係を確かめ、入力ルールやレポートの確認につなげます。
各段階の記録は、移行元の値、採用した判断、確認した担当者、未解決の例外を対応付けて残します。後の検証で差が見つかったときに、抽出、変換、取込、運用のどこへ戻るべきか判断するためです。
移行を5つの工程で進める: 工程ごとの成果物と確認
HubSpotゴールドパートナーとして150社以上のHubSpot支援に携わってきたStartLinkは、データ移行を「データ移行」という1つの作業として切り出さず、導入全体の工程の中に置いています。現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の5つの工程を、最初は範囲を絞ったスモールスタートで回し、運用しながら広げます（HubSpot導入・構築支援、Salesforce→HubSpot移行支援）。次の表は、各工程で残す成果物と、HubSpot側で触る画面の対応です。
| 工程 | 残す成果物 | HubSpotで触る場所 |
|---|---|---|
| 1. 現状の整理・要件定義 | 情報源の一覧、移行する・参照だけ・移行しないの分類、切替後に続ける業務の一覧 | HubSpot外（表計算とヒアリング）。契約中のプランで使える機能の確認 |
| 2. 設計・構築 | マッピング表、識別子の方針、カスタムプロパティ、パイプラインとライフサイクルステージの定義 | 設定（歯車）＞ プロパティ ／ データ管理 ＞ オブジェクト ＞ パイプライン |
| 3. データ移行 | 取り込み用ファイル、取り込み動作の選択、インポート名 | 各オブジェクトの一覧ページ「Import」、またはデータ管理 ＞ データ連携 |
| 4. テスト・検証 | 件数照合、重複・関連付けの確認結果、差の理由の記録 | インポート結果のサマリー、レコード画面、データ管理 ＞ データ品質 |
| 5. 定着・運用改善 | 入力ルール、必須プロパティ、レポートで見る指標、次に広げる範囲 | パイプラインのConditional logic rules、ダッシュボード |
- 現状の整理・要件定義: 移行元の情報源、更新者、同じ顧客を識別する手掛かりを一覧にし、新しい運用で続ける業務から必要なデータを決めます。
- 設計・構築: 移行先のプロパティと関連付けを先に作り、取り込み前に内部名と選択肢の値まで確定します。
- データ移行: まず少量で取り込み、画面で結果を確かめてから本番分を取り込みます。
- テスト・検証: 件数だけでなく、値、関連付け、担当者が実際に試す作業を確認します。
- 定着・運用改善: 切替後の入力先を1つにし、入力率とレポートを見ながら範囲を広げます。
StartLinkは、準委任で伴走しながらこの工程を進め、AI（HubSpotのBreezeやClaude）は、表記ゆれの検出や変換ルールの下書きのように、人が最終確認できる作業に使います。企業様によって最適な形は異なりますので、工程の長さと順番は、データ量と業務の複雑さを見て決めます。
CRMデータ移行は業務設計から始める
最初に、新CRMで続けたい業務を書き出し、それぞれに必要な情報を対応付けます。問い合わせ対応で担当者を探す場合と、商談の引き継ぎで過去の経緯をたどる場合では、必要な項目や履歴が異なります。利用場面を説明できない情報は、移行対象と決める前に管理者へ用途を確認します。
業務ごとに「作業を始めるときに見る情報」「更新する情報」「次の担当者へ渡す情報」を並べると、必要なデータの関係が見えます。たとえば商談の引き継ぎで過去の連絡を確認するなら、活動履歴の本文だけでなく、どのコンタクトや取引に結び付いているかも確認対象です。必要な情報を元データから取り出せると分かった段階で、移行先での表し方を決めます。
ここでの判断は、画面に表示できるかだけで終えません。引き継ぐ担当者に元の情報で作業を試してもらい、必要な値と関連先を特定します。その情報を抽出できない場合は、取得方法を調べるか、旧環境で参照する手順を決めます。参照方法まで決まってから、対象範囲を確定します。
移行時に判断が分かれやすいのは、データの構造、関連付け、履歴、添付ファイルです。次の表を使い、対象ごとに「移す方法を調べる」「旧環境で参照する」「対象から外す」のどの判断が必要かを洗い出します。
| 課題 | 内容 | 対処法 |
|---|---|---|
| オブジェクト構造の違い | CRM間でデータ構造が異なる | 移行元と移行先の項目・関係を対応付け、表せない情報の扱いを決める |
| リレーション（関連）の移行 | コンタクト↔企業↔取引の紐付け | 元レコードを識別する列と関連先を示す列を決め、テストで照合する |
| カスタム項目の移行 | 旧CRMのカスタム項目→新CRMへの対応 | 用途を確認し、必要なら新CRM側の項目を事前に設計する |
| 活動履歴の移行 | メール・電話・訪問等の活動ログ | 種類ごとに取得できるデータと移行方法を確認し、扱えない履歴の参照方法を決める |
| 添付ファイルの移行 | 提案書、契約書等の添付ファイル | 所在、関連レコード、移行先で開けるかを確認する |
| 数式の扱い | Excelの数式を値に置き換えると再計算されなくなる | 計算結果を固定する必要がある列は、元ファイルを複製してから値のみ貼り付ける出典 |
| 基幹システムとの継続連携 | 移行後も両システムのデータ更新が必要 | 対応アプリでは出典を確認し、片方向または双方向の同期を設定する |
CRMデータ移行の各段階で行う作業と成果物を示します。
| フェーズ | 内容 | 標準期間 | 主な成果物 |
|---|---|---|---|
| データ棚卸し | 移行元のレコード、項目、品質を調べる | 移行範囲に応じて設定 | データ棚卸し一覧表 出典 |
| データマッピング | 移行元と移行先の項目や関連付けを対応付ける | 移行範囲に応じて設定 | データマッピング設計書 出典 |
| 本番移行・切替 | 移行元の更新を止め、最終差分を移して件数を照合する | 移行範囲に応じて設定 | 移行結果・件数照合記録 出典 |
成果物は作成しただけで次へ進めず、業務担当者が対象範囲を確認してから使います。棚卸し一覧に情報源の漏れがあれば棚卸しへ戻り、マッピングで意味を説明できない項目があれば定義を確認します。切替時の照合記録には、差がないという結果だけでなく、差がある場合の対象行と扱いも残します。
Excel管理の困りごとを棚卸しする
部門や担当者ごとにシートが分かれている場合は、ファイル名と保存場所に加え、更新する人、更新する場面、参照する人を記録します。同じ顧客が複数の表にあれば、更新履歴と利用目的を比べ、どの表を基準にするか利用者と決めます。
片方の表は連絡先、もう片方は商談の進捗を管理しているなら、ファイル単位で正本を決めるだけでは足りません。項目ごとに、どの情報源の値を採用し、値が食い違う場合は誰が確認するかを記録します。基準が決まらない項目は自動で上書きせず、確認対象として残してから統合用ファイルを作ります。
たとえば連絡先の表と商談の表で会社名が異なる場合は、先に同じ会社を指す根拠を確認します。同じ会社と確認できても、連絡先の値と商談の値のどちらを採るかは項目ごとに判断します。根拠が不足する行は別々に残し、業務担当者が確認できる状態にします。
Excelでは、列名が同じでも値の意味が違うことがあります。たとえば「担当者」が顧客側の担当者なのか、自社の営業担当者なのかは、列名だけでは判断できません。次の表に該当する問題を見つけたら、統合する前にサンプル行と入力者の説明を照合します。
| 課題 | 内容 | 対処法 |
|---|---|---|
| シートの分散 | 部門・担当者ごとに別ファイル | 情報源と更新者を確認してから統合対象を決める |
| 列構造の不統一 | ファイルごとに列の順序や名前が異なる | 列の意味を確認し、移行用の共通形式に対応付ける |
| 自由入力のカオス | 備考欄に構造化されていない情報 | 抽出できる情報と原文のまま残す情報を分ける |
| 数式・参照の消失 | Excel固有の数式が値として固定 | 計算結果を移すか計算の仕組みを作り直すか決め、出力値を照合する |
| 日付形式の混在 | 和暦/西暦、yyyy/mm/dd/mm-dd等の混在 | 元の値を残し、変換規則と判別できない値の扱いを決める |
| 文字コードの問題 | Shift-JIS/UTF-8の不一致で文字化け | 移行先が求める形式を確認し、日本語を含むファイルで表示を試す |
問い合わせ対応、営業引き継ぎ、商談の進捗管理、既存顧客のフォローなど、業務ごとに必要な情報を並べます。表の役割が重なるなら統合を検討します。異なる目的で使われているなら、同じ列名でも別の意味として移行先の項目設計に反映します。
顧客情報を業務の流れに結び付ける
コンタクトを登録した後、所属会社をどう確認し、商談化したときにどの取引へ結び付けるかを決めます。受注後も参照する情報は、誰がどの画面やレポートで使うかまで確かめます。CRM内で扱うデータの種類と関係を確認する際は、HubSpot CRMデータベースの管理も参照できます。
会社が同名で複数ある場合は、会社名だけでコンタクトを結び付けません。元の管理番号や連絡先との組み合わせなど、実際のデータで区別できる手掛かりを確認します。区別できなければ関連付けを保留し、どの業務担当者が判断するか決めます。テストでは、その判断を要する行が意図しない会社に結び付いていないか確認します。
請求情報などを別システムで管理している場合は、CRMで必要な情報と、別システムを基準に扱う情報を分けます。両方に同じ項目があるなら、更新元と確認先を決めます。更新元が未定のまま取り込むと、切替後に異なる値が残っても、どちらを直すべきか判断できません。
入力者の注意に頼らず、運用ルールにする
移行先の項目は、営業活動やレポートで使うものから選びます。各項目について、次を決めます。
- 入力する場面
- 入力する人
- 値を確認する人
取引を次のステージへ進める際に必要な情報なら、何を見て値を確定するかまで手順に書きます。
項目の追加を検討するときは、既存項目で同じ判断ができないか、入力者が値の意味を説明できるかを確認します。値の出所が決まらない項目は作成を保留し、業務側で定義を確かめてから設計へ進みます。
移行直後に空欄が見つかった場合も、直ちに入力漏れと決めません。次の順に調べます。
- 元データに値がないのか
- 変換時に除かれたのか
- 移行先で表示できないのか
原因が分かれば、データ修正と入力手順のどちらが必要かを選べます。
移行範囲とデータを棚卸しする
移行範囲は「移行する」「旧環境で参照する」「移行しない」に分けて検討します。データの種類ごとに利用目的、管理者、切替後に更新が必要かを確認します。判断を保留したものは、理由と確認する担当者を残します。範囲が決まってから、整備とテストの対象を確定します。
判断に迷ったら、切替後の具体的な作業から逆にたどります。新CRMでその情報を更新するなら移行方法を調べます。過去の確認だけに使うなら、必要な人が旧環境で探せるかを試します。利用場面が確認できない場合は、管理者が用途を調べるまで対象の扱いを保留します。
移行対象を利用目的で分類する
顧客、会社、取引、活動履歴、添付ファイルなどを分け、現在の業務で必要かを確認します。進行中の取引のように新CRMで作業を続ける情報は、項目の値だけでなく、会社や担当者との関係も対象として検討します。過去の情報は、誰がどの場面で参照するかを確かめてから扱いを決めます。
過去情報を旧環境で参照する方針なら、閲覧する担当者が切替後も必要な情報へたどり着けるか試します。旧環境を閉じる予定がある場合は、その後の参照先が決まるまで対象外と確定しません。判断の基準はデータの古さだけでなく、業務で必要になる場面と参照方法です。
移行対象が決まったら、元データを移行先の項目へどう表すかを確認します。分割や結合を伴う場合は、変換後の値から元の意味をたどれるかが判断の分かれ目です。
| 課題 | 例 | 対処法 |
|---|---|---|
| 1対多のマッピング | 「住所」→「都道府県」「市区町村」「番地」 | 分割できる形式を定義し、判別できない行は確認対象にする |
| 多対1のマッピング | 「メモ1」「メモ2」→「備考」 | 結合順と区切り方を決め、元の記述を識別できるか確認する |
| 該当項目なし | 移行先CRMに対応項目がない | 用途を確認し、項目の追加、別の保管先、対象外のいずれかを決める |
| データ型の不一致 | テキスト↔数値、和暦↔西暦 | 変換できる条件と例外の扱いを設計書に書き、テストで照合する |
移行方法を決める際は、次の分類ごとに「新CRMで作業するために必要か」を確かめます。旧環境で参照する方針なら、切替後も必要な人がその情報を見られるかを確認してから対象外にします。
| 分類 | 確認すること | 判断の考え方 |
|---|---|---|
| 顧客・会社情報 | 現在の営業やサポートで使うか | 現行業務で使う情報は移行対象として検討する |
| 取引情報 | 商談の継続判断や引き継ぎに必要か | 進行中の取引は関連付けも含めて設計する |
| 活動履歴 | 過去の対応を新CRMから参照する必要があるか | 移行方法を確認し、扱えない履歴は旧環境での参照を検討する |
| 添付ファイル | ファイルの所在や利用者が特定できるか | CRM内に置く必要があるものと別保管するものを分ける |
| 個別管理項目 | 誰が何のために使うか説明できるか | 用途が不明な項目は定義を確認してから決める |
活動履歴や添付ファイルを旧環境に残す場合は、「参照できる」という方針を実際の操作で確かめます。担当者が新CRMの顧客から対象を特定し、必要な履歴やファイルを開けるか試します。たどれなければ、識別に使う情報を移すか、参照手順を見直してから範囲を確定します。
データソースと品質を記録する
部署別のExcel、旧CRM、基幹システムを情報源ごとに一覧化します。各情報源について、管理者、更新方法、項目名、値の形式、同じ顧客を識別する手掛かりを記録します。会社名だけで照合する場合と、ドメインや元システムのレコードIDを使える場合では、関連付けの設計が変わります。
欠損や重複の状況、最終更新日も確認します。移行元ファイルのサイズ、オブジェクト種別ごとのレコード件数と項目数は、抽出条件と一緒に記録します。テスト時と本番時に件数が違えば、対象外にした条件、抽出後の更新、抽出方法の順に照合します。差を説明できない状態では、対象ファイルを確定しません。
件数を比較する際は、情報源ごとに抽出時点、対象期間、絞り込み条件、重複や削除済みレコードの扱いをそろえます。件数が異なる場合は、該当レコードと更新日時を照合し、抽出後の追加・変更・削除による差と移行漏れを分けて記録します。ただし、元システムの更新が続いている間は、件数差だけで移行の成否を判断できません。対象レコードと差の理由を確認してから、テスト結果を評価します。
照合記録には、抽出元、抽出条件、抽出時点、取込対象から外した行、取込時にエラーとなった行を分けて残します。差が抽出後の更新によるものなら、そのレコードを差分として反映するか、再抽出するかを決めます。エラーや対象外の条件では説明できない差が残るなら、抽出手順に戻ります。こうして差の行と処理先が対応してから、値の検証へ進みます。
移行優先度を決める
対象を「移行する」「参照用に残す」「移行しない」に分類します。意見が分かれるデータは、実際に使う担当者に利用場面を聞きます。新CRMで作業を続けるために必要なら移行方法を調べ、過去の確認にだけ使うなら旧環境で参照できるかを確かめます。
判断する人と確認する人を分けておくと、技術的には取り込めても業務では使えない、という見落としを防ぎやすくなります。次の役割は担当を割り当てる際の整理例です。役割を兼ねる場合も、範囲と確認先を明記します。
| 役割 | 責務 | 必要スキル |
|---|---|---|
| 移行PM | 全体管理、スケジュール管理、リスク管理 | プロジェクト管理、CRM知識 |
| データアーキテクト | データマッピング設計、変換ルール策定 | データベース設計、ETL知識 |
| データクレンジング担当 | データ品質の改善、名寄せ処理 | Excel/データ操作スキル |
| 業務部門代表 | データの正確性確認、業務要件の提供 | 業務知識、顧客理解 |
| CRMベンダー/パートナー | 技術支援、インポート設定、動作検証 | CRM製品の専門知識 |
移行方針は、取り込む範囲だけでなく、残したデータを切替後にどう参照するかと合わせて選びます。全件移行を選ぶ前には、使わない情報の整備も必要になるか確認します。対象を絞るなら、旧環境での参照方法を先に決めます。
| 移行方針 | メリット | デメリット | 推奨ケース |
|---|---|---|---|
| 全件移行 | 新CRMから過去の情報も参照できる | 利用しないデータも整備・検証の対象になる | 過去情報を新CRMの業務で使う場合 |
| 期間限定移行 | 利用する範囲に整備と検証を集中できる | 対象外の過去データは別の参照方法が必要 | 古いデータを旧環境で参照できる場合 |
| 段階移行 | 対象ごとに結果を確認してから次へ進める | 切替中の更新元と差分管理を決める必要がある | 情報源や業務ごとに切替を分ける場合 |
方針を比べる際は、新CRMで必要な作業を列挙し、それぞれに必要な情報がどこから得られるかを確かめます。全件移行なら、利用しないデータも含めて値と関連付けを確認できるかが分かれ目です。期間を区切るなら、境界にかかる取引や履歴をどう扱うか決めます。段階移行なら、切替中に更新された情報をどちらで管理し、次の段階へどう渡すか決めてから着手します。
期間を区切る場合、取引の作成時点だけで対象を決めると、対象期間の外にある活動履歴が引き継ぎに必要なことがあります。取引を開いた担当者が経緯を追えるかを確認し、不足する履歴を移すか旧環境で参照するか決めます。段階移行では、先に移した会社へ後からコンタクトや取引を結び付けられる識別子があるかも確認します。
検証も段階を分けます。件数が合っていても値や関連付けが違えば、業務で使えるとは判断できません。各段階で見つかった差を記録し、原因と影響を確認してから次へ進みます。
| 段階 | 時期 | 検証内容 | 判定基準 |
|---|---|---|---|
| 第1段階：定量検証 | 取込結果を確認するとき | 対象件数、必須項目の空欄、重複候補を抽出条件と照合する | 差の内訳と原因を説明でき、対応が必要な行の扱いが決まっている |
| 第2段階：定性検証 | 件数の確認後 | 項目値、コンタクト・会社・取引の関連、活動履歴の参照方法を元データと比べる | 誤った値や関連を修正し、判断が残るものの担当者と扱いが決まっている |
| 第3段階：業務検証 | 切替を判断する前 | 検索、引き継ぎ、取引更新、レポート確認を担当者が試す | 必要な作業を続けられ、止まる作業があれば切替前の対応が決まっている |
最初の対象を絞る場合は、日常業務で使うコンタクト、会社、進行中の取引から検討します。ただし、関連付けに必要な識別子や引き継ぎに欠かせない履歴は、後回しにして業務が止まらないか確認してから判断します。
データマッピングで項目と意味をそろえる
データマッピングでは、移行元の各列を移行先のどの項目へ登録するか決めます。列名が似ていても、入力時の意味や値の形式が異なれば、そのまま対応付けられません。自動で変換できる項目と、人の判断が必要な項目を分けて設計します。
以下は、設計書に記録する項目の例です。例示した対応関係をそのまま採用せず、実際の元データと移行先の項目定義を照合します。特にランクや担当者は、値の意味と対応先を業務担当者に確かめてから変換します。
| # | 移行元項目名 | 移行元データ型 | 移行先項目名 | 移行先データ型 | 変換ルール | 備考 |
|---|---|---|---|---|---|---|
| 1 | 会社名 | テキスト | Company Name | テキスト | 前後の空白を確認して扱いを決める | 空欄の行を確認する |
| 2 | 担当者名 | テキスト | Contact Name | テキスト | 姓名を分割できる条件を決める | 判別できない名前は確認する |
| 3 | TEL | テキスト | Phone | 電話番号として扱う項目 | 区切り記号と内線の扱いを決める | 元の値と照合する |
| 4 | メアド | テキスト | メールアドレスとして扱う項目 | 表記の整備方法を決める | 共有アドレスを確認する | |
| 5 | 売上ランク | A/B/Cなどの値 | Lead Score | 移行先で選ぶ形式 | 元の各値が何を示すか確認して対応付ける | 点数に変える場合は根拠と用途を決める |
| 6 | 最終訪問日 | 日付（和暦） | Last Activity | 移行先で選ぶ日付項目 | 元の日付と変換後の日付を照合する | 項目の意味が一致するか確認する |
| 7 | 備考 | テキスト | Description | テキスト | 残す範囲と分割要否を決める | 取込先の条件を確認する |
| 8 | 担当営業 | テキスト | Owner | 移行先の担当者を識別する値 | 元の氏名と移行先ユーザーを突合する | 対応先がない値を保留する |
この表の「売上ランク」と「Lead Score」のように、名称だけでは意味の一致を判断できない組み合わせがあります。ランクが何を基準に付けられたか分からなければ、点数への変換は保留します。「最終訪問日」も、移行先の項目が同じ出来事の日付を表すか確かめます。意味が異なる場合は、対応先の見直しや別項目での保持を検討します。
マッピングを確定する際は、通常の値だけでなく、空欄、想定外の選択肢、同じ名前の担当者を含む行も見ます。通常の行は変換できても、例外行の扱いが決まらなければ本番用ファイルを作りません。例外行ごとに「確認して変換する」「元の値を保持する」「対象から外す」を決め、判断者を記録します。
次の画面は、デモ環境のインポート画面で、取り込むファイルの列をCRMのプロパティに対応付けている様子です。画面上で列が対応付いていても、値の意味まで一致したとは限りません。テスト後にレコードを開き、設計書に書いた意図どおりの項目へ入ったか確認します。
設計書に移行元と移行先の定義を書く
設計書には、移行元の項目名と意味、値の形式、移行先の項目、変換方法、確認担当者を記録します。移行しない項目や判断を保留する項目には理由を付けます。サンプル値を見た関係者が同じ意味として解釈でき、例外行の扱いも決まったら、テスト用データを作ります。
| 移行元項目 | 意味・形式 | 移行先項目 | 変換・判断 |
|---|---|---|---|
| 会社名 | 文字列。法人格の表記にばらつきがある | 会社名 | 表記を残すか統一するかルールを定める |
| 担当者名 | 姓名が一つの列に入っている場合がある | 姓、名 | 分割できる形式と判断できない行の扱いを決める |
| 電話番号 | 区切り記号や桁表記が混在 | 電話番号 | 表示形式と内線情報の扱いをそろえる |
| 売上ランク | 選択肢または文字列 | ランク用プロパティ | 選択肢の意味と対応関係を定義する |
| 担当営業 | 氏名や旧システムの担当者名 | レコード所有者 | 移行先のユーザーと対応しない値を確認する |
| 備考 | 自由記述 | 備考または別項目 | 残す情報の範囲と分割要否、移行先の文字数制限と超過時の扱いを決める |
| 住所 | 都道府県・市区町村・番地が一つの項目に入っている場合がある | 都道府県、市区町村、番地 | 分割できる条件を決め、判別できない住所は確認する |
| メールアドレス | コンタクトのメールアドレス。テキスト形式 | 表記の整備方法と共有アドレスの扱いを決める | |
| 担当営業名 | 氏名・テキスト | Owner・ユーザーID | 移行先ユーザーと突合し、同名や未登録の担当者を確認する |
担当営業の氏名が同じでも、移行先で別のユーザーを指す可能性があるため、名前だけで所有者を決めません。旧システムの値と移行先ユーザーの対応表を作り、同名、退職者、未登録の担当者を確認対象にします。対応できない値を誰が引き受けるか決まってから、所有者を含むテストを行います。
プロパティは必要なものに絞る
各項目について、誰が入力し、誰がどの判断に使うかを確認します。用途が説明できない場合は、元データの定義と利用者を調べてから採否を決めます。引き継ぎやレポートに必要な項目は、名称に加えて入力例と選択肢の意味も決めます。
カスタムプロパティを作る前に、同じ用途を満たす既存プロパティがあるか確認します。既存項目で対応できない場合は、追加する理由、値の更新元、管理者を設計書に残します。これらが決まっていなければ、テストで値を入れる前に業務側へ確認します。
判断の材料は、項目を作れるかどうかではなく、切替後に値を維持できるかです。利用者が必要でも更新元がない場合は、その項目をいつ、誰が確かめるかを決めます。確認方法が決まらなければ、移行時の値を継続して使う前提にはしません。
HubSpotのインポート仕様に合わせる
HubSpotを移行先にする場合は、作成したファイルの列構成や値の形式をHubSpotインポートファイルの形式と照らし合わせます。設計書上の対応だけで判断せず、実際に取り込むファイルを使って、意図した項目に値が入るか確認します。
コンタクト、会社、取引など複数のオブジェクトを扱う場合は、元レコードと関連先を識別する列を先に決めます。HubSpot複数オブジェクトのインポートを確認し、テスト後に実際のレコードを開いて関係を照合します。誤った会社や取引に結び付いた場合は、識別子の重複、空欄、関連列の値を見直してから本番用ファイルを確定します。
ファイルを準備する担当者と、取込後のレコードを確認する担当者が同じ対応表を使えるようにします。取込結果に問題が出たら、ファイルの列構成、列の値、元レコードとの対応を順に確かめます。原因が特定できた範囲を修正し、同じ条件の行にも問題がないか確認してから先へ進みます。
HubSpotのインポート画面で行う手順
HubSpotへの取り込みは、移行元のファイルをそのまま使わず、次の手順で進めます。画面名はHubSpot公式のインポート手順に沿っています。
- 取り込み用ファイルを作ります。形式は .csv／.xlsx／.xls、シートは1つ、1行目は見出し行で、列数は1,000未満にします。日本語を含む場合は文字コードを UTF-8 にします。日付は日・月・年、月・日・年、年・月・日のいずれかに揃えます（HubSpot公式: インポートファイルの準備）。
- 各オブジェクトの一覧ページ右上の「Import」、または「More」＞ データ管理 ＞ データ連携を開き、「Import data」から取り込み対象のオブジェクトと「Single file」（1ファイルに複数オブジェクト）か「Multiple files」を選びます。
- オブジェクトごとに取り込み動作を選びます。「Create and update」「Create new only」「Update existing only」の3種類です。
- マッピング画面で一意の識別子を設定し、各列の「HubSpot Property」を選びます。取り込まない列は「Import As」で「Don't import column」にします。既存の値を守る項目は「Prevent property overwrite」（Don't overwrite）にします。
- 「Import name」を付け、同意の確認にチェックを入れて「Finish import」を押します。完了後は一覧ページで件数を確認し、エラーは「Download errors as file」で取得します。
| 移行の場面 | 取り込み動作 | ファイルに入れる識別子 |
|---|---|---|
| 移行先がほぼ空の状態で初回取り込み | Create new only | コンタクトはメールアドレス、会社は会社ドメイン名 |
| 初回取り込み後に、元システムの項目を追記 | Update existing only | Record ID（エクスポートで確認）または一意値のカスタムプロパティ |
| 切替までの間に差分を繰り返し取り込む | Create and update | 旧システムのレコードIDを入れた「一意の値を必須」のカスタムプロパティ |
識別子は、移行の品質を決める項目です。HubSpotでは、一意の識別子としてRecord ID、コンタクトのメールアドレス、会社のドメイン名、または一意の値を必須にしたカスタムプロパティを使えます。旧システムのレコードIDを残したいときは、移行先にカスタムプロパティを作り、一意の値を必須にしておくと、差分の再取り込みで重複させずに更新できます（カスタムの一意値プロパティはオブジェクトごとに最大10個）。識別子を入れない行は、既存と照合されず新規レコードとして作成されます。
関連付け（コンタクト↔会社↔取引）を1つのファイルで取り込むときは、各行に両方のレコードの識別子を入れます。1つの会社に複数のコンタクトを結び付けるなら、そのコンタクトの行を複数用意します。識別子がない行は関連付けではなく重複レコードを作る原因になるため、テスト取り込みの後に、会社のレコードを開いて関連するコンタクトと取引が想定どおりに並ぶかを確認します。上限は、有料プランでファイル512MB・1ファイル約104万行、無料ツールでファイル20MB・1日50インポートまでです。
| 取り込みの手段 | 向いている場面 | 注意すること |
|---|---|---|
| インポート（ファイル） | 初回の一括移行、定期的でない追加 | 取り込み動作と識別子の選択が結果を決める。既存のメール・メモ・タスクは更新できない |
| データ同期（Connected Apps） | Kintone・Airtable・Notionなどのアプリと、移行後も同じデータを保ち続けたい場合 | 同期方向（双方向／一方向）とデータ競合ルールを決める。独自の項目マッピングはData Hubの有料プランが必要 |
| API・連携アプリ | 旧システムが継続稼働し、常時つなぐ場合 | 同期の仕様と更新の向きを項目単位で決める。会計とはSync for freee、ナレッジとはSync for Notionのような連携アプリで補える |
データ同期の設定は、設定（歯車）＞ Integrations ＞ Connected Apps で対象アプリを選び「Set up your sync」から行い、同期の状況は「CRM syncs」タブで確認します。画面は、対象データの選択、Configure（方向・項目マッピング・競合解決）、Limit（同期ルール・フィルター）、Review の順に進みます。フィルターは初回に同期する対象だけを絞る設定で、同期された後は項目マッピングに従って同期され続ける点に注意します（HubSpot公式: データ同期）。標準の同期で足りない会計・ナレッジとの連携は、StartLinkが開発元のSync for freee・Sync for Notion、そのほかSyncシリーズで補えます。
データを整え、重複や表記ゆれを扱う
データ整備では、検索、抽出、レポートで同じ意味の値を比較できるようにします。一方、値が似ているだけでレコードを統合すると、別の会社や人を同一扱いする可能性があります。形式の変換と、同一人物・同一会社かどうかの判断を分けます。
棚卸しでは「どの程度の量か」という印象ではなく、実際の抽出条件と確認した結果を記録します。次の表の記録例は記入方法を示すもので、対象データの状態をあらかじめ決めるものではありません。
| 棚卸し項目 | 確認内容 | 記録例 |
|---|---|---|
| データソース | どのシステム/ファイルにデータがあるか | 営業部Excel、旧CRM、名刺管理 |
| オブジェクト種別 | コンタクト、企業、取引、活動などの種別 | 情報源ごとに対象種別を記録する |
| 項目数 | 各オブジェクトのフィールド数 | 抽出ファイルごとに実際の列数を記録する |
| データ品質 | 欠損率、重複率、最終更新日 | 電話番号の空欄と重複候補を別々に記録する |
| データ形式 | CSV、Excel、API、データベースダンプ | Excel（.xlsx）、CSV（UTF-8） |
| データ量 | 件数、ファイルサイズ | 抽出条件、実際の件数、ファイルサイズを記録する |
表記と形式を統一する
会社名、氏名、電話番号、メールアドレス、住所、日付などについて、変換前の値を保管したうえで規則を決めます。規則で処理できない行は推測で補わず、確認対象として取り出します。変換後は、通常の値だけでなく、空欄や複数の解釈ができる値も元データと照合します。
| 項目 | ばらつきの例 | 整備方針 |
|---|---|---|
| 会社名 | 法人格の位置や略記が異なる | 法人格を含めた表記ルールを決める |
| 氏名 | 姓名の順序や空白の有無が異なる | 姓と名の分割条件を定める |
| 電話番号 | 区切り記号の有無が異なる | 表示ルールを選び、内線を別扱いにする |
| 日付 | 和暦や西暦、異なる区切り方が混在 | 変換前後を照合できる形式を使う |
| 選択肢 | 同じ状態を別の言葉で表す | 移行先の選択肢に対応させる |
| Excel数式 | 計算結果を値として移行する | エクスポート前に数式と出力値の扱いを決める |
変換規則を決めたら、元の値、変換後の値、適用した規則を対応付けて確認します。日付を複数の方法で解釈できる行や、住所を分割できない行は例外として取り出します。例外の扱いが決まらないまま一律に変換しないことが、次の重複確認へ進む条件です。
変換後の値だけを残すと、差が見つかったときに原因をたどれません。たとえば日付の解釈が分かれる行は、元の表記を残して入力者に確認します。確認できた行に規則を適用し、同じ規則が別の情報源の値にも使えるか確かめます。情報源によって意味が違えば、規則を分けます。
重複候補を段階的に確認する
まずメールアドレスや電話番号の一致から候補を抽出します。共有アドレスや代表電話が含まれる場合は、それだけで統合を決めません。会社名の表記をそろえて比較する場合も、住所、担当者、過去の取引など別の手掛かりを合わせて確認します。
同じ対象かどうかは、名称だけでなく識別に使う項目と関連する取引・履歴を照合して判断します。統合する場合は、残すレコード、引き継ぐ値、取引や履歴の扱いを決めます。判断できない候補は保留し、元データの管理者に確認します。保留したまま取り込む必要がある場合は、誤った統合や関連付けが起きないかをテストで確認してから進みます。
確認では、次の順に記録します。
- 同一と判断できる根拠
- 食い違う値
- 統合後の関連先
根拠が足りなければ別レコードとして扱う方針を管理者と確認します。統合すると決めた場合も、どちらの値を残すかを項目ごとに決め、取引や履歴が別の顧客へ移らないかテストします。判断待ちの行と確認済みの行を混ぜずに管理すれば、残件が本番切替に影響するか判断できます。
HubSpotでの重複の扱いは、次のとおり、オブジェクトと作成方法で異なります（HubSpot公式: レコードの重複排除）。コンタクトはメールアドレス、会社は会社ドメイン名のプライマリ値で重複排除され、フォーム送信とインポートでは既存レコードが更新されます。一方で、取引・チケット・商品・カスタムオブジェクトは自動では重複排除されず、APIで作成する会社はドメインでは重複排除されません。そのため、取引などは識別子を持たせて取り込む設計にします。
取り込み後に残った重複は、各オブジェクトの一覧ページ右上の「Actions」＞「Manage duplicates」、または「More」＞ データ管理 ＞ データ品質 の「Manage Duplicates」タブで処理します。重複の候補は、コンタクトでは名・姓・メールアドレス・電話番号・会社名など、会社では会社ドメイン名・会社名・電話番号などの比較項目から抽出され、「Review」で統合、「Reject」で重複ではないと確定できます（HubSpot公式: 重複の管理）。統合したレコードは元に戻せないため、取り込み前後にエクスポートで控えを取ってから実行します。重複アラートや書式の自動修正は、Data HubのProfessional以上の機能です。
欠損と不要データを分ける
業務に必要な項目が空欄なら、そのレコードを利用できるか担当者に確認します。値を推測して埋めず、確認待ちと対象外を分けて記録します。テスト用のレコードや用途が不明な情報も、データの管理者に扱いを確認します。
個人情報を含むデータは、利用目的と保持の扱いを社内ルールに照らします。判断がつかないデータは移行対象に含める前に確認します。対象、例外行、確認担当者が決まったところでテスト用ファイルを作ります。
空欄の影響は項目ごとに異なります。検索や連絡に必要な値がなければ、切替後の作業を担当者に試してもらいます。作業できない場合は、元の情報源で確認するか、対象レコードの扱いを決めてからテストへ進みます。作業できる場合も、後で値を確認する担当者と更新先を残します。
テスト移行から本番切替までを段階的に進める
テスト移行では、取り込めた件数だけで合否を決めません。値の意味、レコード同士の関係、担当者が必要な作業を続けられるかを確認します。問題があれば、元データ、変換規則、マッピング、取込手順のどこで生じたかを特定し、修正した範囲を再確認します。
テストデータで処理の流れを確認する
部署や情報源が偏らないようにサンプルを選びます。空欄、表記ゆれ、同名の会社、複数担当者、進行中の取引など、判断が分かれやすいデータも含めます。活動履歴を対象にするなら、種類ごとに元データを取得できるか、移行先でどのレコードに結び付くか、移せない履歴をどこから参照するかを確かめます。
テスト対象は、取り込みやすい行だけで選びません。複数の表に載る顧客、判断を保留した関連付け、旧環境に履歴を残す取引も含めます。各行について期待する値と関連先を先に記録し、取込後の結果と比べます。期待する結果を決められない行は、業務担当者の判断が必要な例外として分けます。
取込後は元データと移行先のレコードを対応付け、次の順で確認します。差があれば原因と対象行を記録し、業務に必要な情報へ影響するか判断します。担当者が検索、引き継ぎ、取引更新を試し、必要な作業を続けられることも本番へ進む条件です。
| 確認項目 | 見るポイント | 問題がある場合 |
|---|---|---|
| レコード数 | 抽出条件をそろえた対象ファイルと取込結果の差 | エラー行、対象外の条件、重複処理の結果を特定する |
| 項目値 | 変換後の値が元の意味を保つか | 元の値と照合し、マッピングや変換ルールを修正する |
| 関連付け | コンタクト、会社、取引が意図した相手に結び付くか | 元レコードの識別子と関連列を見直す |
| 文字と日付 | 文字化けや日付のずれがないか | 元の値と取込結果を比べ、ファイル形式や変換規則を見直す |
| 業務の再現 | 担当者が必要な情報を見つけ、次の作業に進めるか | 項目、権限、関連付け、運用手順を切り分ける |
| 添付ファイル | 対象レコードからファイルを開き、元の内容と照合できるか | 所在、関連先、開けないファイルの扱いを確認する |
検証で差を見つけたら、対象行、元の値、取込後の値、業務への影響、確認担当者を同じ記録に残します。件数差を解消しても、別の会社への誤った関連付けが残れば引き継ぎには使えません。影響する作業を担当者が再実行できることを確かめてから、本番の段取りに進みます。
原因に応じて戻る場所を変えます。元データ自体が違えば情報源の管理者に確認し、変換後だけが違えば変換規則を直します。値は正しいのに表示先が違えばマッピングを、関連先が違えば識別子と関連列を見直します。修正後は問題が出た行に加え、同じ規則を適用した行も確認します。
テスト取り込みで出やすいエラーと直し方
テスト取り込みは、マッピング画面のエラー件数表示（「x errors」の形式のリンク）で確認でき、取り込み後は「Import errors」セクションから「Download errors as file」でダウンロードできます（HubSpot公式: インポートエラーの対処）。
| エラー表示（英語名） | 原因 | 直し方 |
|---|---|---|
| Could not parse date | 日付形式が、選んだ形式と合わない（日と月の入れ替わりなど） | 日付形式の設定を確認し、和暦や混在表記を西暦に統一して再取り込み |
| Invalid enumeration option | ドロップダウン等にない値（例: 「A」「Ａ」の全角半角差） | ファイルの値を既存の選択肢に合わせるか、選択肢を追加 |
| Failed validation（メール、ステージ、パイプライン） | メール形式が不正、またはステージ・パイプライン名がHubSpotに存在しない | 取り込む前にパイプラインとステージを作成し、名称を一致させる |
| Could not find owner / Multiple owners found | 担当者が存在しない、または同名ユーザーが複数いる | 担当者の列をメールアドレスで指定し、退職者はユーザーを再有効化するか別の担当者に置き換える |
| Duplicate unique property value | 一意であるべき値（メール、旧システムID）がファイル内で重複 | 重複行を整理するか、識別子を別の列に変えて再取り込み |
同じ値でも、「担当営業」は氏名ではなくメールアドレスで渡すなど、HubSpotが判別できる形に直しておくと、本番でのエラーが減ります。
本番移行の段取りを決める
本番前に、次を記録します。
- 作業責任者
- 対象データ
- 旧システムへの入力停止の有無
- バックアップ
- 実行順序
- 問題時の戻し方
旧システムで更新を続ける場合は、移行用データを抽出した後の変更を誰が把握し、新CRMへどう反映するか決めます。差分を追えないなら、入力を止める範囲や抽出のやり直し方を検討します。
取り込みはデータの関係を踏まえた順序で進めます。取込結果に差があれば、合意済みの対象外レコード、エラー行、移行中の更新と照合します。差の理由を説明できず、現場の作業に影響する場合は切替を保留します。理由が特定でき、対応する担当者と方法が決まったら、業務担当者と切替可否を判断します。
切替判断に使う記録には、最終抽出の条件、取込結果、未反映の変更、未解決の例外、現場で試した作業をまとめます。未解決の例外があっても、担当者、確認方法、業務への影響が明らかなら、その扱いを業務側と判断できます。影響を確認できない例外は、切替後の対応に回す前に調べます。
移行PMは進捗と問題への対応を関係者と共有します。設定やインポートの確認に技術支援が必要なら、CRMベンダーやパートナーの担当範囲を事前に決めます。基幹システムからデータを扱う場合は、抽出方法と更新の続き方を確認し、必要に応じて対象を分けた移行を検討します。移行中のデータの暗号化とアクセス権限も、社内の管理方針に沿って確認します。
対象を分けて移行する場合は、分け方と実行順序を関連付けに合わせて決めます。各段階で件数、値、関連先を確認し、差の原因と次の段階への影響を判断してから進みます。前の段階で作成したレコードを後の段階で参照するなら、その識別方法も先に確かめます。
並行運用中の入力先を一つにする
並行運用を行う場合は、新CRMと旧システムのどちらへ入力するかを業務ごとに決め、担当者に共有します。旧システムを参照用にするなら、修正依頼の受付先と、新CRMへ反映する人も決めます。同じ情報を両方で更新する必要がある場合は、どちらを基準に照合するかを先に定めます。
入力先を決めるときは、顧客情報の修正、取引の進捗更新、過去履歴の参照を別々に確認します。顧客情報は新CRMで更新し、過去履歴は旧環境で参照するなど、作業ごとに扱いが異なる場合があります。担当者が迷う作業は、修正依頼をどこへ出すかまで手順に書き、実際に操作して確かめます。
切替後は、次を現場で確認します。
- 顧客情報を探せるか
- 取引を次の段階へ進められるか
- 必要なレポートを見られるか
作業が止まる場合は、操作説明だけで済ませず、項目、権限、関連付け、手順のどこに原因があるかを調べます。原因を直した後、止まっていた作業を担当者が再実行できることまで確かめます。
移行後に営業プロセスへ定着させる
移行後は、登録された情報が日常の判断に使われ、更新が続くかを確認します。現場の操作とレポートの両方を見て、足りない情報や使われない項目を洗い出します。変更の要望が出たら、どの作業で困ったかを確認し、データ修正、項目設計、運用手順のどれを見直すか決めます。
検証結果を「おおむね一致」で済ませると、残った差が業務に影響するか判断できません。次の表では差を見つけた後の記録と確認先を明確にします。
| チェック項目 | 確認内容 | 判定基準 |
|---|---|---|
| レコード数の一致 | 同じ抽出条件で移行元と移行先の件数を比べる | 差の対象行と理由を説明でき、未解決分の扱いが決まっている |
| 項目値の正確性 | 元の値と変換後の値を対応付けて確認する | 意味が異なる値を修正し、判断待ちの値を記録している |
| リレーションの整合性 | コンタクト↔企業↔取引の紐付けが正しいか | 元レコードの識別子と関連先を照合し、誤った関係を修正している |
| 文字化けの有無 | 日本語、特殊文字が正しく表示されるか | 対象の値を元データと比べ、表示できない文字の扱いが決まっている |
| 日付の正確性 | 日付データが正しく変換されているか | 元の日付と照合し、解釈できない値を確認対象にしている |
| ファイルの整合性 | 添付ファイルを関連レコードから開けるか | 確認対象のファイルを元の内容と照合し、開けないものの扱いが決まっている |
切替後に見つかる差も、移行時の差と同じ記録につなげます。対象レコード、発見した作業、元の情報源、修正担当者を記録すれば、個別のデータ修正で済むのか、同じ条件の行や入力手順を見直すべきか判断できます。
コンタクトから取引、顧客対応へつなげる
問い合わせを受けたコンタクト、所属する会社、商談を管理する取引の関係を確認します。テストで使った組み合わせだけでなく、同名の会社や複数の取引を持つ顧客も確認対象に含めます。担当者が顧客との経緯をたどれない場合は、情報がないのか、関連付けが違うのか、表示や権限の問題なのかを切り分けます。
請求や会計の情報については、CRMで参照・更新する範囲と、別の基幹システムで管理する範囲を決めます。基幹システムで更新が続く情報をCRMでも使う場合は、更新元、反映方法、差が出たときの確認先を定めます。APIやETLツールを検討するときも、まずどの値をいつ確認する必要があるかを業務側と合わせます。
基幹システムで管理する商品・顧客マスタをCRMの顧客情報と照合し、差異の確認方法と同期の仕組みを定めます。どちらの値を基準にするかが決まらない項目は、反映方法を選ぶ前に管理者へ確認します。
移行後の入力漏れは、パイプライン設定のステージ行にある「Conditional logic rules」列にカーソルを合わせ、「Add rule」から必須のプロパティを追加して防ぎます。依存させるプロパティを選んで「Required」をオンにし、「Save logic」で保存すると、そのステージへ移動するときや手動でレコードを作成するときに入力欄が表示されます。先にプロパティを作成しておくことと、「プロパティ設定の編集」権限が必要です。移行で取り込んだ取引は、この必須入力の対象になる前の値が空のこともあるため、取り込み後に、取引ステージごとの空欄を一覧ビューで確認します（HubSpot公式: パイプラインの設定）。導入全般の定着の進め方はHubSpot導入・活用・定着ガイド、失敗しやすい点はHubSpot導入の失敗パターンと回避策で整理しています。
入力漏れを仕組みで減らす
取引ステージごとの確認情報、所有者の変更方法、更新のタイミングを一つの手順にまとめます。入力漏れが見つかったら、最初に値を確認できる情報源があるか調べます。情報源があるのに入力されないなら、入力する場面と担当者を見直します。そのうえで、CRM上の案内や項目設定が必要かを判断します。
レポートで移行前後の数字を比べる際は、対象範囲、項目の定義、集計する時点をそろえます。差が出たら、対象外レコード、重複、関連付け、ステージ定義、更新時点を確認します。原因がデータにあれば対象レコードを修正し、入力方法にあれば手順を直します。修正後に同じ条件でレポートを見直し、差の説明ができる状態にします。
レポートの差を調べるときは、表示された結果だけでなく、その結果に含まれるレコードを確認します。対象範囲の違いなら集計条件をそろえ、ステージの意味が違うなら対応関係を見直します。担当者が入力していない値が原因なら、どの作業で入力できるかを手順に反映します。
利用状況を見ながら拡張する
運用開始後は、使われる項目と使われない項目、旧環境に残したデータへの参照が必要かを確認します。追加要望があれば、利用者、利用場面、必要な判断を聞き、既存の項目やレポートで対応できるかを検討します。
活動履歴、添付ファイル、顧客マスター、取引データは、種類ごとに更新元と参照先を確認します。対象を広げる場合も、用途を決め、テストで値、関連付け、業務の流れを確かめてから運用へ加えます。
旧環境への参照が繰り返し必要になる情報は、どの作業で使うかを記録します。新CRMに移す判断をする際は、その情報を取得できるか、既存レコードと結び付けられるか、更新元を決められるかを順に確かめます。いずれかが未定なら、参照手順を維持しながら設計を見直します。
よくある質問
この節の要点は次のとおりです。
- 進め方 ── 情報源、管理者、利用する業務の一覧から始め、新CRMで作業を続ける情報と旧環境で参照する情報を分けます。
- 取り込み前の確認 ── 列と項目の意味、値の形式、重複、会社と担当者の関連付けを、実際のレコードで照合します。
- 履歴と項目の扱い ── 活動履歴や添付ファイルは種類ごとに扱いを確認し、移行対象の項目は用途から絞ります。
CRMデータ移行はどこから始めればよいですか？
顧客情報を管理しているファイルやシステム、管理者、利用する業務を一覧にするところから始めます。次に、新CRMで作業を続ける情報と、旧環境で参照する情報を分けます。判断が分かれた情報は利用者に用途を確認します。対象が決まったら、項目の意味と関連付けに使う識別子を設計します。
Excelの顧客リストをそのままCRMに取り込めますか？
ファイル形式が合っていても、列と項目の意味、値の形式、重複、会社と担当者の関連付けを確認する必要があります。まず更新の基準になるファイルを決め、列ごとに用途を確認します。意味を判断できない列は利用者に確認し、サンプルを取り込んで値と関連付けを照合してから本番へ進みます。
会社と担当者の関連付けはどう確認しますか？
会社とコンタクトを識別する列に加え、どの会社へ結び付けるかを示す元データを確認します。テスト移行後に実際のレコードを開き、元の会社と担当者の組み合わせを照合します。誤った会社に結び付く場合は、識別子の重複や空欄、関連列の値を調べます。判断できない組み合わせは保留し、元データの管理者に確認します。
活動履歴や添付ファイルも移行できますか？
移行元から取得できるデータと、移行先で扱う方法を種類ごとに確認します。活動履歴は、内容だけでなく日時や関連するコンタクト・取引をどう確かめるか決めます。HubSpot複数オブジェクトのインポートを参照する場合も、対象の活動を想定した方法で扱えるかを確認し、テストデータで表示と関連付けを確かめます。扱えない履歴は、旧システムで誰がどう参照するか決めます。
添付ファイルは、移行先での扱い方を確認し、テストでは関連レコードからファイルを開いて元の内容と照合します。移さないファイルについても、所在と参照方法を残します。
添付ファイルのサイズ制限を移行前に確認します。制限に合わないファイルがあれば、別の保管先と、担当者が関連レコードからそのファイルを特定する方法を決めます。
移行対象の項目はどう絞ればよいですか？
その項目を誰が入力し、どの業務や判断で使うかを確認します。用途が分からない場合は、元データの定義と利用者を調べます。必要性が確認できた項目から設計し、値の更新元と例外時の確認先も決めます。運用後の追加要望は、具体的な利用場面を聞き、既存項目で対応できるかを見てから判断します。
まとめ
CRMデータ移行は、情報源と利用目的の棚卸しから始め、項目の意味、値の変換、関連付けを設計して進めます。テストでは件数に加えて元の値と関連先を照合し、現場の作業を再現します。差の原因と扱いが決まってから本番切替を判断し、切替後も入力先と更新ルールを見直します。
まずは、移行元の一覧と利用目的の棚卸しから始めてください。
- 移行元ごとにデータの種類、管理者、更新方法を整理します。
- 新CRMで作業する情報と、旧環境で参照する情報を分けます。
- 移行先の項目、識別子、関連付けのルールを設計します。
- テストで値、関連付け、業務の流れを確認し、差の扱いを決めてから本番へ進みます。
棚卸しで用途が決まらなければ利用者に戻り、項目の意味が決まらなければ元データの管理者に確認します。テストで差が出たら対象行と原因を記録し、修正した作業を現場で再実行します。この順序で、次へ進む判断に必要な情報をそろえられます。
企業様によって最適な形は異なります。移行対象や切替方法に迷う場合は、現在の情報源と業務で必要な使い方を整理したうえで検討してください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
