CRM移行のデータ設計完全ガイド｜プロパティマッピング・データクレンジング・移行テストの実践

CRM移行プロジェクトの成功は、データ設計の品質で決まります。ツールの選定や機能比較に注目が集まりがちですが、実際に移行プロジェクトが失敗する原因の多くは「データの整備不足」と「プロパティマッピングの不備」にあります。本記事では、CRM移行のデータ設計を「設計→クレンジング→テスト移行」の3ステップに分解し、プロパティマッピングシートの作成方法からテスト移行の実施方法、本番移行のタイムラインまでを実践的に解説します。

CRM移行を経験した企業の多くが、移行後に「データが正しく入っていない」「旧CRMの情報が欠落している」「重複レコードが大量に発生した」といった問題に直面しています。ガートナーの調査によると、CRM移行プロジェクトの約40%がデータ品質の問題で当初の目標を達成できていないとされています。

本記事では、移行元のCRMがSalesforce、Dynamics 365、Zoho CRM、kintone、eセールスマネージャー、スプレッドシートのいずれであっても活用できる、CRM移行のデータ設計の汎用的なフレームワークを解説します。特にHubSpotへの移行を想定した具体例を多く紹介します。

この記事でわかること

• CRM移行のデータ設計における3ステップの全体像
• プロパティマッピングシートの作り方と記載すべき項目
• データクレンジングの具体的なチェックリスト
• テスト移行の計画と実施方法
• 本番移行のタイムライン設計と差分データの扱い方

CRM移行のデータ設計：3ステップの全体像

全体フレームワーク

CRM移行のデータ設計は、以下の3ステップで進めます。

ステップ1：データ設計（1〜2週間）

移行元CRMのデータ構造を棚卸しし、移行先CRMのプロパティにマッピングする。移行対象データの範囲を確定し、プロパティマッピングシートを完成させる。

ステップ2：データクレンジング（1〜2週間）

エクスポートしたデータの品質を改善する。重複排除、表記揺れ統一、無効データの除外、形式変換を行い、インポート可能な状態にする。

ステップ3：テスト移行（1週間）

本番データの一部（10%程度）を使ってテストインポートを実施し、マッピングの正確性とデータの整合性を検証する。問題があれば設計・クレンジングに戻って修正する。

この3ステップを経てから本番移行に進むことで、移行後のデータ品質問題を最小限に抑えられます。テスト移行を省略して本番移行を行うと、大量のデータ修正が発生するリスクが高くなります。

ステップ1：データ設計とプロパティマッピング

移行元データの棚卸し

まず、移行元CRMに存在するすべてのデータ構造を棚卸しします。

棚卸しの対象

• オブジェクト/エンティティ：移行元CRMで管理しているデータの種類（顧客、担当者、案件、活動、商品など）
• フィールド/プロパティ：各オブジェクトに含まれるフィールドの一覧（名前、型、選択肢、必須/任意）
• リレーション：オブジェクト間の関連付け（顧客と担当者、担当者と案件、案件と活動など）
• レコード数：各オブジェクトのレコード数（移行のボリューム見積もりに使用）
• カスタムフィールド：標準フィールド以外に独自に追加したフィールド

棚卸しの実施方法

• 管理画面からフィールド設定の一覧をエクスポートまたはスクリーンショットを取得
• APIのスキーマ情報を取得（Salesforceの場合はDescribe API、HubSpotの場合はProperties APIなど）
• 実際にデータをCSVエクスポートし、カラムヘッダーと値の種類を確認

プロパティマッピングシートの作成

棚卸しの結果を基に、プロパティマッピングシートを作成します。これはCRM移行プロジェクトの最も重要な成果物の一つで、移行の設計書となります。

マッピングシートの推奨カラム構成

スプレッドシート（Googleスプレッドシートまたは Excel）で以下のカラムを持つマッピングシートを作成します。

