CRMの乗り換えを検討しているなら、まず認識を改めてほしいことがある。データ移行（Data Migration）は「データを運ぶ作業」ではなく、「ビジネス変革のプロジェクト」だ。この違いを軽く見た瞬間に、移行は失敗する。
—
CRMデータ移行が難しい本当の理由
「CSVで書き出してインポートすれば終わり」と思っているなら、それは甘い。実際に移行すべきものは、コンタクトや企業情報だけではない。
移行対象には、エンティティ（コンタクト・企業・案件・チケット）、リレーションシップ（企業と担当者の紐付け、案件と活動の関連）、履歴（メール・電話・ミーティング記録）、権限設定（ユーザーロール・チームアクセス）、そしてワークフローや連携ツールまで含まれる。
ここが落とし穴で、コンタクトレコードひとつを見ても、企業に紐づき、案件に関連し、メール履歴があり、自動化シーケンスが走っている。その関連が一本でも切れた瞬間、「孤立レコード（Orphaned Record）」が生まれ、パイプラインが壊れ、レポートが狂う。
日本のBtoBマーケターに多いのは、「ツールを変えれば自動的に整理される」という誤解だ。実際は逆で、移行前に整えておかないと、新しいCRMに汚れたデータが引き継がれるだけになる。
—
移行前のデータクレンジングが全体を決める
正直に言うと、移行プロジェクトの成否はデータクレンジング（Data Cleansing）の質で8割決まる。移行中や移行後にクレンジングしようとするチームが後を絶たないが、新しいシステムでのデータ修正は旧システムの何倍も手間がかかる。
まずデータ監査（Data Audit）を実施する。各オブジェクト（コンタクト・企業・案件）ごとに、総レコード数、必須項目の入力率、重複レコードの割合、18ヶ月以上活動のないレコード数を把握する。これが移行のベースラインになる。
次に重複排除（Deduplication）と正規化（Normalization）。コンタクトの重複は「メールアドレス完全一致」を起点にするのが安全だ。企業レコードはドメイン単位での重複検出が効く。正規化では電話番号フォーマット、都道府県の表記ゆれ（「東京都」「東京」「Tokyo」）、ライフサイクルステージの定義を統一する。
重複レコードをマージする際は、どちらのフィールド値を残すかを決める「サバイバーシップルール（Survivorship Rule）」を文書化しておく。ルールが曖昧なまま進めると、数千件のマージ判断が担当者の感覚に依存し、新たなデータ品質問題を生む。
—
フィールドマッピングとオブジェクトの移行順序
フィールドマッピング（Field Mapping）は、移行元CRMのフィールドを移行先に対応させる作業だ。ここで頻出するのが3種類の衝突——型の不一致（テキスト型 vs プルダウン型）、フィールドの欠如（移行先に存在しない項目）、命名の違い（「顧客担当者」vs「コンタクトオーナー」）。それぞれについて「変換ロジックを書く」「カスタムプロパティを作成する」「アーカイブする」のいずれかを判断する。
移行の順序は絶対に守ってほしい。親オブジェクトを先に、子オブジェクトを後に移行する。推奨順序はこうなる。
1. ユーザー（所有者割り当ての前提）
2. 企業・アカウント
3. コンタクト（企業と紐づけ）
4. 案件・商談（コンタクト・企業と紐づけ）
5. チケット・サポート案件
6. カスタムオブジェクト
7. 活動記録（メール・電話・ミーティング・タスク）
8. 添付ファイル・ドキュメント
この順序を崩すと、参照先が存在しない孤立レコードが大量発生する。後から修正するのは非常に困難だ。
—
バリデーションとハイパーケアで移行を完結させる
「だいたい合ってそう」はバリデーション（Validation）ではない。検証には4つのレイヤーが必要だ。
レコード数照合：移行元と移行先のオブジェクト別レコード数を突き合わせる。0.1%以上の差異があれば必ず原因を特定する。
サンプルスポットチェック：各オブジェクトから50〜100件をランダム抽出し、フィールド単位で目視比較する。集計では見えない変換エラーがここで浮かぶ。
自動比較スクリプト：大量データ（特に活動記録）は、一意IDで移行元・先を突き合わせるスクリプトを走らせて不一致をフラグする。
ユーザー受入テスト（UAT）：営業担当、マーケティングオペレーション、カスタマーサクセスなど異なる職種のユーザー3〜5名が実際に新CRMを操作し、自分のワークフローが機能することを確認して承認する。この承認がGo/No-Goの判断基準になる。
本番稼働後はハイパーケア（Hypercare）期間を設ける。2〜4週間、専任の担当者（CRM管理者かRevOpsリード）がエラーログを監視し、ユーザー問い合わせに対応する。毎朝15分のスタンドアップを1週間続けるだけで、初動の混乱が大幅に減る。旧CRMはこの期間、必ず読み取り専用（Read-Only）のまま残しておく。ロールバックの保険として機能するからだ。
—
まとめ
CRMデータ移行の本質は、技術作業ではなくビジネス変革の管理だ。クレンジングを先に行い、親オブジェクトから順に移行し、4層のバリデーションを経て本番稼働し、ハイパーケアで定着させる。この流れを省略しないことが、データ負債を積み上げない唯一の方法になる。移行後のCRMが組織の成長を支える基盤になるかどうかは、計画と規律にかかっている。
—
参考：https://blog.hubspot.com/marketing/crm-data-migration
**