HubSpot移行の切り替え計画の立て方｜並行稼働の範囲・データ凍結・切替日・ロールバック条件を決める実務手順

私たちが大手企業のHubSpot移行を支援する際、切り替え計画書は要件定義や基本設計とは別の独立したドキュメントとして作成しています。理由は単純で、切り替えは「作業の手順書」ではなく「意思決定の事前合意」だからです。当日に必要なのは手順の正しさではなく、誰が何を根拠に止める・進める・戻すを決めるかの合意です。本記事では、その計画書に何を書き、どの数字を根拠に判断するのかを、HubSpotの公式仕様に即して具体的に示します。

なお、移行プロジェクト全体の進め方（費用・期間・工程）についてはSalesforceからHubSpotへの移行ガイドで整理しています。本記事はその最終盤、カットオーバーの一点に絞って解説します。

なぜ切り替え計画は「作業手順書」ではなく「意思決定の計画」なのか？

切り替えで失敗するプロジェクトは、手順を間違えて失敗するのではありません。想定外が起きたときに、判断を下せる人が会議の場にいない、あるいは判断の基準が共有されていないために時間が溶けます。IPA（情報処理推進機構）が公開しているシステム再構築を成功に導くユーザガイドでも、移行の失敗要因として、ユーザー企業側の役割と責任の不明確さが繰り返し指摘されています。切り替え計画書は、この責任分界を切替日の前に文章で固定する道具です。

私たちが計画書の冒頭に必ず置くのは、手順ではなく「判断者の表」です。システム停止、ロールバック発動、暫定運用への切り替え、顧客への告知。この4つについて、一次判断者・最終決裁者・代理者を実名で書きます。代理者を書かない計画書は、当日に決裁者が別件の会議に入った瞬間に機能しなくなります。

切り替え計画書には何を書けば、当日の判断が止まらないのか？

項目を網羅すること自体が目的ではありません。重要なのは、各項目が「誰かが当日に悩む論点」に対応していることです。実務で紛糾するのは、だいたい次の表にある項目のどれかです。この表は、私たちが実際に使っている切り替え計画書の目次をそのまま項目化したもので、上から順に合意を取っていくと、後工程で前提が崩れにくくなります。

誰が「止める」判断を持つべきか？

ロールバックの決裁は、プロジェクトマネージャーではなく業務側の責任者に置くことをお勧めしています。ロールバックは技術的な巻き戻しではなく、業務を旧システムで回し続けるという経営判断だからです。プロジェクトマネージャーに決裁を預けると、「ここまで作ったのだから進めたい」という力学が働き、判断が遅れます。

同時に、一次判断者には技術側の担当を置きます。データ不整合の規模を数えられるのは技術側だけで、業務側の責任者が自力で状況を把握するのは現実的ではありません。一次判断者が事実を数字で提示し、業務側の責任者が業務影響で決める。この二段構えを計画書に明記します。

並行稼働はどの範囲で、どれだけの期間やるべきか？

並行稼働を「安全策」として無条件に採る提案を見かけますが、実務では逆に事故を増やすことがあります。二重入力が発生した瞬間に、どちらが正なのか分からないレコードが生まれるためです。SSOT（信頼できる唯一の情報源）を目指して移行しているのに、並行稼働期間中だけ情報源が二つになるという矛盾が起きます。

私たちが並行稼働を設計する際は、期間ではなく「範囲」から決めます。全業務を並行させるのではなく、止まると売上に直結する業務だけを並行させ、それ以外は一括で切り替えます。範囲を絞れば、二重入力の対象レコード数が減り、現場の負荷と差分照合のコストが同時に下がります。

並行稼働の「範囲」をどう切るか？

範囲を切る軸は業務機能ではなくレコードのライフサイクルです。進行中の商談だけを並行させ、終了済みの商談は参照専用として旧システムに残す、という切り方が最も扱いやすくなります。進行中の商談は件数が有限で、担当者が特定でき、クローズすれば自然に並行稼働から抜けていくためです。

