シャドーインポートによる移行テスト

シャドーインポートは、「サンドボックスで3つのマッピングエラーを発見した」と「30人の担当者が待つカットオーバー当日に3つのマッピングエラーを発見した」の違いです。適切に実行すると2〜3時間かかります。本番稼働を1週間遅らせるような問題を防ぎます。

ある移行チームは、スプレッドシートで検証済みだったためシャドーインポートをスキップしました。Excelでフィールドマッピングが正しいことを確認し、ピックリスト値が揃っていることを確認し、自信を持っていました。カットオーバー当日、コンタクトと取引のリレーションシップフィールドが解決されていないことが判明しました。インポートツールが関連付けルックアップをスプレッドシートの比較が示唆したものとは異なる方法で処理していたのです。システム内のすべての取引がコンタクトから切り離されました。手動で関連付けを解決する間、カットオーバーは5日間延期されました。テスト前に移行先のCRMデータモデル設計を把握していなければ、このようなリレーションシップの失敗は見つけにくいです。

実際のサンドボックスでのシャドーインポートなら、最初の10分で検出できたはずです。

このガイドでは、シャドーインポートの完全なプロセスを説明します：セットアップ、テストデータセットの選択、インポート実行、QA検証、カットオーバーへの承認基準。

ステップ1：サンドボックスまたはテスト環境を設定する

移行先CRMの実際のインスタンスが必要です。スプレッドシートの比較や視覚的なチェックではありません。実際のCRM環境に対して実際のインポートツールを実行し、何が起きるかを確認することが目標です。

HubSpot：HubSpotのサンドボックスアカウントはProfessionalおよびEnterpriseプランで利用可能です。設定 > アカウント管理 > サンドボックス。サンドボックスを作成し、本番アカウントと同じカスタムプロパティ、パイプラインステージ、ライフサイクルステージ定義を設定します。サンドボックスは本番のセットアップを反映している必要があります。そうでなければカットオーバー当日に使用する設定とは異なる設定に対してテストすることになります。HubSpotサンドボックスドキュメントでは、本番から自動的に同期されるものと手動設定が必要なものが説明されています。

Salesforce：Salesforceには複数のサンドボックスタイプがあります。移行テストには、開発者サンドボックスで十分です。本番と同じ設定（オブジェクト、フィールド、ピックリスト値）を持っています。フルサンドボックスには本番データが含まれますが、プロビジョニングが遅く、移行テストには通常不要です。設定 > 環境 > サンドボックス > 新しいサンドボックス。

Pipedrive：Pipedriveにはネイティブサンドボックスがありません。別のメールアドレスで無料トライアルアカウントを作成し、本番のパイプラインステージとカスタムフィールドに合わせて設定します。無料プランの制限は500〜1,000件のレコードでのテストには十分です。

Zoho CRM：Zohoには設定 > Developer Space > Sandboxでサンドボックス環境があります。設定は本番インスタンスを反映します。

サンドボックスが利用できない場合：

  • テスト会社名と専用の管理者メールで新しい本番アカウントを作成する
  • すべてのテストレコードに明確なインポートタグ（「TEST IMPORT - DELETE」）を使用する
  • テスト後、カットオーバー前にそのタグのすべてのレコードを削除する

サンドボックスには以下が必要です：

  • すべてのカスタムフィールドが作成・設定済み（本番と同じタイプ、ピックリスト値）
  • パイプラインステージとライフサイクルステージが移行先設定に合わせて定義済み
  • ユーザー割り当てフィールドをテストする場合はユーザーアカウントが設定済み
  • 統合Webhookが無効化済み（テストインポートで実際の通知がトリガーされないように）

ステップ2：代表的なテストデータセットを準備する

テストデータセットは、ほとんどのシャドーインポートが失敗するポイントです。チームは50件のクリーンで整形されたレコードを使用し、移行が機能すると結論付けます。しかし、全データセットにはアクセント記号を含む40件のレコード、NULLのリレーションシップフィールドが200件、HTMLタグを含むメモが15件含まれており、テストでは予測できない方法でフルインポートが壊れます。

目標サイズ：500〜1,000件。エッジケースを露わにするのに十分な大きさですが、手動QAができる程度のサイズです。

テストデータセット選択基準

問題のあるレコードを意図的に含めてデータセットを構成します：

