カットオーバー当日：障害を防ぐチェックリスト

カットオーバー当日は即興の時間ではありません。うまくいかなかったCRM移行はすべて同じ根本原因がありました：書面による計画がなかったことです。クリーンなカットオーバーを実行するチームはチェックリストから実行し、最初のレコードをインポートする前にロールバックのトリガーを定義し、すべての段階で営業チームにコミュニケーションを取ります。

悪いカットオーバーの例：200人規模の会社が金曜日の午後にSalesforceから新しいCRMに移行しました。インポートはうまく実行されました。6時間後、営業チームはデータの凍結が適切に伝達されていなかったため、両方のシステムからロックアウトされました。3つの欠落したチェックリスト項目が原因でした：データ凍結手順なし、担当者への事前連絡なし、カットオーバー窓口の責任者（DRI）の未指定。チームは週末にロールバックし、3週間後に再スケジュールしました。そのソースシステムがSalesforceだった場合、Rework対Salesforceでは担当者が初めてログインする前に移行先に設定する必要がある特定の設定の違いが解説されています。

このガイドが実行のベースとなる計画です。印刷してください。前夜に読んでください。すべての項目に担当者を割り当ててください。

T-マイナス48時間：カットオーバー前チェックリスト

カットオーバー前チェックリスト（10項目）

T-マイナス48時間でこれらの10項目のうちどれかが不完全であれば、カットオーバーを延期してください。本番稼働の失敗より1週間の遅延の方がよいです。

T-マイナス2時間：データ凍結

データ凍結は移行の中で最も扱いが悪い部分のひとつです。ほとんどのチームは遅すぎる通知、実施しない、その結果インポート窓口中にソースと移行先が乖離してしまいます。

なぜ重要か：担当者がソースCRMで午前9時15分に新しいコンタクトを作成し、インポートが午前9時から正午まで実行されると、そのコンタクトは移行先に入りません。担当者はデータが失われたと思います。初日から新システムへの不信感が生じ、取り除くのが困難です。

実施方法：

凍結窓口の2時間前に、正確な時間を含むSlack/Teamsメッセージを送信する：「[ソースCRM]へのデータ入力は今日の午前10時から午後2時まで停止します。」
インポート窓口中は、すべての管理者以外のユーザーについてソースCRMのユーザー権限を読み取り専用に変更する。これが唯一の確実な実施方法です。
Salesforceの場合：プロファイル設定で管理者以外のすべてのユーザーのすべてのオブジェクトのCreate/Edit権限を削除する。Salesforce Data Loaderガイドには凍結が発効した後に実行するインポートシーケンスの手順があります。
HubSpotの場合：単一の「読み取り専用モード」はありません。最も近いのはすべての管理者以外のユーザーを一時的にアカウントから削除することです。ほとんどのチームにとって、コミュニケーションが実施方法です。HubSpotのインポートドキュメントでは凍結後のインポートプロセスとインポートログがQAで表示する内容が説明されています。
Pipedriveの場合：設定 > ユーザーの管理。ユーザーごとに権限を制限できます。Pipedriveのインポートガイドでは、インポート窓口中に重複したコンタクトが来た場合に何が起きるかが文書化されています。

凍結窓口中に来る取引の対応：これは起きます。担当者が凍結中の午前10時30分にインバウンドリードを受け取ります。答えは：メモを取る、ソースシステムに入力しない、本番稼働後に直接移行先に入力する。凍結が始まる前にチームにこれを説明してください。

凍結窓口はインポート開始の少なくとも1時間前であるべきです。 凍結が発効した瞬間にインポートを開始しないでください。最後のデータ入力が完了して同期するまで1時間のバッファを与えてください。

1〜3時間目：インポートの実行

インポートシーケンス文書に従って実行しています。即興は禁止です。

インポートシーケンス

この正確な順序でインポートを実行します。各ステップはリレーションシップの解決のために前のステップに依存します：

会社/アカウント — 依存関係なし。最初に実行。
コンタクト — 会社に依存（会社の関連付けのため）。次のステップに進む前に会社のレコード数が一致することを確認。
取引/商談 — コンタクトに依存（コンタクトの関連付けのため）。次のステップに進む前にコンタクトのレコード数が一致することを確認。
活動（通話、メール、メモ、タスク） — コンタクトと取引に依存。最後に実行。
カスタムオブジェクト — 該当する場合。すべての標準オブジェクトの後に実行。

各ステップの間に：