この切り方を採る場合、計画書に書くべきは「並行対象の判定条件」です。取引ステージが特定の段階より手前のもの、クローズ予定日が切替日以降のもの、といった形で条件を書き、切替日前日時点の該当件数を実数で把握します。件数が分からないまま並行稼働を始めると、照合作業の工数が見積もれません。

並行稼働の期間は何で決まるのか？

期間は「現場が慣れるまで」ではなく、業務サイクルの長さで決めます。月次の締め処理が1回通ること、進行中商談の大半がクローズすることの2点が、並行稼働を終える客観的な条件になります。カレンダー上の日数で決めると、締め処理を一度も通さずに並行稼働を終えてしまい、月末に初めて不具合が見つかるという順序になります。

延長の判断基準も先に決めておきます。私たちは、差分照合で不一致が出た件数が閾値を超えた場合のみ延長する、という形で基準を置いています。基準が無いと、「不安だからもう1か月」が繰り返され、二重入力の疲弊が定着率そのものを下げます。

二重入力の負荷をどこで吸収するか？

並行稼働期間中の二重入力を営業担当に負わせると、ほぼ確実にどちらか片方が形骸化します。私たちが支援する案件では、片側への転記を営業事務や推進事務局が引き受ける体制を敷き、営業担当の入力先はHubSpot一本に寄せます。入力先を一本にしておけば、並行稼働が終わったときに習慣を変える必要がありません。

転記を人手で回す以上、転記漏れは必ず発生します。発生を前提に、日次で件数と主要項目を突合する手順を計画書に入れておきます。HubSpot側の突合には、カスタムレポートビルダーで作成した件数レポートを使い、旧システム側の抽出結果と並べる形が最も軽量です。

データ凍結（フリーズ）はいつ、何を止めるのか？

凍結で止めるべきなのはレコードではなく、レコードを更新する経路です。人の手入力だけを止めても、連携バッチ・Webフォーム・メール配信の自動処理・外部ツールの同期が動いていれば、移行中にデータは変わり続けます。凍結計画は「更新経路の棚卸し表」から始めます。

棚卸しの単位は、経路ごとに「止め方」「止めるのに必要な権限」「止めたことの確認方法」「解除手順」の4点です。止め方が分からない経路が1本でも残っていると、凍結宣言をしても実際には凍結できていない状態になります。

HubSpot側の自動処理は、どう止めれば止まるのか？

ここで最も誤解が多いのがワークフローの扱いです。ワークフローをオフにすると新規の登録は止まりますが、すでに登録済みのレコードは登録されたまま残り、アクションは実行されないものの待機（ディレイ）はスキップされません。つまりオフは「一時停止」ではありません。長い待機を含むワークフローをオフにしても、待機時間は進み続けます。

特定の日にアクションを実行させたくない場合は、オフではなく一時停止日（pause dates）を使います。切替日とその前後を一時停止日に指定しておけば、登録済みレコードのアクション実行を日付単位で抑えられます。私たちが凍結計画を作るときは、この2つを使い分けて表に書き分けています。

凍結はいつ始め、差分はどう拾うのか？

凍結開始時刻は、移行対象データの最終抽出時刻から逆算します。抽出に数時間かかるのであれば、抽出開始より前に凍結していなければ、抽出中に更新されたレコードが取りこぼされます。計画書には「凍結開始時刻」と「最終抽出の開始・終了予定時刻」を並べて書き、前者が確実に先になっていることを確認します。

凍結期間をゼロにはできないため、差分（デルタ）の扱いを決めておきます。凍結中に発生した更新要求は、紙やスプレッドシートで受け付けて切替後にまとめて反映する運用が現実的です。この際、HubSpotへの一括反映には、インポートファイルの作成手順に従ったファイルを使います。1ファイルあたり1,048,576行・512MB（有料アカウントの場合）、列数は1,000列未満、1日あたり1,000万行が上限です。差分反映の規模がこの上限に触れることはまずありませんが、初期移行の本体側では確認が必要です。上限値は改定されることがあるため、実行前に現行値を見ておいてください。

切替日はどう決めるのか？締め処理・期末を避ける判断基準