カテゴリ 件数 テスト内容
クリーンで完全に入力されたレコード 150 ベースライン（全フィールドあり、標準形式）
電話番号なし 60 電話フィールドのNULL処理
メールなし 40 必須フィールドがNULLの場合の処理
名前フィールドに特殊文字 50 O'Brien、Müller、José、Li Wei、複合姓
最大フィールド長 30 255文字の会社名、長いメモ、最大長URL
重複候補（同じメールの2コンタクト） 20 インポートツールが重複をどう処理するか
会社の関連付けなしのコンタクト 30 アカウント/会社リンクなしのスタンドアロンコンタクト
複数の取引に関連付けられたコンタクト 30 複数関連付けのリレーションシップレコード
メモや説明フィールドにHTMLが含まれるレコード 20 移行先でのノートフィールドのレンダリング
データセット内で最も古い日付のレコード 20 日付フィールド形式のエッジケース
すべてのライフサイクルステージ値のレコード 1件/値 ピックリストマッピングのカバレッジ
すべてのリードソース値のレコード 1件/値 ピックリストマッピングのカバレッジ
合計 約500

このセットを具体的にエクスポートしてください。最初の500行を取るのではありません。最初の500行は通常最近作成されたレコードで、古いレコードより整形されています。テストデータセットには乱雑さが必要です。

ステップ3：実際のツールを使ってインポートを実行する

これが重要です：カットオーバー当日に使用するものと同じインポートツール、同じフィールドマッピングファイル、同じ変換ルールを使用してください。テストインポートに異なる方法を使用すると、異なるプロセスをテストすることになります。

ソース/移行先の組み合わせ別の一般的なインポートツール：

  • HubSpot → 他のCRM：ネイティブCSVエクスポート＋移行先CRMのCSVインポート。HubSpotのインポートドキュメントには各オブジェクトに必要な列ヘッダー形式が詳細に記載されています。テストCSVはこれに正確に従う必要があります。
  • Salesforce → 他のCRM：Salesforce Data Loader（無料）またはテスト実行にはData Loaderのバッチモードが必須です。行ごとの成功/エラーログを生成し、QAをはるかに高速化します。
  • Pipedrive → 他のCRM：ネイティブCSVエクスポート＋移行先インポートウィザード
  • 任意 → 任意：Trujay、Migrate.io、Import2などのサードパーティ移行ツールはリレーションシップの解決を自動で処理します

実行前に：フィールドマッピング文書と変換ルールを準備してください。文書に従って実行し、即興は禁止です。テストインポート中にその場で判断しているなら、文書は未完成です。実行前に完成させてください。HubSpotから切り替える場合、HubSpotからReworkへの移行でそのソースシステム固有のインポート順序の注意点が解説されています。

インポートの順序（これは重要です）：

  1. まず会社/アカウント
  2. 次にコンタクト（会社の関連付けを解決できるように）
  3. 次に取引/商談（コンタクトの関連付けが必要）
  4. 最後に活動（取引とコンタクトの関連付けが必要）

この順序でテストインポートも実行してください。順序から逸脱することはリレーションシップフィールドが壊れる最も一般的な原因のひとつです。

インポートログをリアルタイムで確認してください。 離れてから戻ってこないでください。ログにはフィールド検証エラー、タイプ変換の失敗、スキップされたレコードが表示されます。レコードIDとエラーメッセージを含む各エラーをメモしてください。QAステップでこのリストが必要です。

ステップ4：インポート後のQAチェックリスト

インポート完了後、エラーなしで終了したからといって成功と思わないでください。このチェックリストを体系的に実行してください。

インポート後のQAチェックリスト

レコード数の確認：

  • インポートされたコンタクトの合計が予想数と一致する（ベースラインから意図的なスキップを引いた数）
  • インポートされた会社の合計が予想数と一致する
  • インポートされた取引の合計が予想数と一致する
  • インポートエラー数がエラーログと一致する（サイレントスキップなし）

フィールドタイプの正確性：

  • 日付フィールドが日付として表示される（テキスト文字列やUnixタイムスタンプではない）
  • 数値フィールド（Annual Revenue、取引金額）がテキストではなく数値として表示される
  • 通貨フィールドが移行先で正しく表示される
  • 電話フィールドが一貫した形式で表示される
  • チェックボックスフィールドがTrue/Falseになっている（移行先の目標でなければ「1」/「0」や「Yes」/「No」ではない）

ピックリスト値のマッピング：

  • すべてのライフサイクルステージ値が有効な移行先値にマッピングされている（空白のライフサイクルステージなし）
  • リードソース値が正しくマッピングされている
  • 取引ステージ値が正しくマッピングされている
  • カスタムピックリストフィールドが正しくマッピングされている

