Data Migration Guide
移行前のデータ準備：完全チェックリスト
CRM移行で誰も教えてくれないこと：インポート自体は数時間で終わります。準備には数日、場合によっては数週間かかります。そして、準備をスキップしたチームが、カットオーバー当日の夜11時に「コンタクトの40%が消えた。なぜ？」と電話をかけてくることになります。
あるミッドマーケットSaaS企業のRevOpsチームは、SalesforceからあるCRMへ6,000件のコンタクトを移行するのに3週間費やしました。最初の実行は1,200件の重複で失敗。2回目の実行は4つの異なる日付形式を調整できず失敗。3回目でようやく成功しました。さらに1週間かかりました。このような事態は、1日の移行前監査作業で回避できたものです。
このガイドでは、混乱した移行を退屈な移行に変えるための7つの準備手順を説明します。ステップ7まで移行先システムには触れません。それは意図的なことです。
ステップ1：ソースシステムのデータ品質監査を実施する
1行もエクスポートする前に、実際に何を持っているかを把握する必要があります。ほとんどのチームは移行中にデータ品質の問題を発見します。賢いチームは事前に発見します。どのシステムに移行するか評価している段階なら、CRM購入チェックリストで確約前に確認すべきデータモデルの質問事項を確認してください。
ソースCRMを開いて、以下の数字を確認しましょう：
オブジェクト別の行数：
- コンタクトの合計数
- 会社/アカウントの合計数
- 取引/商談の合計数（オープンとクローズド）
- 活動の合計数（通話、メール、メモ、タスク）
最もよく使うオブジェクトのフィールド入力率。 コンタクトの場合、メール、電話、会社名、役職、ライフサイクルステージ、リードソース、国を確認します。70%未満のフィールドは今のうちに把握すべき問題です。
重複の推定値。 Salesforceでは、メールドメイン別にグループ化したコンタクトのレポートを実行し、明らかなクラスターを探します。HubSpotでは重複管理ツールを使用（コンタクト > アクション > 重複を管理）。Pipedriveでは、CSVにエクスポートしてメール列でCOUNTIFを実行します。大まかな推定で十分です。まだマージはしません。数えるだけです。
日付形式の不整合。 ランダムに50件のレコードをエクスポートし、日付フィールドを確認します。MM/DD/YYYY、DD/MM/YYYY、YYYY-MM-DD、「Q3 2024」のようなテキスト文字列が混在している場合、後のフィールドマッピングで破綻する正規化の問題があります。
データ監査チェックリスト
| チェック項目 | 測定内容 | 許容閾値 |
|---|---|---|
| オブジェクト別の合計レコード数 | 行数 | 移行後QAのベースライン |
| メールフィールドの入力率 | 有効なメールを持つコンタクトの% | 80%超 |
| 電話フィールドの入力率 | 電話番号を持つコンタクトの% | 60%超 |
| 会社名の入力率 | 会社に関連付けられたコンタクトの% | 75%超 |
| ライフサイクルステージの入力率 | 定義されたステージを持つ% | 85%超 |
| 重複の推定値 | 重複したメールを持つコンタクトの% | クレンジング前で5%未満 |
| 日付形式の一貫性 | 異なる日付形式の数 | 1（正規化後） |
| 国フィールドの形式 | フルネームとISO コードの混在 | いずれかに統一 |
数字を書き留めてください。この監査ベースラインは移行後のQA目標にもなります。インポート後にこれらの数字と照合します。
ステップ2：移行する価値のあるデータを定義する
すべてを移行する必要はありません。この判断は移行プロセス全体で最もレバレッジの効く選択のひとつですが、ほとんどのチームは明示的にこの判断を下しません。
各オブジェクトとレコードタイプについて、次の質問をしてください：
コンタクト/リード：3年以上活動のないレコードは必要ですか？セールスサイクルが90日なら、2021年以来エンゲージメントのないコンタクトは見込み客ではなく、ストレージのオーバーヘッドです。カットオフ日を決めましょう。
過去の活動：3年前の通話ログ、メールスレッド、ミーティングメモ。担当者は実際に参照しますか？ほとんどのチームでは、18ヶ月以上前のものは参照しません。2019年のすべてのメモを移行するのではなく、ソースシステムをアーカイブしましょう。
取引/商談：平均セールスサイクルの3倍以上古いクローズロスト取引はほとんど再開されません。会社レコードは移行しても4年前の取引レコードはスキップするかもしれません。
カスタムオブジェクト：Salesforceに存在しないプロセス用のカスタムオブジェクトを構築していた場合、移行しないでください。
アーカイブ対移行のシンプルなフレームワーク：
| レコードの年数＋活動状況 | 判断 |
|---|---|
| 過去12ヶ月にアクティブまたはエンゲージ済み | 移行 |
| 12〜24ヶ月活動なし、高価値（エンタープライズアカウント） | フラグをつけて移行 |
| 12〜24ヶ月活動なし、低価値 | ソースにアーカイブ |
| 24ヶ月超の活動なし | アーカイブまたは削除 |
| 18ヶ月超の過去活動 | ソースシステムにアーカイブ、移行しない |
この判断を文書化してください。担当者から古いデータがどこにあるか聞かれます。書面でのポリシーがあれば、その会話が危機にならずに済みます。
ステップ3：エクスポート前の重複排除
これはほとんどのチームがスキップするステップで、ほとんどの移行が失敗する原因です。重複をエクスポートすると、重複をインポートします。見慣れない新しいシステムでの重複排除は、知っているシステムでの重複排除より難しいです。
Salesforceの場合：重複ルール（設定 > 重複管理）を使ってレポートを実行します。一括マージには標準ツールをバッチで使用するか、5,000件以上のコンタクトにはDedupelyのようなサードパーティツールを使用します。マッチルールをメール完全一致で自動マージに設定し、ファジーマッチ（名前＋会社名）を手動確認キューに入れます。
HubSpotの場合：コンタクト > アクション > 重複を管理。HubSpotのツールがマッチングを行い、確認用のペアを表示します。大規模なデータベースでは時間がかかります。10,000件以上のコンタクトには丸1日見込んでください。HubSpotのインポートガイドも参照してください。
Pipedriveの場合：Pipedriveのネイティブ重複排除は限定的です。CSVにエクスポートし、Google SheetsまたはExcelで重複排除（メール列でデータ > 重複の削除）を行い、再インポートします。より高度なマッチングには、移行前にDedupe.ioを通してエクスポートを実行します。
マージ戦略：
- まずメールの完全一致から始めます。安全に自動マージできます。
- 名前＋会社名のファジーマッチを手動で確認します（1,000件あたり約30分）
- 会社名が大きく異なるレコードは自動マージしないでください。それは同じ会社の異なるコンタクトである場合が多いです
マージ前は必ずバックアップしてください。重複管理ツールに触れる前に、現在の状態のフルCSVをエクスポートしてください。一括マージは確実には取り消せません。
ステップ4：主要フィールドを正規化する
フィールドの正規化は手間がかかります。しかし、クリーンなインポートと初日の担当者からのサポートチケット40件の違いはここにあります。
電話番号：目標標準としてE.164形式（+15551234567）を選びます。ITU-T E.164仕様が標準を正式に定めていますが、実務上の重要なルールは：プラス記号、国番号、加入者番号、区切りなし。内線番号をメイン電話フィールドから除去し、必要に応じて別の内線フィールドを作成します。フィールドタイプ検証を壊すすべての書式文字（括弧、ダッシュ、スペース）を削除します。
国フィールド：ISO 3166-1 alpha-2コード（US、GB、DE）またはフルネームのどちらかを選択し、混在させないでください。国フィールドに「Japan」「JPN」「JP」が混在していると、3つの異なる値としてインポートされます。
ライフサイクルステージ：これは大変です。ソースシステムには移行先の4つにマッピングする必要がある7つのステージ名が存在することが多いです。マッピングは自動化できません。新しいシステムで「Marketing Qualified Lead」と「Product Qualified Lead」の両方がどこに行くかを決める必要があります。各ステージの実践的な意味が明確でなければ、リードライフサイクルステージでマッピングの議論を始める前のフレームワークが得られます。
リードソース値：同じ問題です。リードソースフィールドからすべての異なる値をエクスポートし、移行先のピックリストにマッピングします。移行先に対応する値がない場合、空白でインポートされるかエラーになります。
正規化リファレンステーブル
| フィールド | よくある問題 | 正規化の目標 |
|---|---|---|
| 電話 | 形式の混在、内線番号がメインフィールドに、先頭ゼロの消去 | E.164 (+CC NNNNNNNNNN) |
| 国 | フルネーム/略称/ISOの混在 | ISO 3166-1 alpha-2 |
| ライフサイクルステージ | ソースの値が移行先より多い | 明示的な値マップを作成 |
| リードソース | 自由記入 vs. ピックリスト値 | 移行先のピックリストにマッピング |
| 日付フィールド | 形式の混在、テキスト文字列、NULL | ISO 8601 (YYYY-MM-DD) |
| 通貨 | ロケール形式の混在（$1,000 vs 1000.00） | 数値、書式なし |
| 役職 | 大文字/小文字の不整合、略語 | 一貫したタイトルケース |
インポートテンプレートを開く前にこの表を作成してください。エクスポート前に正規化されていないすべてのフィールドが、移行先での問題になります。
ステップ5：移行先に触れる前にフィールドマッピングを文書化する
フィールドマッピングは当日に決める作業として扱われることがよくあります。それは間違いです。インポート実行中にプレッシャー下で下した判断はエラーを生み、2週間後に担当者が見つけるまで気づかれません。
今すぐ、移行先CRMに触れる前に、フィールドマッピング文書を作成してください。
フィールドマッピングテンプレート
| ソースフィールド | ソースタイプ | ソースオブジェクト | 移行先フィールド | 移行先タイプ | 移行先オブジェクト | 変換ルール |
|---|---|---|---|---|---|---|
| First Name | テキスト | コンタクト | First Name | テキスト | コンタクト | なし |
| Last Name | テキスト | コンタクト | Last Name | テキスト | コンタクト | なし |
| メール | コンタクト | メール | コンタクト | すべて小文字化 | ||
| Phone | 電話 | コンタクト | Phone | 電話 | コンタクト | E.164に変換 |
| Lifecycle Stage | ピックリスト | コンタクト | Lifecycle Stage | ピックリスト | コンタクト | 下記の値マップ参照 |
| Annual Revenue | 通貨 | アカウント | Annual Revenue | 数値 | 会社 | 通貨記号を除去 |
| Close Date | 日付 | 商談 | Close Date | 日付 | 取引 | YYYY-MM-DDに変換 |
| Lead Source | ピックリスト | コンタクト | Original Source | ピックリスト | コンタクト | 下記の値マップ参照 |
| Account ID | ルックアップ | コンタクト | Company | 関連付け | コンタクト | 会社名マッチで解決 |
「変換ルール」列が最も重要です。空白のままにすると、インポート実行中にその判断を下す予定ということです。そうしないでください。
ピックリストフィールドには、別の値マッピングセクションを作成してください：
ライフサイクルステージ値マップ： | ソース値 | 移行先値 | |---|---| | Lead | Lead | | Marketing Qualified Lead | MQL | | Sales Qualified Lead | SQL | | Opportunity | SQL | | Customer | Customer | | Churned Customer | Customer (非アクティブ) | | Evangelist | Customer |
ステップ6：過去の活動をどう扱うか決める
活動（通話ログ、メールスレッド、メモ、タスク）は最も難しい移行判断です。また、あらゆるCRMデータベースの中で最もボリュームが大きい部分でもあります。
トレードオフ：
活動を移行すると、担当者は一つの場所で全履歴を得られます。しかし、インポート時間、新システムのストレージコスト、リレーションシップマッピングエラーのリスクも増加します（活動は適切なコンタクトと取引レコードにリンクされ続ける必要があります）。
活動をアーカイブすると、履歴を移行せずに保持できます。担当者はカットオーバー後90日間、必要に応じて旧システムを読み取り専用アーカイブとして開けます。
実践的なガイダンス：
- 過去12ヶ月のすべての活動を移行する
- 12ヶ月以上前の活動はアーカイブ（移行しない）
- アクティブな取引に添付されたメモは常に移行する（価値の高いコンテキストです）
- メールスレッド：取引がアクティブでない限り、コンタクト1件につき最後の5件のみ移行
- タスクとリマインダー：オープンなタスクのみ移行。2022年の完了タスクはノイズを増やすだけで価値がありません
移行前に移行先CRMの活動レコード1件あたりのストレージコストを確認してください。一部のシステムでは、500,000件の活動レコードがプランの大幅アップグレードを意味します。
ステップ7：100件のテストサンプルを作成する
インポートを実行する前（テストインポートも含めて）、テストサンプルが必要です。これはデータ品質の問題の全範囲を代表する100〜150件のレコードです。
サンプルの選び方：
- すべてのフィールドが入力された問題のないクリーンなレコード：30件
- 電話番号が欠けているレコード：20件
- 名前フィールドに特殊文字があるレコード（アクセント記号、ハイフン、アポストロフィ：O'Brien、Müller）：20件
- 最大フィールド長のレコード（255文字の会社名、長い役職）：15件
- ライフサイクルステージ値が曖昧なレコード：10件
- データセットの既知のエッジケース（例：会社のないコンタクト、クローズ日のない取引）：5件
このサンプルを別のCSVとして保存してください。これがシャドーインポートのQAセットになります。最初にこの100件のサンプルをインポートして検証し、それからはじめてデータセット全体を処理します。
よくある落とし穴
重複の問題を新しいシステムに移動してしまう。 エクスポート前に重複排除しなければ、問題をそのまま移動するだけです。新システムのマージツールは馴染みがなく、担当者は初日から新しいCRMを信頼しなくなります。
フィールドマッピングを当日の判断事項として扱う。 「インポート中に決めればいい」という発言ひとつひとつが、45分のダウンタイムを追加し、サイレントエラーの可能性を高めます。間違ったフィールドに入った値がエラーなしにインポートされます。カスタムフィールドガイドはフィールドマッピング作業と並行して読む価値があります。インポートを始める前に移行先に構築すべきフィールドが解説されています。
変換ルールを文書化しない。 ライフサイクルステージマッピングのロジックを3時間かけて考え出し、どこにも記録せず、3週間後に「Evangelistコンタクトがステージなしでインポートされたのはなぜか」という質問に2時間かけて再導出することになります。
ストレージコストを確認せずにすべての過去活動を移行する。 あるチームは80万件の過去通話ログをストレージ課金のCRMに移行しました。6ヶ月間、月額費用が予想の3倍になりました。移行先を決める前にオプションを比較しているなら、Rework対Salesforceでストレージと価格モデルの違いが解説されています。
テストサンプルをスキップする。 最初のインポートにはエラーがあります。問題ありません。しかし、最初のインポートが100件ではなく50,000件だと、それらのエラーが連鎖します。
次のステップ
移行日を設定する前にデータ監査を完了してください。監査前にカットオーバーをスケジュールすることは本末転倒です。クレンジングにどのくらいかかるかはデータの品質を把握するまでわかりません。このプロセスを経験したチームは、RevOpsの成熟度が移行の難しさに影響することも指摘しています。成熟度が低い組織はデータ品質が低い傾向があり、この段階に多くの時間が必要です。
今週の作業：
- データ監査チェックリストを実行してベースライン数値を記録する
- 過去レコードの移行対アーカイブを決定する
- ライフサイクルステージとリードソースフィールドのすべての異なるピックリスト値をエクスポートする
- フィールドマッピング文書の作成を開始する
監査の数値とフィールドマッピング文書の骨格ができたら、データの積極的なクレンジングに移行する準備ができています。それが次のガイドで説明されます。
