CRM移行時の過去の活動履歴、メモ、メールの取り扱い

著者: Calvin D. · 更新日: 2026年4月18日

あるAEが6ヶ月間、更新交渉に取り組んでいました。そのAccountは2年間の付き合いがあります。その間に14件の通話ログ、競合製品との比較評価、4ヶ月目の価格に関する異議、そして8ヶ月目のミーティングで購買委員会から競合製品のインテグレーション機能についての具体的な懸念が提起されていました。

移行でそのすべてが消えました。意図的ではありませんでしたが、活動履歴はエクスポートのスコープ外であり、AEには確認するよう誰も告げていませんでした。

移行から3週間後、更新交渉が始まりました。AEは競合に関する異議を覚えていませんでした。通話でインテグレーション機能について尋ねると、見込み客は不満を示しました。すでにこの話をしていたのに、と。更新交渉は停滞しました。最終的には成約しましたが、低い金額で、大きな信頼の損失を伴いました。

データの損失は技術的な失敗ではありませんでした。計画の失敗でした。何を移行し、何を残すかの決定が誰もなされていなかったのです。このガイドはその決定プロセスを扱います。データ移行前の準備に直接つながります。活動履歴をスコープに含めるかどうかを含む移行のスコープは、エクスポートツールに触れる前に定義されます。

過去の活動履歴があらゆる移行で最も難しい理由

ほとんどのCRMオブジェクトはクリーンに移行されます。Contact、Account、Deal、これらは定義されたフィールドを持つ構造化レコードです。フィールドはフィールドにマッピングされます。行数は一致します。

活動履歴は違います。

**ボリューム。**50名の営業チームを持つ成熟したCRMは何百万件もの活動レコードを蓄積します。メール開封イベント、通話ログ、ミーティングレコード、システム生成の更新、すべてがアクティビティストリームに存在します。誰もその大部分を見ることはありませんが、すべてがスペースと移行の帯域を消費します。Statistaが公開しているCRM使用に関するデータによれば、グローバルCRM市場は2023年に690億ドルを超えており、営業インフラがこれらのシステムをどれほど運営しているか、また活動データのボリュームがなぜこれほど大きくなったかを反映しています。

**フォーマットの不整合。**通話ログはプレーンテキストかもしれません。メールはHTMLで保存されているかもしれません。メモは独自のリッチテキスト形式かもしれません。ミーティングの結果はテキストではなくチェックボックスかもしれません。移行先CRMはこれらを異なる方法で処理するため、すべてのフォーマットに変換の判断が必要です。

**不完全なデータ。**古いCRMではメールのメタデータ（件名、送信者、受信者、日付）は保存されていてもメール本文は保存されていないことがよくあります。または本文が正しくレンダリングされないエンコードで保存されている場合があります。不完全なデータを移行することは、移行しないよりも悪い結果になることがあります。タイムラインに「メール: [コンテンツなし]」と表示されると、担当者は何かが壊れたと思います。

**CRM固有のオブジェクト構造。**SalesforceはTaskとEventを分離しています。HubSpotにはエンゲージメントがあります。PipedriveはすべてをContactではなくDealに対して記録します。これらは1対1でマッピングされません。すべての移行でフィールド名だけでなく、活動タイプの変換ステップが必要です。これがソース固有のガイド、Salesforceからのエクスポート、HubSpotからのエクスポート、Pipedriveからのエクスポートがすべてオブジェクトエクスポートとは別に活動エクスポートを扱う理由です。

この4つの要因は、「すべての活動を移行する」ことがほぼ常に正しい答えではないことを意味します。常に可能でさえありません。判断フレームワークが技術的な仕組みよりも重要です。

移行とアーカイブの判断フレームワーク

エクスポートの前に、これらの判断を明示的に行い、文書化します。フレームワークには3つの変数があります: レコードの経過年数、レコードタイプ、案件のステータス。

判断マトリックス:

このフレームワークの適用方法:

このマトリックスをデフォルトとして使い、業務上のコンテキストに基づいて特定のカテゴリを上書きします。複数年の企業向け契約を販売している企業は「3年以上」の閾値をさらに後ろにずらすべきです。30日で案件が回転する高速SMBチームは履歴の基準日を6ヶ月に設定できます。

エクスポートが始まる前に、基準日とスコープ内のレコードタイプを文書化します。エクスポートクエリでこれらのパラメータでフィルタリングします。エクスポート後にもっと多くの履歴が必要と判断した場合は、追加のエクスポートパスが必要になります。

実際に移行すべきもの

このフレームワークの中で、これらのカテゴリは通常移行を正当化します。

**オープン案件の活動ログ。**現在オープン中の案件に関するメモ、通話ログ、メールのサマリーは必須です。担当者はday oneから新しいCRMでこれらの案件に取り組みます。効果的に進めるために履歴が必要です。

**収益上位20%のAccountのメモ。**高価値なAccountには、担当者とマネージャーが定期的に参照するリレーションシップのコンテキストがあります。上位20%のAccount（または規模によっては上位50）を抽出し、それらのAccountのすべての担当者入力メモと通話ログを移行します。

**直近12ヶ月のメールと通話の記録。**過去1年間の記録されたメールと通話は、アクティブなリレーションシップレコードを表しています。これらは担当者が通話や更新交渉の準備をする際に実際に参照する活動です。

**有効な商談のミーティング結果。**チームがDealに対してミーティングのメモや結果を記録している場合、オープンな商談に関するそれらのレコードは必須です。多くの場合、競合に関する情報や異議申し立ての履歴はここに存在します。

**最近クローズした案件のメモ（直近6ヶ月）。**最近クローズした案件（成約・失注を問わず）は、更新の関連性、紹介のコンテキスト、または学びの記録を持っていることが多いです。6ヶ月が通常適切なウィンドウです。

移行ではなくアーカイブすべきもの

これらのカテゴリはCRMに存在しますが、移行のコストを正当化しません。

**2年以上前のクローズ失注案件。**2年前に失注した案件の競合情報、価格に関する異議、ステークホルダーの状況は、今日行動可能であることはまずありません。案件レコード自体はアーカイブしますが、活動ログはソースシステムに残します。

**システム生成のメール開封イベント。**HubSpot、Salesforce、ほとんどのCRMはメール開封、リンクのクリック、ページビューをアクティビティとして自動記録します。これらは大容量で低シグナルなレコードです。移行すると、使えるコンテキストを追加せずに新しいタイムラインにノイズが生まれます。

**自動記録の低シグナルアクティビティ。**人間がコンテンツを書くことなく自動生成されたもの（ステータス変更ログ、ワークフローステップの完了、割り当て変更イベント）はアーカイブに入れます。移行先にはしません。

**人間のメモが添付されていないもの。**件名だけで内容のない通話ログは「通話があった」という事実を示すデータポイントです。コンテンツがなければ、新しいシステムでの価値は最小限です。ルールを設定します: メモ本文がない場合は移行せずアーカイブ。

フォーマット変換の処理方法

活動タイプはCRM間で1対1でマッピングされることはまずありません。エクスポート前に変換を計画します。

よくある変換の課題:

複雑なフォーマット変換の最も安全なアプローチは、元のタイプを問わず、すべての過去の活動を移行先CRMで「メモ」としてインポートすることです。データ移行に関するWikipediaの概要では、この変換と正規化のステージが、このようなフォーマット変換の判断をデータが移行先システムに入る前に行う必要があることを説明しています。これはタイプの区別（通話だったのかメールだったのか）を失いますが、コンテンツは保持されます。メモ本文の最初の行に元のタイプを記録します: [元のタイプ: 通話ログ, 2023-09-12]

このアプローチにより、担当者がほとんど直接アクセスしないレコードに複雑なタイプマッピングを必要とせず、移行先にクリーンで一貫した活動履歴が生まれます。インポート後は移行後データ監査で活動レコードが正しいContactにリンクされ、コンテンツがエンコードの問題なく表示されていることを確認します。