• 移行元オブジェクト名：移行元CRMのオブジェクト名（例：「取引先」「リード」「商談」）
• 移行元フィールド名：移行元CRMのフィールド名（例：「会社名」「業種」「従業員数」）
• 移行元フィールドタイプ：テキスト、数値、日付、選択肢など
• 移行先オブジェクト名：HubSpotのオブジェクト名（例：「Company」「Contact」「Deal」）
• 移行先プロパティ名：HubSpotのプロパティ名（例：「name」「industry」「numberofemployees」）
• 移行先プロパティタイプ：テキスト、数値、日付、ドロップダウンなど
• 変換ルール：値の変換が必要な場合のルール（例：「業種コード → 業種名に変換」「全角数字 → 半角に変換」）
• 移行判定：移行する（必須）/移行する（任意）/移行しない
• 備考：特記事項（既存プロパティを使用 / カスタムプロパティを新規作成 / 値の選択肢の対応表が別途必要 など）

マッピング時の判断基準

すべてのフィールドを移行する必要はありません。以下の判断基準で移行対象を選定します。

必須移行

• 顧客の基本情報（会社名、氏名、メールアドレス、電話番号）
• 進行中の取引/案件のデータ（金額、ステージ、予定日）
• オプトアウト情報（メール配信停止フラグ）
• コンタクトのオーナー（担当者）情報

推奨移行

• 直近1年分の活動履歴
• リードソース情報
• カスタムフィールドのうち、営業・マーケティングで日常的に使用しているもの
• セグメント情報（リストやタグ）

移行不要の場合が多いもの

• システム自動生成フィールド（作成日時、更新日時は移行先で新たに記録される）
• 使用頻度が低いカスタムフィールド
• 3年以上前の活動履歴（必要に応じて参照用に旧CRMを残す）
• テストデータや無効データ

オブジェクト間のリレーションマッピング

移行元CRMのオブジェクト間リレーション（関連付け）をHubSpotでどう再現するかも設計します。

Salesforceからの移行の場合

Salesforceのオブジェクト構造はHubSpotと類似しており、基本的な対応は以下のとおりです。

• Account → Company
• Contact → Contact
• Opportunity → Deal
• Lead → Contact（ライフサイクルステージ = Lead）
• Activity（Task/Event） → Engagement（Task/Meeting/Call/Note）
• Campaign → Campaign

Salesforceでは「Lead」と「Contact」が別オブジェクトですが、HubSpotでは「Contact」オブジェクトにライフサイクルステージ（Lead/MQL/SQL/Customer等）を設定して管理する設計です。この違いはマッピング時に最も注意が必要なポイントの一つです。

kintoneからの移行の場合

kintoneはアプリ（テーブル）単位でデータを管理するため、各アプリをHubSpotのどのオブジェクトに対応させるかを個別に設計する必要があります。kintoneのルックアップフィールドで構築されたアプリ間の関連は、HubSpotの関連付けに変換します。

選択肢の値の対応表

移行元と移行先でドロップダウンの選択肢が異なる場合、値の対応表を別途作成します。

たとえば、移行元CRMの業種選択肢が「IT」「製造」「金融」「サービス」で、HubSpotの業種プロパティの標準選択肢が異なる場合、どの値をどの選択肢にマッピングするかを明確にします。

HubSpotのドロップダウンプロパティは、移行元の選択肢に合わせてカスタム選択肢を追加できるため、完全一致させることも可能です。

ステップ2：データクレンジング

データクレンジングの目的

データクレンジングの目的は「インポート後のCRMデータ品質を最大化すること」です。旧CRMに蓄積されたデータには、長年の運用で品質が劣化した情報が含まれています。この「ゴミデータ」をそのまま新CRMに移行すると、新しいツールの効果が大幅に低下します。

データクレンジングチェックリスト

以下のチェックリストに沿って、データクレンジングを実施します。

1. 重複レコードの排除