次のオブジェクトに進む前にインポートログでエラーを確認する
レコード数をメモして予想と比較する
最新のインポートが正しく実行されたことを確認するために3件のレコードを手動でスポットチェックする

インポートログで注意すること：

タイプ変換エラー（数値フィールドのテキスト値）
必須フィールドの失敗（必須フィールドがNULLのためスキップされたレコード）
リレーションシップ解決の失敗（コンタクトはインポートされたが会社の関連付けが失敗）
重複検知（移行先に重複排除ルールがある場合、一部のレコードがブロックされる可能性）
レート制限またはタイムアウトエラー（大規模インポートはAPIの制限に達する可能性。必要に応じて一時停止して再開）

大規模データセット（50,000件以上）の場合：10,000〜15,000件ずつバッチでインポートします。これにより途中でインポートが失敗した場合の回復ポイントが得られ、QAが容易になります。大規模な移行でRevOpsが移行を管理している場合、RevOpsの成熟度モデルは各成熟度レベルのチームがカットオーバー後に通常必要とするクリーンアップ量について現実的な期待値を設定するのに役立ちます。

インポートが完全に完了するまでQAを開始しないでください。 インポート実行中にレコードを確認し始めたくなります。待ってください。不完全なデータは誤解を招き、残りのデータがインポートされると解消される問題に時間を無駄にします。

3〜4時間目：本番稼働QA

これがスイッチを入れる前の最終確認です。15項目のチェックリストを体系的に実行してください。各チェックには合格/不合格の判定があります。

本番稼働QAチェックリスト（15チェック）

レコード数の確認：

移行先のコンタクトの合計 = 予想数（±0.5%）
移行先の会社の合計 = 予想数（±0.5%）
移行先の取引の合計 = 予想数（±0.5%）
移行先のオープン取引の合計 = ソースのオープン取引数

フィールドの正確性スポットチェック（各10件のレコードを開く）： 5. [ ] コンタクトのライフサイクルステージが有効な値を表示している（NULL、未マッピングの値なし） 6. [ ] 取引ステージが移行先のパイプラインステージに正しくマッピングされている 7. [ ] 取引金額がテキストではなく数値として表示されている 8. [ ] 日付フィールド（クローズ日、作成日）が正しい形式で表示されている

リレーションシップの整合性： 9. [ ] 10件のコンタクトのランダムサンプル — すべてが正しい会社の関連付けを持つ 10. [ ] 10件の取引のランダムサンプル — すべてが少なくとも1件のコンタクトの関連付けを持つ 11. [ ] 5件の取引のランダムサンプル — 取引オーナーが正しく割り当てられている

レポートの確認： 12. [ ] ステージ別パイプラインレポート：オープン取引の合計金額がソースと1%以内で一致 13. [ ] ライフサイクルステージ別コンタクト：ステージ別カウントがソースと2%以内で一致 14. [ ] 当期間に作成された取引：カウントがソースと一致（凍結窓口を考慮）

システム機能： 15. [ ] 移行先に新しいコンタクトを作成するテスト — 基本的なワークフローが正しくトリガーされ、エラーなし

QAのスコアリング：

15/15のチェックが合格：本番稼働判断に進む
13〜14/15のチェックが合格：失敗を評価する。ブロッキングか？軽微な表示問題はリレーションシップフィールドの破損とは異なる
13未満：本番稼働しない。失敗を診断し、影響の範囲を特定し、ロールバックの判断を下す

4時間目：ゴー/ノーゴーの判断

これが計画されたカットオーバーと混乱したカットオーバーを分けます。本番稼働の基準とロールバックの基準は、開始前に定義されていなければなりません。QA窓口中に議論するのではなく。

ゴー基準（すべてが真でなければならない）：

QAチェックリストスコア：14/15以上
ブロッキングの問題なし（すべてのオープン取引が正しいステージを持ち、すべてのコンタクトが有効なライフサイクルステージを持つ）
レポートの合計が許容範囲内（パイプライン金額が1%以内、ステージカウントが2%以内）

ロールバックのトリガー（いずれか1つで十分）：

レコード数が説明のない2%超のずれ（インポートでレコードが失われた）
リレーションシップフィールドが大規模に壊れている（取引の5%以上がコンタクトの関連付けなし）
フィールドタイプの破損が検出された（通貨フィールドがテキストとしてインポートされ、収益レポートが壊れる）
移行先CRM自体が通常使用を妨げるパフォーマンスの問題を経験している