「day one」の最低限

すべてのものをgo-liveの前に移行する必要はありません。待てるものもあります。本当に緊急なものもあります。

day oneに担当者が新しいCRMで必要なもの:

• オープン案件の活動ログ（オープンDealのすべてのメモと通話サマリー）
• 収益上位10件のAccountのメモ
• 直近90日間のオープン商談に関するミーティング結果
• 直近6ヶ月の更新交渉に関するメモ

アーカイブされたソースシステムからリクエストに応じて取得できるもの:

• 6ヶ月以上前のクローズ失注案件の履歴
• 休眠AccountのActivityログ
• メールのメタデータと開封イベントのログ
• 過去のシステム生成イベント

まったくアクセス不要なもの:

• 2年以上前の自動記録イベント
• システムのワークフローイベント
• 再エンゲージメントの動きがない限り、解約済み顧客のActivityレコード

移行前に営業チームと「day oneの最低限」を定義します。営業マネージャーに最も履歴が重要な5件のAccountを特定してもらいます。それらの特定のレコードが移行スコープに含まれていることを確認します。その後、ソースシステムをgo-live後90日間アクセス可能な状態にしておきます。最低限以外のリクエストのほとんどは最初の2週間に集中します。

よくある失敗パターン

**コンテンツなしで活動メタデータを移行する。**件名だけでメモ本文のない通話ログは、多くのCRMでは何もないよりも悪い状況を生みます。読み取れないアクティビティが表示され、何かが失われたように見えます。完全なレコードを移行するか、まったく移行しないかのどちらかです。

**アーカイブされたシステムイベントと実際の担当者メモを混在させる。**何も選別せずに移行すると、自動生成のシステムイベント（メール開封、ページビュー、フィールド更新）が担当者が書いたメモと並んでタイムラインに表示されます。担当者はノイズをスクロールするのに時間を費やします。これらはエクスポートの段階でフィルタリングします。

基準日を設定しない。「後で決める」というアプローチは、エクスポートチームが「すべて移行する」というデフォルトになり、後続の整理とボリュームの問題を生みます。エクスポート前に基準日を設定します。文書化します。サプライズをなくすために営業マネージャーに伝えます。

**ストレージコストの影響を無視する。**レコードごとまたはストレージGBごとに課金するCRMに何百万件もの活動レコードを移行すると、ライセンスコストに影響を与えることがあります。フルの活動移行を確定する前に、移行先CRMの料金モデルを確認してください。Deloitteのエンタープライズデータ管理調査では、ストレージコスト分析が移行計画でよく見落とされること、そして移行時に決定したデータボリュームの判断が複数年の財務的影響を持つことを指摘しています。移行の対象外となったレコードはレガシーCRMデータの長期アーカイブで管理します。削除せず、アクティブなライセンスのまま放置もしないでください。

次に取るべき行動

エクスポートが始まる前に移行/アーカイブの判断を確定します。具体的に書き留めます。基準日、スコープ内のレコードタイプ、フル履歴移行を優先するAccountを明記します。サインオフのために営業マネージャーと共有します。

判断が文書化されたら、エクスポートのスコープが確定します。Salesforceからのクリーンなエクスポートでは、TaskとEventのクエリで基準日をフィルターとして使います。HubSpotからのクリーンなエクスポートでは、エンゲージメントAPIの呼び出しも同様に日付とエンゲージメントタイプでフィルタリングします。

移行の対象外となったすべてのデータについては、レガシーシステムデータの長期アーカイブでソースシステムを無期限にフルライセンスで維持せずにアクセスを確保する方法を説明しています。

関連ガイド

• データ移行前の準備
• Salesforceからのクリーンなエクスポート
• HubSpotからのクリーンなエクスポート
• レガシーCRMデータの長期アーカイブ
• go-live後のCRMデータ品質管理文化
• CRMの定期メンテナンス: データ劣化を防ぐ週次・月次の習慣