CRM移行ガイド：ディスカバリーから安定化までの5フェーズ

CRM移行は、ほぼ必ず「強制イベント」です。Salesforceの更新が2四半期先に迫り、提示された見積もりは昨年の3倍、経営陣は月末までにHubSpotへの乗り換え提案を見たいと言っている——。計画を丁寧に詰めれば、切替は週末で終わります。逆に行き当たりばったりで進めると、最も見たくないタイミングでパイプラインの可視性を失います。

この記事では、CRM移行の全体像を、意思決定のチェックポイントからデータ準備、切替、そしてCRMがネイティブにカバーしないバックオフィス領域まで順を追って解説します。想定読者はSalesforce→HubSpot移行を進めるRevOpsリードですが、他のCRM乗り換えにも同じ型が使えます。

移行そのものを決めかねている段階であれば、先にCRMの選び方を読んでください。本記事は「移行する」と決めた後のガイドです。

5フェーズの移行プラン

成功する移行は、ほぼ例外なく次の流れをたどります。

中堅規模で合計10〜16週。ディスカバリーを省くとビルドで必ず遅延します。安定化を省くとユーザーが離れ、結局2つのCRMが並立します。

フェーズ1：ディスカバリー

移行先に触れる前に、移行元に何があるかを文書化します。戦術的なチェックリストは移行前監査ガイドにまとめてあるので、ここでは戦略的な観点を扱います。

4つの棚卸し

1. オブジェクト：標準オブジェクト（連絡先、会社、取引、チケット）のうち実際に使われているのはどれか。カスタムオブジェクトで業務に組み込まれているものはどれか。アクティブレコードが50件未満のものは事実上放置されています。
2. フィールド：すべてのプロパティ、型、使用率。利用率5%未満のフィールドは、移行対象ではなく削除対象の候補です。
3. ワークフロー：すべての自動化、そのトリガー、下流への影響範囲。ワークフローの「腐敗」は移行を頓挫させる最大要因です。5年運用すれば400本は溜まっています。
4. 連携：CRMとの間でデータをやり取りしているすべてのシステム。マーケティングオートメーション、請求、サポート、BIウェアハウス、分析、エンリッチメント——それぞれが切替タスクになります。

利用マトリクス

各オブジェクト・各フィールドを次の3軸で評価します。

• 重要度：これがないと業務が止まるか
• ボリューム：レコード数、更新頻度
• オーナー：実質的に保守している人

これが優先順位です。高／高／名前付きオーナーが揃う項目は初日に移行。それ以外はフェーズ2のバックログへ。

フェーズ2：デザイン

スキーマ・マッピング

マッピング表を1枚作ります。1行＝1フィールド、5列構成：

現実が現れるのは「変換ロジック」列です。Salesforceの400値もあるピックリストは統合が必要。HubSpotに式フィールドは同じ形で存在しない。多通貨の金額は正規化が要ります。まず日本語で書き、次にコードにします。

移行ツールの選定

選択肢は大きく4つ。

1. ネイティブインポート：HubSpotへのCSVアップロード。1万件未満・単純スキーマ向け。無料だが壊れやすい。
2. iPaaS（Workato、Zapier、Tray）：GUI主体のETL。中小向け。件数が増えると高コスト。
3. 専用移行ツール（Import2、Trujay、Funnel）：標準オブジェクトに強い。カスタムスキーマは苦手。
4. コード：両APIに対するPythonスクリプト。自由度最大・工数最大。複雑な業務ロジックがある場合はこれ一択。

ホットパス（連絡先、会社、取引）はコード、ロングテールはネイティブインポート、という組み合わせがおすすめです。

切替戦略

• ビッグバン：1週末で全切替。低コスト・高リスク。100ユーザー未満向け。
• 並走：新旧両方を4〜8週間並行稼働。高コスト・低リスク。規制業界や500ユーザー超のチーム向け。
• 段階移行：部署単位で順次。部署間でパイプラインを共有していない場合のみ成立。

フェーズ3：ビルド

ロード順序を守る

依存関係が大事です。取引を会社より先にロードすると関連付けが壊れます。