• メールアドレスをキーにしてコンタクトの重複を特定
• 会社名をキーにして会社レコードの重複を特定
• 重複レコードの中で最も情報が充実しているレコードを残し、他はマージまたは削除
• Excelの「条件付き書式 → 重複する値」やGoogleスプレッドシートのCOUNTIF関数で重複を検出

2. 無効メールアドレスの除外

• 形式が不正なメールアドレスの除外（@マークがない、ドメイン部分がない等）
• 明らかに無効なアドレスの除外（test@test.com、xxx@example.com等）
• バウンスリスト（過去にメール配信でバウンスしたアドレス）の除外
• ロールベースアドレス（info@、sales@、support@等）のフラグ付け

3. 表記揺れの統一

• 会社名の正式表記への統一（「株式会社」「(株)」「㈱」→「株式会社」に統一）
• 住所の都道府県名の有無を統一
• 電話番号のフォーマット統一（ハイフン有無、市外局番の表記）
• 全角文字と半角文字の統一（英数字は半角に統一）
• 不要なスペース（前後のスペース、連続スペース）の除去

4. 空白フィールドの処理

• 必須フィールド（メールアドレス、会社名）が空白のレコードへの対応方針を決定
• 空白フィールドが多いレコードの取り扱い（移行するか、しないか）

5. 日付フォーマットの統一

• 日付のフォーマットを統一（YYYY-MM-DD、MM/DD/YYYY等）
• 和暦表記（令和○年）の西暦への変換
• 「2025年3月1日」のような日本語表記の変換

6. 金額データの変換

• 通貨記号（¥、$）の除去
• カンマ区切りの除去
• 税込/税抜の確認と統一
• 小数点以下の桁数の統一

7. オプトアウト情報の保全

• メール配信停止（オプトアウト）フラグが正しく設定されているか確認
• オプトアウトリストの件数を移行元と移行先で照合（1件でも漏れがあると法的リスク）

データクレンジングツール

大量データのクレンジングには、以下のツールが有効です。

• Googleスプレッドシート / Excel：関数（TRIM、SUBSTITUTE、PROPER、VLOOKUP等）を使った基本的なクレンジング
• OpenRefine：大量データの表記揺れ統一、クラスタリングに特化したオープンソースツール
• Python（pandasライブラリ）：プログラム的なデータ変換。正規表現での一括置換、重複排除、結合に強い
• Insycle：HubSpot連携のデータ品質管理ツール。重複検出、一括修正、フォーマット統一に対応

ステップ3：テスト移行

テスト移行の目的

テスト移行は、本番移行前にマッピングとクレンジングの品質を検証するプロセスです。以下の項目を確認します。

• プロパティマッピングが正しいか（値が意図どおりのフィールドに入るか）
• データ型の変換が正しいか（日付、数値、選択肢が正しく反映されるか）
• オブジェクト間の関連付けが正しいか（コンタクトと会社、取引とコンタクトの紐づけ）
• エラーが発生するレコードがないか
• インポート後のレコード数が期待どおりか

テスト移行の手順

ステップ3-1：テストデータの抽出

クレンジング済みの本番データから、テスト用のサンプルデータを抽出します。推奨は全体の10%程度で、以下の条件を含むデータを選びます。

• 基本的なレコード（全フィールドが埋まっている「きれいな」データ）
• 一部フィールドが空白のレコード
• 特殊文字（全角記号、環境依存文字）を含むレコード
• 複数オブジェクトに関連付けがあるレコード
• ドロップダウンのすべての選択肢を含むレコード

ステップ3-2：テスト環境の準備

HubSpotのサンドボックス環境（Enterpriseプランで利用可能）または本番環境の一角をテスト用に使用します。サンドボックスがない場合は、テストデータに「[TEST]」プレフィックスを付けて本番環境にインポートし、テスト完了後に削除する方法もあります。

ステップ3-3：テストインポートの実行

