CRM移行: データを失わずにCRMを切り替える方法

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
CRM移行は、営業やオペレーションのチームが手がけるプロジェクトの中でも最もリスクが高いものの一つであり、大半のチームは移行が始まってからようやくその規模の大きさに気づきます。このガイドは、それをきれいに乗り切るための具体的な計画を示します。
CRM移行がうまくいかない理由
重要ポイント: CRM移行
- CRMの失敗率は全体で55%に上り、データ品質の低さと部門横断的なオーナーシップの欠如が主な原因として挙げられています。
- B2Bの連絡先データは年間25~30%の割合で劣化していきます。つまり6か月の移行スケジュールでは、切り替え(カットオーバー)を迎える前にレコードの4分の1が劣化してしまう計算になります。
- データ移行プロジェクトの83%が予定期間を超過するか、完全に失敗しています。原因はたいてい、範囲の見積もりが甘く、テストが省略されることです。
CRMの切り替えが失敗する原因は、予測可能な5つのパターンのいずれかにほぼ集約されます。
フィールドの欠落。 移行元のCRMに、移行先のスキーマにきれいにマッピングできないカスタムフィールドがある。チームはツールが自動でうまく処理してくれると思い込みますが、そうはなりません。それらのフィールドは黙ってスキップされるか、実質的に使い物にならない何でも入れ用のメモ欄に放り込まれます。
壊れたオブジェクトの関係性。 連絡先とアカウントの紐付け、アカウントと案件の紐付け、案件と活動の紐付けは、外部キー参照として保存されています。単純なCSVのエクスポート・インポートは、これらすべての関係を壊してしまいます。結果として、行数だけ見れば正常に見えても、UI上ではつながりを失った孤立レコードが大量に生まれます。
重複レコード。 どのCRMも時間とともに重複が蓄積します。移行はその負荷テストのようなもので、同じ会社の2つのレコードが2つの別々のアカウントとしてインポートされ、チームはその後6か月をかけて移行が生み出した混乱を片付けることになります。
活動履歴の消失。 メール、通話記録、メモ、会議のログは、きれいにエクスポートされない別のオブジェクトタイプに保存されていることが多いです。多くのチームは移行後になって、過去のやり取りの文脈がすべて失われていたことに気づきます。これは単に不便というだけでなく、規制業種にとってはコンプライアンス上のリスクにもなります。
自動化の破損。 ワークフロー、シーケンス、リード割り当てルール、スコアリングモデルはすべて設定情報であり、データではありません。これらは移行されません。新システムでゼロから作り直す必要があり、移行を始める前に文書化していなければ、その半分を見落とすことになります。
移行前に計画しておくべきこと
移行するものの完全な棚卸しをせずに移行を始めてはいけません。以下の表は、エクスポートボタンを押す前に、各オブジェクトタイプごとに答えておくべき質問をまとめたものです。
| オブジェクトタイプ | エクスポート前に答えておくべき質問 |
|---|---|
| 連絡先 | 総数はいくつか。重複はあるか。使用中のカスタムフィールドは何か |
| アカウント/企業 | アカウントの階層(親子関係)はあるか。カスタムフィールドは。紐付いた連絡先は無傷か |
| 案件/商談 | パイプラインのステージは移行先と1対1で対応するか。カスタムフィールドは。成約金額は正確か |
| 活動履歴 | メール、通話、メモは何が保存されているか。どこまで遡る必要があるか。添付ファイルは含まれるか |
| カスタムフィールド | オブジェクトごとのカスタムフィールドの全リスト。今も使われているものと、レガシーな不要品はどれか |
| ユーザーとオーナー | 現在のユーザー一覧。退職した担当者のレコードで再割り当てが必要なものはあるか |
| 連携 | 現在CRMに接続しているツールは何か(メール、マーケティングオートメーション、サポート、ERP)。それぞれ再接続が必要になる |
| 自動化とワークフロー | すべてのルール、シーケンス、割り当てロジックの完全な文書化 |
| 添付ファイルと文書 | レコードに添付されたファイル。ほとんどのインポートツールはこれらを完全にスキップする。別のワークストリームとして計画すること |
移行後ではなく、移行前にデータを整理してください。 汚れたデータを移行しても、問題を新しい場所に移すだけです。エクスポート前に、重複排除のパスを実行し(ほとんどのCRMには組み込みのマージツールがあります。Dedupelyのようなツールも使えます)、フィールド形式を統一し(電話番号、国コード、日付形式)、24か月以上触られていないレコードをアーカイブまたは削除してください。より小さく、よりきれいなデータセットの方が、速く、エラーも少なく移行できます。
自動化は今すぐ文書化してください。 現在のCRMにあるすべてのワークフロー、シーケンス、リードルーティングルール、スコアリングモデルを確認し、平易な言葉で書き出してください。これが移行先システムでそれらを再構築する際に使う文書になり、移行後に何も見落としがなかったかを確認するQAチェックリストにもなります。
まだ移行先のCRMを決めかねているなら、移行計画に入る前にCRM評価基準チェックリストとCRMの選び方から始めるのが適切です。
段階的なCRM移行計画
フェーズ1: 監査と範囲の確定
現在のCRMから、オブジェクトタイプごとの完全なレコード数を取得します。サンプル(オブジェクトごとに100~200件)をエクスポートし、スプレッドシートで開きます。すべてのフィールドを移行先の対応するフィールドにマッピングします。きれいに対応しないフィールドにはフラグを立てます。この監査結果が移行仕様書になります。
今のうちに、実施可否の判断基準を定めておきましょう。成功した移行とはどんな状態か、どの程度のレコード数の誤差なら許容できるか。誰かがボタンを押し始める前に、これに合意しておいてください。
フェーズ2: フィールドをマッピングする
フィールドマッピング文書を作成します。移行元のフィールド名、移行元のフィールドタイプ、移行先のフィールド名、移行先のフィールドタイプ、そして変換が必要な項目のための備考欄です。特に以下の点に注意してください。
- 選択肢が完全には一致しないピックリスト/ドロップダウンフィールド
- 複数選択フィールド(多くのインポートツールがうまく処理できない)
- 地域によって形式が異なる日付フィールド
- 自由記述フィールドが構造化フィールドに分割される場合(またはその逆)
この文書はロールバック時の参照資料にもなります。移行を元に戻す必要がある場合、データがどう変換されたかを正確に知る必要があります。
フェーズ3: データを整理し、重複を排除する
重複排除のパスを実行します。電話番号や住所の形式を統一します。古いレコードを削除またはアーカイブします。移行元のCRMがタグ付けに対応しているなら、移行対象のレコードにタグを付けて、エクスポートを正確に絞り込めるようにしてください。
フェーズ4: 移行方法を選ぶ
下記の「移行アプローチ一覧」セクションを参照してください。選択はレコード数、データの複雑さ、利用可能な技術リソースによって決まります。ほとんどのミッドマーケットのチームは、ガイド付きのサードパーティツールか、ベンダー支援によるオンボーディングのいずれかに落ち着きます。
フェーズ5: サンドボックスでテストする
主要なCRM(Salesforce、HubSpot、Dynamics、Pipedrive)はいずれもサンドボックスまたはトライアル環境を提供しています。まずサンドボックスに移行全体を実行してください。以下を確認します。
- レコード数が一致しているか(移行元と移行先、オブジェクトごと)
- 関係性が無傷か(連絡先が正しいアカウントに紐付いたままか)
- カスタムフィールドが正しく入力されているか
- 想定外の重複が作られていないか
- オーナーの割り当てが正しいか
フェーズ6: 本番データでのリハーサル
現在の本番データの最新エクスポートを使って、もう一度移行を実行します。これにより、初回のデータ整理から今日までの間に生じた変更が明らかになります。差異を修正してください。セールスオペレーションのリーダーと、CRMを使う各チームから少なくとも1名の担当者から承認を得てください。
フェーズ7: 切り替え(カットオーバー)
切り替えは、トラフィックの少ない時間帯に予定してください(金曜の夜や月初がよく選ばれます)。プラットフォームが対応していれば、移行元のCRMを読み取り専用モードにしてください。これにより、移行実行中に旧システムで新しいレコードが作られるのを防げます。移行全体を実行します。
移行元のCRMを読み取り専用にできない場合は、明確な「差分移行」計画を用意してください。最後のエクスポート後に作成・変更されたレコードを特定し、本番移行の後で別途移行します。
フェーズ8: 検証する
以下を検証するまでは、「本番稼働」のスイッチを入れないでください。
- 合計レコード数が合意した誤差範囲内で一致しているか
- 高価値のアカウントと案件のサンプルを手作業で抜き取り確認したか
- すべての連携が再接続され、テスト済みか
- 自動化とワークフローが再構築され、テスト済みか
- チームが新システムにログインし、操作できるか
移行後最初の48週間は、担当者の生産性が2040%低下することを見込んでおいてください。これを指標にあらかじめ組み込み、切り替え後ではなく切り替え前に経営陣へ伝えてください。
フェーズ9: 旧システムの廃止
両システムを読み取り専用で少なくとも30日間並行稼働させてください。チーム全体が新CRMだけで業務を回せるようになったら、旧システムを廃止し、契約を解約してください。
移行アプローチ一覧
| アプローチ | 仕組み | おすすめの対象 |
|---|---|---|
| ネイティブインポーター/CSV | 移行元からCSVでエクスポートし、移行先CRMの組み込みインポートツールでインポート | シンプルな移行、少ないレコード数(約1万件未満)、カスタムオブジェクトが少ない場合 |
| ベンダー支援によるオンボーディング | 新CRMの導入チームまたはオンボーディングチームが、契約の一環として移行を実施 | 新しいCRMを購入するミッドマーケットのチーム。オンボーディング費用に含まれることが多い |
| サードパーティの移行サービス | 25以上のCRMの組み合わせに対応し、フィールドマッピングと重複排除が組み込まれたMigrateMyCRM(旧Trujay)のような専用ツール | 複雑なフィールドマッピングがあり、カスタム開発なしでガイド付きの再現可能なプロセスを求めるチーム |
| APIベースのカスタム移行 | エンジニアリングチームが移行元APIから抽出し、移行先APIに読み込むスクリプトを作成 | 大量のレコード(50万件以上)、複雑なカスタムオブジェクト、厳格なデータ変換要件がある場合 |
| 段階的な並行稼働 | 新しい案件や連絡先は新CRMに入力し、過去データは並行して移行。履歴が完全に移行されるまで両システムを稼働 | 移行中も事業継続性を最優先したい、混乱の少ない移行 |
まだどのCRMに落ち着くか評価中のチームは、移行計画を確定する前におすすめCRMソフトウェアの総まとめを参照してください。
決め方: 移行の意思決定の枠組み
| 必要としているのが... | この方法を選ぶ |
|---|---|
| 1万件未満のレコード、標準オブジェクトのみ、複雑なカスタムフィールドがない | ネイティブCSVインポートでのDIY。作業に週末1回分を見込む |
| 1万~10万件のレコード、いくつかのカスタムフィールド、少数の連携 | ガイド付きパッケージを備えたサードパーティの移行ツール(MigrateMyCRM、SyncMatters)を使う |
| 10万件以上のレコード、複雑なカスタムオブジェクト、複数の連携 | ベンダーのプロフェッショナルサービスまたは専門の移行代行会社に依頼。1.5万~5万ドルを予算化 |
| 開発リソースはゼロだが複雑なデータモデル | カスタム移行アドオン付きのサードパーティツール。ガイド付きプランに875~5,000ドルを予算化 |
| 厳格なコンプライアンス要件(HIPAA、GDPR、金融サービスなど) | 完全な監査ログを備えたAPIベースのカスタム移行。早い段階で法務・セキュリティ部門を関与させる |
| 移行中の事業継続性を最大限確保したい | 段階的な並行稼働アプローチ。混乱を減らす代わりに、運用の複雑さの増加を受け入れる |
単なるアップグレードではなくベンダーそのものを乗り換える場合は、SaaSベンダーの乗り換えガイドとベンダーデューデリジェンスのチェックリストが、契約と交渉の側面をカバーしています。
中小企業向けの検討事項については、中小企業向けCRMの選び方ガイドに、ネイティブインポーターで本当に十分な場合と、それ以上が必要な場合についての解説があります。
料金: 想定しておくべきこと
DIY(ネイティブインポーター/CSV)。 無料か安価です。ほとんどのCRMには追加費用なしで組み込みのインポートツールが含まれています。支払うのはお金ではなく時間です。1万件未満のきれいな移行なら、オペレーション担当者の作業時間として13日を見込んでください。もう少し複雑な場合は12週間を見込んでください。
ベンダー支援によるオンボーディング。 ほとんどのエンタープライズおよびミッドマーケット向けCRMベンダーは、オンボーディングパッケージに移行を含めています。プラットフォームとプランによりますが、オンボーディング契約の費用は1,500~10,000ドル程度が相場です。通常はコアオブジェクト(連絡先、アカウント、案件)をカバーしますが、カスタムオブジェクトや複雑な連携は対象外です。
サードパーティの移行サービス。 MigrateMyCRMは、小規模なレコードセットであれば一括料金299ドルから始まり、ガイド付き移行(専門家によるサポート5時間)は875ドルです。複雑な移行になると数千ドル規模に拡大します。SyncMattersも同様の段階的な料金体系を採用しています。
APIベースのカスタム移行。 主なコストはエンジニアリングの工数です。複雑さや、社内で対応するか専門の代行会社に依頼するかによりますが、適切に範囲を定めたカスタム移行で5,00020,000ドル以上が相場です。DataSovrenの内訳では、プロフェッショナルサービス、データ整理、連携の再構築をすべて含めたフルサービスのエンタープライズ移行は2万10万ドル以上とされています。
予算に入れておくべき隠れたコスト。 移行後48週間は、担当者が新システムに慣れるまで営業生産性が2040%低下します。これはベンダーへの支払い項目ではありませんが、実質的な売上への影響です。承認前にビジネスケースにモデル化しておいてください。
新CRMの契約を同時に交渉しているなら、移行支援を契約に含めるよう働きかけてください。営業プロセスの中で依頼すれば、多くのベンダーはオンボーディング費用を免除するか、トライアル期間を延長してくれます。
よくある質問
CRM移行にはどれくらいの期間がかかりますか。
レコード数と複雑さによります。小規模企業の移行(1万件未満のレコード、標準オブジェクト、12個の連携)は、十分な準備があれば週末で完了できます。ミッドマーケットの移行(5万20万件のレコード、カスタムオブジェクト、複数の連携)は、監査、データ整理、テスト、切り替えのフェーズを含めると、通常412週間かかります。50万件以上のレコードと深いカスタマイズを伴うエンタープライズの移行は、36か月かかることもあります。
最も移行が難しいデータは何ですか。
活動履歴(メール、通話、メモ)とファイルの添付は、一貫して最も問題になりやすい部分です。多くのCRMは、別システムのスキーマにきれいにマッピングできる形式で活動ログをエクスポートしません。ファイルの添付は、ネイティブインポーターから完全に除外されることがよくあります。これらは手作業を伴う別のワークストリームとして計画し、どの過去の文脈が移行後も残り、どれが失われるかについて、チームと事前に期待値をすり合わせておいてください。
データの整理は移行前と移行後のどちらに行うべきですか。
移行前です。常に移行前に行ってください。汚れたデータを移行しても、問題を移すだけです。重複排除、フィールドの標準化、レコードのアーカイブはすべて、エクスポート前に移行元のCRMで行うべきです。例外は、サンドボックスでのQA中に気づいたわずかな不備で、それらは移行全体をやり直すのではなく、移行先で修正してください。
移行中に両方のCRMを同時に稼働させることはできますか。
できます。多くのチームにとって、これは最もリスクの低いアプローチです。段階的な並行稼働とは、新しい活動は新CRMに入力しながら、旧システムを過去参照用に読み取り専用で残しておくというものです。トレードオフは運用の複雑さです。担当者は、どの目的にどちらのシステムを使うか明確なルールを必要とします。並行稼働の期間には明確な終了日(30~60日)を設定してください。そうしないとずるずると長引いてしまいます。
チームが最もよく間違えることは何ですか。
サンドボックステストを省略することです。余計な手間に感じられますが、これはフィールドマッピングのエラー、壊れた関係性、欠落したレコードを、本番環境で問題になる前に見つけられる唯一の方法です。サンドボックスを省略したチームは例外なく後悔します。テスト環境で移行全体を実行し、きちんとQAを行い、承認を得てから、本番で実行してください。
移行を最初から正しく行う
CRM移行が失敗するのは、実質的な範囲、実質的なリスク、実質的なビジネスへの影響を伴うプロジェクトとしてではなく、単なるデータコピー作業として扱われたときです。うまくいくチームは、実際の切り替えにかける時間の2倍を、計画とテストのフェーズに費やしています。この前倒しの労力こそが、切り替え自体を拍子抜けするほど平穏なものにしてくれます。それこそがまさに目指すべき状態です。
まだ評価段階にあり、移行先のCRMを確定していないなら、移行計画に着手する前にCRM評価基準チェックリストから始めてください。

Head of Enterprise Solutions