切替日は「システム側の準備が整う日」から決めてはいけません。業務カレンダー上で切ってはいけない日を先に塗りつぶし、残った日から選びます。順序を逆にすると、月次の締め処理と重なった切替日が決まってしまい、経理と営業の両方から差し戻されます。

塗りつぶすべき日は業種によって違いますが、BtoBの製造業・情報通信業では次の期間が共通して外れます。月末3営業日と月初3営業日（請求・締め処理）、四半期末と期首（決算・予算）、全社的な繁忙期（決算期前の駆け込み、展示会直後のリード処理）、主要顧客の締め日。この4つを営業・経理・情報システムの3部門から集めて1枚のカレンダーにします。

会計年度やパイプラインの区切りと、どう合わせるか？

HubSpot側では、会計年度の開始月をアカウント設定で指定できます。既定は1月から12月で、アカウントのデフォルト設定から変更できます。日本企業の多くは4月開始であるため、この設定は移行作業ではなく初期設定の段階で済ませておくべき項目です。

切替日を会計年度の切れ目に合わせると、レポートの連続性が保ちやすくなる一方で、期首は予算策定や人事異動と重なり、現場の学習余力が最も小さい時期でもあります。私たちは、レポートの連続性よりも現場の余力を優先し、期首を避けた月の中旬に切替日を置く提案をすることが多くあります。レポートの断絶は旧システムの実績を取り込むことで後から埋められますが、定着の失敗は後から埋められません。

曜日と時刻はどう決めるか？

切替作業そのものは週末に置き、切替後の最初の営業日を火曜日か水曜日にする形をお勧めしています。月曜に初日を置くと、週明けの問い合わせの山と切替直後の混乱が重なります。また、金曜を初日にすると、不具合が見つかったときに対応できる営業日が1日しか残りません。

見落とされがちなのがDNS関連の時間です。メール送信ドメインの認証を切替に合わせて変更する場合、DNSレコードの反映には通常10分から70分、場合によっては48時間かかることがあります。切替当日にDNS変更を入れる計画は、この48時間を吸収できません。

切り戻し（ロールバック）は、どの条件で発動し、どこまで戻せるのか？

ロールバックで最も重要なのは手順ではなく発動条件です。条件が無いまま当日を迎えると、不具合が出るたびに「これは戻すほどではない」という解釈が積み重なり、気づいたときには戻せる時間帯を過ぎています。条件は定性的な表現ではなく、件数と時刻で書きます。

私たちが使っている判定の型は、確認項目ごとに閾値を置き、1つでも超えたら自動的に保留、2つ超えたらロールバック決裁に上げる、というものです。閾値そのものは案件ごとに変わりますが、「誰かが判断する」ではなく「超えたら機械的に上げる」という構造を作ることが要点です。

HubSpot側で実際に戻せるものと、戻せないものは何か？

ロールバック計画は、HubSpotの復旧機能で何がどこまで戻るのかを正確に把握したうえで書く必要があります。戻せない操作を「戻せる」前提で計画すると、発動した瞬間に計画が破綻します。以下は、HubSpotの機能ごとの復旧可否の整理です。読み方のポイントは、期限の長短よりも「取り消し不可」の行がどこにあるかです。

この表で切り替え計画に直結するのは、マージが取り消せない点と、プロパティー更新の巻き戻しが直近14日に限られる点の2つです。名寄せのためのマージを切替作業の中に組み込むと、ロールバックしてもマージだけは戻りません。私たちは、マージは切替とは別日程に分け、切替後の安定稼働を確認してから実施する手順を標準にしています。

14日という制約は、並行稼働の期間設計にも効きます。並行稼働を1か月以上に設定し、その途中で初期移行データの誤りに気づいた場合、一括での巻き戻しは使えません。初期移行の検証は切替直後に集中させ、14日以内に判定を終える計画にします。なお復元のプレビューは準備後14日間アクションできる状態で残り、実行した復元は復元履歴テーブルに90日間保持されます。

「戻さない」判断（フォワードフィックス）の基準はどこに置くか？