テストデータをHubSpotにインポートし、以下の検証項目をチェックします。

検証チェックリスト

• インポートされたレコード数がテストデータの件数と一致するか
• エラーレポートを確認し、エラーの原因を特定
• 5〜10件のレコードを個別に開き、各プロパティの値が正しいか目視確認
• コンタクトと会社の関連付けが正しく設定されているか
• 取引のパイプラインステージが正しいか
• 日付プロパティの値が正しい日付になっているか（タイムゾーンの影響でずれていないか）
• ドロップダウンプロパティの値が選択肢に一致しているか
• 金額プロパティの値が正しい数値になっているか
• オプトアウトフラグが正しく反映されているか

ステップ3-4：問題の修正と再テスト

テストインポートで発見された問題を修正します。

• マッピングの誤り → プロパティマッピングシートを修正
• クレンジング不足 → クレンジングルールを追加し、データを再処理
• HubSpot側の設定不備 → プロパティの型や選択肢を修正

修正後、再度テストインポートを実施し、問題が解消されたことを確認します。テスト移行は「問題がゼロになるまで繰り返す」のが原則です。

本番移行のタイムライン設計

本番移行の推奨タイムライン

テスト移行が完了したら、本番移行のタイムラインを設計します。以下は一般的な推奨タイムラインです。

移行日の1週間前

• 移行日の確定と社内周知
• HubSpotの本番環境の最終確認（プロパティ、パイプライン、ユーザー権限）
• バックアップの取得（移行元CRMの全データバックアップ）
• 移行手順書の作成（誰が何をどの順序で実行するか）

移行日の前日

• 移行元CRMの最新データをエクスポート（差分データの取得）
• エクスポートデータの最終クレンジング
• 移行元CRMへの新規データ入力を制限（可能であれば）

移行日当日

• 本番データのHubSpotインポート（推奨順序：会社 → コンタクト → 取引 → アクティビティ）
• インポート後の検証（レコード数、データ整合性、関連付け）
• エラーレコードの修正と再インポート
• ユーザーへのHubSpotアクセス開始の案内

移行日の翌日〜1週間

• 並行運用期間の開始（移行元CRMとHubSpotの両方を使用）
• 差分データの確認と追加インポート（移行日〜移行完了日の間に入力されたデータ）
• ユーザーからのフィードバック収集

移行後2〜4週間

• 並行運用の終了判定
• 移行元CRMの参照専用への切り替え
• HubSpot運用の安定化確認

差分データの扱い方

CRM移行で最も注意が必要なポイントの一つが「差分データ」です。データをエクスポートしてからHubSpotにインポートするまでの間にも、営業活動は続いています。この間に発生した新規データや更新データの扱いを事前に計画しておく必要があります。

方法1：移行期間中のデータ入力凍結

週末や祝日など、営業活動が停止するタイミングで移行を実施し、データ入力を一時的に凍結する方法です。最もシンプルですが、営業活動への影響が大きいため、凍結期間は最短（1〜2日）に抑えます。

方法2：差分データの手動追加

移行後に、エクスポート日以降に発生したデータを手動でHubSpotに追加する方法です。差分が少ない場合（数十件程度）に有効です。

方法3：差分データの再エクスポート＋インポート

移行日の直前に「前回エクスポート以降に更新されたレコード」のみを再エクスポートし、HubSpotにインポートする方法です。移行元CRMの「最終更新日」フィルターを使ってエクスポートします。HubSpotのインポートで「既存レコードを更新」オプションを有効にすれば、重複を避けてデータを上書き更新できます。

移行後のデータ品質維持

データガバナンスルールの策定

CRM移行後のデータ品質を維持するために、以下のデータガバナンスルールを策定します。

入力ルール

• 必須プロパティの定義（メールアドレス、会社名、電話番号など）
• 命名規則の統一（取引名のフォーマット、会社名の正式表記ルール）
• データ入力のタイミング（営業活動発生後、当日中に入力）