リレーションシップの整合性：

  • 20件のコンタクトレコードを開いて会社の関連付けが正しいことを確認
  • 10件の取引レコードを開いてコンタクトの関連付けが正しいことを確認
  • 少なくとも3件の取引レコードで取引オーナーが正しく割り当てられていることを確認
  • 複数関連付けのレコード（複数の取引にリンクされたコンタクト）ですべての関連付けが存在するかを確認

フォーミュラと計算フィールドの結果：

  • 移行先CRMが計算フィールドを持つ場合（最終活動からの日数、取引経過時間など）、5件のレコードで妥当な値かをスポットチェック

自動化トリガーの確認：

  • テストインポートレコードがライブのワークフロー/シーケンスをトリガーしていないことを確認（本番に近い環境で実行した場合に重要）

各失敗をログに記録してください。「ほぼ機能する」QAチェックは合格ではありません。すべての失敗はフィールドマッピング文書の欠陥であり、フルインポートに影響します。

ステップ5：最もよく使われる3つのレポートをテストする

フィールドレベルの検証は個別のレコードエラーを検出します。レポートの検証は、データが集計されたときにのみ現れる体系的なマッピング問題を検出します。

最もよく使われる3つのレポートを特定してください：

  • 通常：ステージ別パイプライン概要、ライフサイクルステージ別コンタクト、今月作成された取引
  • 担当者チームに毎日開くレポートを確認してください。週次パイプラインレビューでは、営業チームが最も依存するパイプラインレポート形式が説明されています。

各レポートについて：

  1. 500件のテストサンプルに対してソースシステムで同じレポートを実行する
  2. 移行先で同じレポートを（インポートされたレコードにフィルタリングして）実行する
  3. 数字を比較する

カウントは一致するべきです。ソースシステムがテストサンプルで85件のSQLコンタクトを表示し、移行先が79件を表示する場合、6件のレコードに影響するライフサイクルステージのマッピングエラーがあります。フルインポート前に見つけてください。

一般的なレポートレベルの不一致とその原因：

  • ライフサイクルステージのカウント差異：正しくマッピングされていないピックリスト値
  • 売上合計のずれ：テキストとしてインポートされた通貨フィールド（正しく合計されていない）
  • 日付ベースのフィルターが間違ったレコードを返す：誤った形式でインポートされた日付。レコードが誤った期間に帰属
  • オーナーレポートが空：ユーザー割り当てが解決されていない

ステップ6：担当者1人に5件のレコードをエンドツーエンドでテストしてもらう

技術的なQAは技術的なエラーを見つけます。担当者は使いやすさのエラーを見つけます。インポートログでは正しく見えるが、取引を進める際には間違って感じるフィールドです。

ソースデータをよく知る担当者を選んでください。5件のコンタクトのレコードIDを伝えて、次のことを依頼してください：

  1. 新しいシステムでレコードを見つける
  2. 情報が正しく見えるか確認する（会社、役職、電話、メール、ライフサイクルステージ）
  3. そのコンタクトの活動履歴を確認する
  4. 関連付けられた取引を開いて取引情報を確認する
  5. 間違っていたり欠けていたりするものを報告する

QAチェックリストを渡さないでください。データ品質に対する担当者の誘導なしの反応が、構造化されたチェックよりも価値があります。得たいフィードバックは「正しく見える」または「使っていた取引ステージはどこ？」というものです。それが初日に移行がチームに問題を起こすかどうかを示すシグナルです。

ステップ7：すべてのエラーを文書化し、カットオーバー前に修正する

QA後、エラーのリストができます。各エラーには2つの原因のどちらかがあります：

  1. フィールドマッピング文書のミス
  2. マッピング文書が対処していなかったデータのエッジケース

カットオーバー前にどちらもマッピング文書で修正する必要があります。移行先のレコードを手動で編集してエラーを修正しないでください。それは3件のレコードにパッチを当て、残り47,000件に根本原因を残したままにします。

各エラーについて：

  • 根本原因を特定する：間違った変換ルール、誤ったタイプ処理、間違ったピックリストマッピング
  • マッピング文書を更新する
  • 修正したプロセスを通じて影響を受けるテストレコードを再実行する
  • アウトプットが正しいことを確認する