実務では、ロールバックよりも「戻さずに前に進んで直す」判断のほうが多く選ばれます。ロールバックは旧システムの再稼働と、切替後にHubSpot側で発生した更新の破棄を伴うため、コストが小さくありません。計画書には、ロールバックの条件と並べて、フォワードフィックスを選ぶ条件も書いておきます。

私たちが基準にしているのは、影響範囲が特定できるか、手作業で復旧できる件数か、顧客に見えているかの3点です。影響範囲が特定でき、件数が有限で、顧客に見えていないのであれば、戻さずに直すほうが早く終わります。逆に、顧客向けのメール配信やフォームの挙動に影響が出ている場合は、件数が小さくてもロールバックを含めた検討に上げます。

関係部署への連絡設計は、どう組めば現場が止まらないのか？

切替の連絡は「全社メール1通」で済ませると必ず失敗します。情報の粒度が部門ごとに違うためで、営業は入力先の変更を、経理は締め処理への影響を、情報システムは連携の停止時刻を知りたがります。1通にまとめると、全員が自分に関係する行を探せません。

私たちが連絡設計を作る際は、宛先を4つに分けます。実務で毎日HubSpotを触る層、月次でレポートだけを見る層、連携システムを運用する層、そして顧客接点を持つが社内システムには関与しない層です。それぞれに必要な情報と、必要なタイミングが異なります。

当日のコミュニケーションは、チャットの専用チャンネルに一本化し、進捗を時刻付きで書き込む運用にします。口頭で共有すると、後からロールバック判断の根拠を再構成できません。切替後に振り返りを行う際、この時系列の記録がそのまま一次資料になります。

顧客に見える変化をどう扱うか？

切替によって顧客側に見える変化が生じる場合は、社内連絡よりも早く設計します。メールの差出人アドレスやドメインが変わる場合、フォームのURLや画面が変わる場合、問い合わせへの返信元が変わる場合が代表的です。いずれも、顧客からの返信先が変わるという意味を持ちます。

特にメール送信ドメインでは、他の用途で使用中のドメイン（ウェブサイトのホスティングなど）は認証できず、接続するサブドメインは送信元アドレスのドメインと一致している必要があります。切替直前にこの制約に気づくと、送信元アドレスの変更を顧客に告知する時間が取れません。

切替後の監視は、何をどれだけの期間見るのか？

切替作業が終わった時点では、まだ何も確認できていません。移行の成否が分かるのは、現場が実際に業務を回し始めてからです。監視項目は、データの静的な正しさではなく、業務が流れているかを測る指標に置きます。

私たちが切替後に見るのは、日次の新規レコード作成件数、ステージ遷移の発生件数、ワークフローの登録件数とエラー、ユーザーのログイン率の4つです。件数がゼロに近い項目があれば、データではなく運用が止まっています。ワークフローの稼働状況は、ワークフロー詳細ページや、レコード単位のワークフロー経路の確認から追えます。

設定変更そのものの追跡には、アカウントのアクティビティー履歴の表示とエクスポートが使えます。切替直後は複数の担当者が設定に触るため、「誰がいつ何を変えたか」を後から説明できる状態を保っておくと、原因切り分けの時間が大きく短縮されます。このあたりの運用設計は、CRM全社導入で失敗する企業と成功する企業で扱っているガバナンスの議論と地続きです。

切り替え計画の精度を上げるために、どの一次資料を参照すべきか？

切り替え計画はプロジェクト固有の事情に強く依存しますが、構成要素そのものは標準化できます。公的機関が公開している資料を土台にすると、社内の稟議や監査対応の場面で根拠を示しやすくなります。以下は、私たちが大手企業の計画書レビューで実際に参照している資料です。いずれも無償で公開されており、社内配布も可能です。

HubSpot側の仕様については、移行実務に直結する公式ページを計画書の付録として添付しておくことをお勧めします。オブジェクトのインポート、過去のインポートの確認、過去のインポートの再実行、CRMデータのバックアップと復元、CRMレコードの削除の5本は、切替当日に実際に開くことになるページです。