レビュールール

• 月次のデータ品質レビュー実施
• 重複レコードの定期チェック（HubSpotの重複管理機能を活用）
• 未活動レコードの棚卸し（90日以上アクティビティがない取引の確認）

権限ルール

• プロパティの作成・削除はCRM管理者のみが実施
• 一括削除・一括更新は承認プロセスを経てから実施
• インポート操作は指定されたメンバーのみが実施

HubSpotのデータ品質管理機能

HubSpotには標準でデータ品質管理をサポートする機能があります。

• 重複管理：AIが潜在的な重複レコードを検出し、マージを提案
• プロパティのバリデーション：入力値の形式チェック（メールアドレス形式、数値範囲など）
• ワークフローによる自動クレンジング：電話番号のフォーマット統一や、特定のプロパティ値に基づくレコードの自動更新
• Data Hub（旧Operations Hub）：データ同期、データ品質自動化、プログラマブルオートメーションによる高度なデータ管理

まとめ

CRM移行のデータ設計は「設計→クレンジング→テスト移行」の3ステップで進めます。最も重要な成果物はプロパティマッピングシートで、移行元と移行先のフィールドの対応関係、変換ルール、移行判定を明記します。

データクレンジングでは、重複排除、表記揺れ統一、無効データ除外、オプトアウト情報の保全が必須項目です。テスト移行は本番データの10%で実施し、問題がゼロになるまで繰り返します。

本番移行では差分データの扱いを事前に計画し、並行運用期間を設けて段階的に新CRMに移行します。移行後はデータガバナンスルールを策定し、CRMデータの品質を継続的に維持する体制を構築してください。

データ設計に十分な時間を投資することが、CRM移行プロジェクト全体の成功確率を高める最も効果的な方法です。

よくある質問（FAQ）

プロパティマッピングシートの作成にはどのくらいの時間がかかりますか？

移行元CRMのカスタムフィールド数によりますが、一般的には3〜5営業日が目安です。標準フィールドが中心の場合は1〜2日で完成できますが、カスタムフィールドが50個を超える場合や、選択肢の値の対応表が必要な場合は1週間以上かかることもあります。

テスト移行は何回実施すべきですか？

最低2回の実施を推奨します。1回目でマッピングの誤りやデータ品質の問題を洗い出し、修正後に2回目で問題が解消されたことを確認します。データ構造が複雑な場合は3回以上のテスト移行が必要になることもあります。問題がゼロになるまで繰り返すのが原則です。

移行元CRMのデータはいつまで残しておくべきですか？

並行運用終了後も、最低6ヶ月〜1年は参照専用として旧CRMを維持しておくことを推奨します。移行後に「旧CRMでは参照できたがHubSpotには移行しなかったデータ」が必要になるケースがあるためです。旧CRMの契約更新のタイミングで判断しても遅くありません。

CRM移行のご相談はお気軽にどうぞ

CRM移行のデータ設計は、移行プロジェクト全体の成否を左右する最も重要な工程です。プロパティマッピングの設計からデータクレンジング、テスト移行の実施、本番移行のタイムライン策定まで、データ移行の全プロセスをサポートしています。

移行計画の策定や工数見積もりについて、まずはお気軽にご相談ください。

お問い合わせはこちら

関連記事

• SalesforceからHubSpotへの移行完全ガイド
• Excel顧客管理からHubSpotへの移行ガイド
• IT導入補助金でHubSpotを導入する方法
• HubSpotのCRM機能を徹底解説｜無料で始められるCRM運用の全体像
• HubSpot料金プラン完全比較ガイド2026

カテゴリナビゲーション:

• CRM・バックオフィス連携 — このカテゴリの記事一覧
• BtoBマーケティング — BtoBマーケティングの全カテゴリ
• HubSpot - AI Studio — ブログトップ