誰が判断を下すか：事前に1人を指名してください。委員会の判断ではありません。指名されたDRI（直接責任者）が上記の基準に基づいてコンセンサスなしに判断します。全員が決定しているとき、誰も素早く決定しません。そして遅延は問題を複合させます。

決定をコミュニケーションする方法：

ゴー：すぐに本番稼働のメッセージを送信（以下のテンプレート）
ノーゴー/ロールバック：ロールバックのメッセージをすぐに送信し、ロールバック手順に従う

問題を「調べている」間、コミュニケーションを遅らせないでください。先にステータスメッセージを送信し、それから調査してください。

4〜5時間目：ロールバック手順

ロールバックをトリガーする場合、失敗ではありません。計画を実行しているのです。ロールバックは破損したデータで本番稼働するよりも良いです。

ロールバック手順：

営業チームにすぐにロールバックのコミュニケーションを送信：「QAで問題が特定されたため、現在のところ[ソースCRM]に戻ります。[ソースCRM]で作業を再開できます。データは失われていません。再スケジュールされた本番稼働日を24時間以内にお知らせします。」
ソースCRMへのフルアクセスを再有効化する（データ凍結の権限を元に戻す）。
移行先CRMのインポートを削除する。ほとんどのCRMでは、特定の窓口中にインポートされたデータの一括削除または「空白にリセット」が可能です。移行先でチームが編集を始める前に行ってください。再インポートのためのクリーンな状態が必要です。
行われた作業を保存する。インポートログ、エラーログ、QAメモをエクスポートしてください。これらが根本原因修正のインプットになります。
翌営業日にデブリーフをスケジュールする。何が失敗したか？マッピング文書は何を変更する必要があるか？修正にどのくらいかかるか？現実的な再実行タイムラインを設定する。

ロールバックのタイムライン：決定から90分以内にロールバックを完了してソースCRMのアクセスを回復することを目指します。担当者が宙ぶらりんでいる時間が長いほど、不信感が高まります。

再スケジュール：新しいカットオーバー日に少なくとも5営業日を追加してください。根本原因を修正し、修正を確認するための別のシャドーインポートを実行し、再試行前にステークホルダーの承認を得る時間が必要です。再実行を急ぐと2回失敗することになります。

5時間目：本番稼働のコミュニケーション

QAが通過してゴーと判断したら、すぐにコミュニケーションを取ってください。

本番稼働コミュニケーションテンプレート

Slack / Teams（最初に送信）：

[名前]、チームの皆さん — [CRM名]が本番稼働しました。今すぐ新しいシステムの使用を開始できます。

簡単なメモ：

データは本日より[CRM名]に移行されました

何か見つからないものがあれば、#crm-supportに投稿してください。お手伝いします

[ソースCRM]は読み取り専用モードで、過去の参照のために30日間アクセス可能です

初日の質問の担当者：[名前] — 直接またはは#crm-supportで連絡してください

メール（本番稼働から30分以内に送信）：

件名：[CRM名]が本番稼働しました — 必要なことは何ですか

移行が完了しました。今から[CRM名]はすべての営業活動のシステム・オブ・レコードです。

今日することが必要なこと：

[メール/SSO]の資格情報を使用して[URL]の[CRM名]にログインする

オープンな取引が正しいステージと金額を表示していることを確認する

何かおかしいと思ったら、[名前]（[連絡先情報]）に連絡してください。自分で修正しないでください

[ソースCRM]への読み取り専用アクセス： [ソースCRM]は[今日から30日後の日付]まで読み取り専用アーカイブとしてアクセス可能です。過去の活動の参照に使用してください。[ソースCRM]に新しいデータを入力しないでください。

初日サポート： [名前]は今日と明日に質問対応できます。Slack：#crm-support。メール：[アドレス]。

移行中のご協力ありがとうございました。

本番稼働判断から5分以内に両方のメッセージを送信してください。最終確認が終わるまで待たないでください。コミュニケーションのスピードが「システムは稼働中か？」という混乱を防ぐものです。

1〜3日目：カットオーバー後のモニタリング

本番稼働は終わりではありません。安定化期間の始まりです。担当者がQAがカバーしなかった方法でシステムを使い始めると、初日のよくあるエラーが表面化します。

日次モニタリングチェックリスト（1〜3日目）

1日目（本番稼働から2時間以内）：

ライブの担当者のオープンパイプラインから20件のレコードをスポットチェック — ステージ、コンタクト、金額は正しいか？
報告された問題の#crm-supportチャンネルを確認 — 15分以内にトリアージして対応
本番稼働後に作成された新しいレコードが正しく保存されていることを確認（基本的なCRM機能チェック）