# 正しいロード順
LOAD_ORDER = [
    "companies",      # 依存なし
    "contacts",       # 会社に関連付け
    "deals",          # 連絡先と会社に関連付け
    "line_items",     # 取引と商品に関連付け
    "tickets",        # 連絡先と会社に関連付け
    "notes",          # 上記すべてに関連付け
    "activities",     # 上記すべてに関連付け
]

最初はテストモードで投入します。HubSpotのインポートにステージング用プロパティをタグ付けしておけば、問題発生時に一括削除できます。

ワークフローは移植ではなく再構築

Salesforceのプロセスビルダーを1対1でHubSpotに作り直すのは避けます。多くは役目を終えた「遺物」です。ルールのオーナーに「これは今も必要ですか」と聞いてください。半分は「不要」と返ってきます。

ヒアリングを通過したものだけをHubSpotのネイティブ構文で書き直します。この工程で、「最初から動いていなかった自動化」も発見できます。

バックオフィスの空白を埋める

移行がラストワンマイルで失敗するのはここです。HubSpotはファネル上流には優れていますが、次の領域はネイティブでは弱い、あるいは機能がありません。

• CPQ：明細行、構成品、承認ルーティング
• 請求：複数事業体の請求、使用量課金、収益認識
• 在庫：物販がある企業
• 購買：発注書、仕入先管理
• 多通貨：基本換算を超える要件

Salesforceは（価格と引き換えに）Revenue Cloud、CPQ、サードパーティアプリでこれを埋めています。HubSpotはネイティブには埋めません。切替後に慌てるのではなく、切替前に計画してください。Sankaはこの領域を埋めるバックオフィス・レイヤーで、請求、在庫、CPQ、収益オペレーションをHubSpot／Salesforceのネイティブ体験として追加します。

フェーズ4：カットオーバー

フェーズ3が終わっていれば、切替そのものは1週末で完了します。標準チェックリスト：

• 金曜EOD：移行元を書込み凍結。全員に告知。
• 金曜夜：最終差分同期。最後のフルロード以降に更新されたレコードを移行。
• 土曜：検証。レコード件数、関連付け件数、フィールド充足率をスポットチェック。
• 日曜：連携切替。マーケ、請求、サポートを新CRM側へ。
• 月曜朝：ユーザーがログインし、不具合を発見し、チケットを投げる。

月曜朝のバグ報告は正常です。初週で30〜80件は想定してください。管理者個人の受信箱ではなく、指名されたオンコールでトリアージします。

フェーズ5：安定化

切替後の4週間が真の勝負です。次のような問題が出てきます。

• 移行しなかったフィールドに依存していたレポート
• 移行元のルールを無効化し忘れて二重発火する自動化
• BIウェアハウスがまだSalesforceを見ていてゼロ件表示になるダッシュボード
• 新UIを嫌がり「しばらくSalesforceを使う」と言い出すユーザー

最後の項目は正面から対処します。切替後2週間を「移行元はリードオンリー」とする境界線にしてください。放置すると真正性が2つに分裂し、移行は失敗したことになります。

よくある失敗パターン

1. カスタムオブジェクトの過小評価：「データ部分は2週間」と見積もり、8万件・循環依存のあるカスタムオブジェクトを6本発見する。
2. 連携の棚卸し漏れ：BIチームが「ダッシュボードが更新されない」と気づいて移行の事後に発覚。
3. 死んだワークフローのコピー：旧CRMの技術的負債をそのまま持ち込む。移植ではなく白紙スタートを。
4. バックオフィスの空白を無視：HubSpotはCRM用途では動くが、請求・在庫は別途計画が必要。
5. 切替凍結なし：最終差分同期の間もユーザーが移行元に書き込み、1日分の更新を失う。

今週やるべきこと

移行まで6ヶ月を切っているなら：

1. 4つの棚卸し（フェーズ1）を完了させる。
2. フィールド・マッピング表を書き始める。
3. バックオフィスの空白を洗い出し、埋め方をスコープする。
4. 切替戦略を決め、日付を確定する。

すでにフェーズ3〜4にいるなら、フェーズ5の指名オンコールと、移行元の書込み凍結日を必ず決めてください。

戦術的な事前監査はHubSpot移行前監査チェックリスト、バックオフィス領域のスコープ支援はSankaの移行サービスを参照してください。