エラーの修正にフルテストインポートの再実行が必要な場合は、実行してください。さらに2〜3時間かかります。しかし、修正で二次エラーが発生したことをカットオーバー当日に発見する方が最悪です。

見つかったすべてのエラーとその修正方法のログを保持してください。 このログは移行文書の一部になり、テストで検出されなかった問題がカットオーバー後に表面化した場合に役立ちます。

カットオーバーのスケジュール前の承認チェックリスト

このリストのすべての項目が完了するまでカットオーバーをスケジュールしないでください：

データの検証：

  • テストインポートのレコード数が予想数の0.5%以内で一致している
  • インポートログに未解決のフィールドタイプエラーがない
  • ライフサイクルステージのNULL率がインポートされたレコードの1%未満
  • すべてのリレーションシップフィールドが正しく解決されている（孤立したコンタクトや取引なし）

レポートの検証：

  • 3つの主要レポートすべてがソースシステムのカウントと2%以内で一致
  • 収益/通貨の合計がソースと0.1%以内で一致
  • 日付ベースのフィルターが正しいレコードセットを返している

ステークホルダーの承認：

  • 担当者のQA完了（少なくとも1人の担当者が5件以上のレコードをテストし、データが正しく見えることを確認）
  • 営業リーダーシップが主要レポートを確認し、正しく見えることを確認
  • IT/管理者がユーザーアクセスと権限設定を確認

プロセスの準備：

  • フィールドマッピング文書が確定（テストインポートのすべてのエラーが修正済み）
  • インポートシーケンスが文書化済み
  • ロールバック計画が文書化済み
  • カットオーバーの通知が下書き済み

すべてのチェックボックスが確認されるまでカットオーバーをスケジュールしないでください。承認リストは官僚主義ではありません。「機能すると思う」と「機能することを確認した」を分けるチェックポイントです。

よくある落とし穴

エッジケースを露わにするには少なすぎるレコードでテストする。 クリーンなデータで50件のテストはQAを通過しますが、メモフィールドにHTMLが含まれる200件に当たるとフルインポートで失敗します。意図的なエッジケースを含む500件以上を使用してください。

リレーションシップをテストせず、フラットなコンタクトフィールドのみテストする。 コンタクトフィールドのQAは簡単な部分です。リレーションシップのQAが移行の壊れる箇所です。取引からコンタクトへのすべての関連付け、コンタクトから会社へのすべてのリンクを、フィールドレベルのチェックから推測するのではなく、明示的にテストする必要があります。

担当者のQAステップをスキップする。 技術ユーザーはフィールドが正しいかどうかをチェックします。担当者はデータが使えるかどうかをチェックします。それは異なる基準です。技術的には有効でも使えない形式の電話番号（市外局番なし、間違った国番号）は技術的なQAを通過しますが、担当者のテストでは失敗します。

マッピング文書ではなく移行先でエラーを修正する。 これが最も一般的な間違いです。ライフサイクルステージが空白の5件のレコードを見つけ、移行先で手動で「SQL」に設定して先に進みます。カットオーバー当日、500件のレコードが空白のライフサイクルステージでインポートされます。マッピング文書の根本原因を修正してください。

シャドーインポートが完了する前にカットオーバーをスケジュールする。 特定の本番稼働日に向けたリーダーシップからのプレッシャーは現実です。しかし、承認基準が満たされる前にカットオーバーをスケジュールすることが、営業リーダーシップが見ている中での公開失敗につながります。シャドーインポートでの1週間の遅延は、カットオーバーのロールバックより良いです。パイプライン衛生文化は関連するコンテキストです。パイプラインの規律が弱いチームは、シャドーテスト中に表面化する悪いデータの量を過小評価することが多いです。

次のステップ

計画されたカットオーバーの少なくとも5営業日前にシャドーインポートをスケジュールしてください。このバッファがエラーを修正し、必要に応じてテストインポートを再実行し、急かされることなくステークホルダーの承認を得る時間を与えます。そして承認が得られたら、CRMのロールアウトと採用に、クリーンなデータ移行をチームが実際に使うシステムに変えるための担当者トレーニングと変更管理の手順があります。

シャドーインポートはカットオーバースケジュールの前の最後の活動であるべきです。同時に進行する複数のタスクの一つではありません。必要な注意を払ってください。

承認チェックリストが完了したら、カットオーバーをスケジュールしてカットオーバー当日のプレイブックを準備する準備ができています。そのプロセスはカットオーバー当日のガイドで説明されています。

関連ガイド