1日目（終業時）：

報告された問題の件数 — データ品質、フィールドマッピング、ユーザーエラーに分類
修正が必要な問題（ユーザートレーニングではない）はあるか？根本原因を特定し、解決のためにログに記録
営業リーダーシップへのステータス更新：X件の問題が報告され、Y件が解決され、Z件が進行中

2〜3日目：

問題ログの日次確認 — 同じ問題が繰り返されているか？繰り返される問題は一度限りの問題ではなく、体系的なマッピングエラーを示唆する
取引ステージベースの自動化が正しくトリガーされていることを確認（ステージを移動する新しい取引が正しいシーケンスをトリガーするべき）
レポートの正確性を確認：パイプラインレポートは担当者が自分のパイプラインで報告するものと一致しているか？

初日のよくあるエラーと修正：

エラー	原因の可能性	修正
コンタクトが間違ったライフサイクルステージを表示	ピックリストマッピングで値が見落とされた	レコードを手動で更新し、類似のレコードのマッピング文書を修正
取引金額が$0またはテキストで表示	通貨フィールドのタイプ変換が失敗した	レポートフィルターで影響を受けるレコードを見つけ、金額を一括更新
コンタクトの活動履歴が欠落	活動のインポートが失敗したかリレーションシップが解決されなかった	そのコンタクトIDのインポートログを確認。影響を受けるレコードの活動を再インポート
担当者が自分の割り当てレコードを見られない	ユーザー割り当てフィールドが正しく解決されなかった	移行先の管理パネルで一括再割り当て
自動化シーケンスがトリガーされない	パイプラインのステージ名が自動化トリガー条件と一致しなかった	新しいステージ名に一致するように自動化トリガーを更新

48時間ルール：ほとんどの初日の問題は48時間以内に表面化します。3日目までに問題について聞いていなければ、おそらく聞かないでしょう。3日間アクティブにモニタリングし、その後は週次チェックインのリズムに移行してください。

よくある落とし穴

ロールバック基準が定義されていない。 事前に定義された基準なしに、ロールバックの判断は危機の中での委員会の議論になります。チームは「孤立した取引の3%はロールバックに「十分悪い」のか」を担当者が待つ間45分間議論します。開始前に基準を定義してください。

データ凍結なし。 これがソースと移行先が乖離する方法です。担当者がインポート実行中の午前10時45分に取引を作成します。ソースにはありますが移行先にはありません。担当者は移行で作業が失われたと思います。完全に防げるモラルと信頼の問題です。

不十分な本番稼働QA。 インポートを終えて30分以内に本番稼働することは効率的に見えます。壊れた通貨フィールドや孤立した取引レコードを検出するQAがスキップされます。90分のQA窓口は価値があります。

初日サポートのDRIの未指名。 担当者に「誰かに聞いてください」というのはサポート計画ではありません。コミュニケーションに明示的に記載された一人の指名者が、直接連絡を受け取れます。その人は質問をその場で解決するか、エスカレーションします。先送りにしません。CRMのロールアウトと採用ガイドには、初日と2日目の構造化された担当者のオンボーディング計画があります。本番稼働のコミュニケーションを書く前に読む価値があります。

金曜日の午後のカットオーバー。 これは常に話題になります。担当者が「慣れる」ために週末を使えるように金曜日にカットオーバーするプレッシャーがあります。実際に起きることは：問題が金曜日の午後に表面化し、移行チームは週末に出かけ、担当者は月曜日に未解決のデータ問題を抱えます。火曜日または水曜日の朝にカットオーバーをスケジュールしてください。チームは新鮮で、サポートが利用可能で、問題は同じ営業日内に解決されます。パイプラインの継続性の観点からは、カットオーバー週の前にパイプライン衛生文化を読んでください。初日に担当者が新しいシステムのデータへの信頼を維持するために何が必要かが説明されています。

次のステップ

金曜日ではなく、火曜日または水曜日の朝にカットオーバーをスケジュールしてください。今日、T-マイナス48時間のカットオーバー前チェックリストを移行担当者に送り、すべての10項目に完了日が割り当てられていることを確認してください。

シャドーインポートがまだ承認されていない場合、カットオーバーをスケジュールしないでください。シャドーインポートの承認はこのガイドのすべての前提条件です。落ち着いたら、リードデータ管理の記事を次の移行で同じクリーンアップ作業が必要にならないような継続的なデータ品質プラクティスのベースラインとして使用してください。

Data Migration Guide