サンドボックスを使ったリハーサルを計画に含める場合は、先に制約を押さえておく必要があります。コンタクト・会社・取引・チケット・カスタムオブジェクトのIDはサンドボックスと本番で異なり、サンドボックス全体で1日あたり100,000レコードまでしかワークフローに登録できません。本番同等の負荷でのリハーサルには、この制約が効いてきます。サンドボックスの提供条件はHubSpot開発者ドキュメントのアカウント種別でも整理されています。

よくある質問（FAQ）

並行稼働をせずに一括で切り替えるのは危険ですか？

危険とは限りません。進行中の商談件数が少ない時期を選べて、旧システムを参照専用で残せるのであれば、一括切替のほうが二重入力による混乱を避けられます。判断材料は、切替日前日時点の進行中レコード件数と、旧システムを参照専用で残せるかどうかの2点です。

切替日を決めたあとで、業務部門から「その日は無理」と言われました。どうすべきですか？

日付そのものを交渉するよりも、その部門の業務だけ段階切替に切り出せないかを先に検討してください。全体の切替日を動かすと、連携ベンダーの作業枠やDNSの変更申請まで連鎖して動きます。1部門の都合で全体を動かす前に、範囲の分割で解けないかを確認する順序をお勧めします。

旧システムはいつ止めればよいですか？

切替直後に止める必要はありません。参照専用で一定期間残し、問い合わせ対応と監査対応に使える状態にしておきます。停止の判断は、参照回数の実測値で決めます。アクセスログが取れない場合は、問い合わせ窓口への照会件数で代替します。

ロールバックを発動したら、HubSpot側に入力されたデータはどうなりますか？

切替後にHubSpot側で入力されたデータは、旧システムには自動では戻りません。ロールバックの計画には、この期間にHubSpotへ入力されたレコードを抽出し、旧システムへ手作業で転記する手順を含めておく必要があります。この転記工数が大きいほど、ロールバックの実行コストは上がります。

凍結期間を短くするために、夜間に切り替えるのは有効ですか？

海外拠点や24時間稼働の問い合わせ窓口がある場合は、夜間でも更新が止まりません。拠点のタイムゾーンを並べて、全拠点で更新が最も少ない時間帯を実測で特定してください。国内のみの運用であれば、夜間よりも土日の日中のほうが、不具合発生時に人を集めやすくなります。

切り替え計画書は誰が承認すべきですか？

情報システム部門の承認だけでは不足します。凍結によって業務が止まる部門、切替後に入力作業が変わる部門、レポートの断絶の影響を受ける部門の責任者から、それぞれ承認を取ってください。承認の対象は計画全体ではなく、各部門に関係する章に限定すると、承認のサイクルが速く回ります。

サンドボックスでリハーサルをすれば、本番の切替はうまくいきますか？

リハーサルで確認できるのは手順の妥当性と所要時間であり、本番のデータ量や連携の挙動までは再現できません。サンドボックスの制約（レコードIDが本番と異なること、ワークフロー登録数の上限があること、本番の連携が自動では接続されないこと）を踏まえ、リハーサルで検証する範囲を事前に限定しておくことをお勧めします。

切替後に「元のシステムのほうが良かった」という声が出た場合、どう扱えばよいですか？

声の内容を、操作の不慣れによるものと、業務要件の欠落によるものに切り分けてください。前者はトレーニングと定着支援の問題で、後者は設計の問題です。切り分けずに対応すると、トレーニングで解決すべき事柄に追加開発の工数を使うことになります。切替後2週間の問い合わせ内容を分類し、件数の多い順に処理する運用をお勧めしています。

切り替え計画を自社だけで作り切れないときは

株式会社100は、HubSpotの認定エリートパートナーとして、大手企業のCRM移行プロジェクトで切り替え計画の設計とカットオーバー当日の推進を担っています。計画書のレビューだけ、あるいは当日の判断体制の設計だけといった部分的なご相談もお受けしています。お問い合わせよりご連絡ください。

本記事に記載したHubSpotの仕様・上限値は、2026年10月23日時点の公式情報に基づいています。仕様および上限は変更される可能性があるため、実際の計画策定時には各公式ページで最新の内容をご確認ください。