MAツールからHubSpotへ移行｜配信を止めない手順とオプトアウトの引き継ぎ

MAツールからHubSpotへの移行設計とは、移す対象を数え、やり直しが効かないものから順に片づけ、旧環境と新環境を並行させながら切り替える段取りを決める作業です。配信停止の引き継ぎと送信ドメイン認証を先に済ませ、段階的に切り替えれば、配信を止めずに移行できます。

「移行したら数週間、メールが送れなくなるのではないか」「以前に配信停止を選んだ人へ、移行後にまたメールが届いてしまうのではないか」——MAツールの乗り換えを検討している方から、移行前のご相談でよくうかがう不安です。

MAツールの乗り換えを検討するとき、多くの方が最初に気にするのは「データを全部移せるか」です。しかし実際の移行で事故が起きやすいのは、データではありません。配信の切り替えです。配信が止まった数週間、あるいは配信停止の意思表示が引き継がれずに旧オプトアウト者へメールが飛んだ。この2つが、MA移行で起きやすく、取り返しがつかない失敗です。

MA移行の設計は、データ移行の作業手順に見えますが、実際には「どの順番で何を止め、何を動かし続けるか」を決めるリスク設計です。この記事では、MAツールからHubSpotへ移行するときの設計を、配信を止めない観点から整理します。不動産のように物件提案メールや反響後の自動フォローを日常的に回している事業では、配信の空白がそのまま機会損失になるため、特に順序が重要になります。

この記事でわかること

MAの乗り換えを検討している方、移行プロジェクトの計画を立てる立場の方に向けて、配信を止めない移行の進め方を整理しました。次の4点がわかります。

• 移行対象の棚卸しの型 — 6種類に分けて数えると、移行の規模と期間が読めるようになります
• オプトアウト情報の引き継ぎ — なぜこれを最優先で設計するのかと、実際の移し方を説明します
• 送信ドメイン認証を先に済ませる理由 — DNSの変更は当日にできる作業ではありません
• 並行運用での切り替え手順 — 一斉切替をしないための3フェーズの進め方を示します

移行計画を任されている方、日常の配信を回しながら切り替えを進める方に向けて書いています。最後まで読むと、自社の移行計画をどの順序で組むかの判断ができるようになります。

MA移行で本当に難しいのは「止めないこと」

まず、移行の難所がどこにあるのかを整理します。難しさの中心は、データの移し替えではなく、配信という動き続けているものの切り替えにあります。

移行の失敗はデータではなく配信で起きる

コンタクトデータの移行は、CSVで出して入れるだけの作業です。項目のマッピングに手間はかかりますが、失敗しても入れ直せます。やり直しが効く作業です。

一方、配信は違います。オプトアウト者へ誤って送ってしまったメールは取り消せません。配信が止まっていた期間の機会損失も戻ってきません。やり直しが効かない領域から先に設計するのが、移行計画の原則です。

配信を止めると取り返せない業務がある

不動産のように、反響後の自動フォローや新着物件の案内を日常的に回している事業では、配信の空白がそのまま反響の取りこぼしになります。「移行中なので2週間止めます」という判断は、実質的に2週間分の追客を放棄することを意味します。

シナリオ配信を持っている場合、止めた期間に該当したリードは、後から遡って配信することができません。タイミングに意味がある配信ほど、この損失は大きくなります。

「一斉に切り替える」はなぜ危険なのか

移行日を決めて全部を一度に切り替える計画は、一見すると分かりやすいのですが、問題が起きたときに戻せません。旧環境を止めた後に不備が見つかると、復旧の手段がなくなります。

現実的な進め方は、並行期間を設けて段階的に移す形です。一気に切り替えるより工数はかかりますが、並行期間の費用は、事故のリスクに対する保険と考えるのが妥当です。

移行対象の棚卸し

計画の最初にやるべきは、移す対象を数えることです。感覚で「だいたい移せる」と判断すると、期間の見積もりが大きく外れます。次の図は、MA移行でよく出てくる対象を6区分に分け、件数・移行方法・移さない判断の3列で整理した棚卸しのイメージです。

これは特定の企業の移行案件ではなく、MA移行でよく出てくる対象を一般化した整理例です。

6区分で数える

ここで大事なのは、「ある数」と「使われている数」を分けて数えることです。多くの環境では、シナリオもリストも、実際に動いているのは全体の一部にとどまることが珍しくありません。

「移さないもの」を決めるのが棚卸しの本質

全部を移そうとすると、移行期間は大幅に伸びます。棚卸しの目的は、移さないものを決めることです。

判断の基準はシンプルで、「直近90日で1度も発火・使用されていないものは移さない」で十分です。必要になったときに作り直すほうが、使われるかどうか分からないものを移すより工数を抑えられます。

棚卸しの結果、動いているシナリオが少ないと分かれば、まずその少数から移し始めて段階的に広げる進め方が取れます。全部を同時に扱う必要はありません。

最優先はオプトアウト情報の引き継ぎ

移行の設計で最初に決めるべきは、配信停止の意思表示をどう引き継ぐかです。コンタクト本体より先にここを固めておかないと、移行直後の配信で信頼を損ないます。次の図は、旧環境の配信停止リストを書き出し、購読タイプの設計を経て、テスト配信で除外を確認するまでの流れです。

なぜこれを最初に決めるのか

配信停止は、受け手が意思表示したものです。移行時に引き継がれないと、以前に配信停止を選んだ人に再びメールが届きます。これは信頼を損なうだけでなく、迷惑メール報告につながり、移行後の到達率そのものを下げます。

HubSpotでは、コンタクトの配信登録を配信カテゴリー（購読タイプ）の単位で管理します。個別レコード、一括更新、ワークフローのいずれからでもオプトイン・オプトアウトを制御できます（コンタクトのメッセージング配信登録の管理）。

配信停止はインポートで引き継げます

同じ公式ドキュメントには、インポートを通じてコンタクトのグループをオプトアウトできると記載されています。旧環境から配信停止者のリストを書き出し、コンタクト移行と同じタイミングでオプトアウト状態を設定するのが基本の流れです。

注意点として、手動でオプトアウトしたコンタクトを、ワークフロー経由で再登録することはできません。一度オプトアウトとして入れたものを機械的に戻すことはできない前提で、リストの精度を確認してから流し込んでください。

購読タイプの設計を先に決める

引き継ぐ前に決めておくべきなのが、購読タイプの構成です。旧環境で「全配信停止」しか持っていなかった場合でも、HubSpot側では用途別に分けて設計できます。

どこまで細かく分けるかの最適な形は、企業様の配信の種類によって異なります。不動産であれば、たとえば「新着物件のご案内」「セミナー・イベント案内」「契約後のお知らせ」といった分け方が考えられます。分けておくと、片方だけ止めたい人を全停止にせずに済み、配信対象が痩せていくのを抑えられます。用途が少ない環境なら、まず2〜3区分から始めて、運用しながら見直す進め方で十分です。

ただし、旧環境の「全配信停止」を新しい購読タイプのどれに割り当てるかは慎重に決めてください。安全側の判断は、すべての購読タイプでオプトアウトにすることです。細かく分けたいなら、移行後に本人の意思で選び直してもらう導線を用意するほうが誠実です。

送信ドメイン認証を先に済ませる

配信を止めないためには、DNSの準備を移行日より前に終わらせておく必要があります。申請から反映まで時間がかかる領域のため、計画の早い段階で着手する対象です。

必要なDNSレコード

HubSpotでEメール送信ドメインを接続する際は、DKIM用のCNAMEレコードが2件、SPFとDMARC用のTXTレコードがそれぞれ1件必要です（Eメール送信ドメインを接続する）。この機能は Marketing Hub・Sales Hub・Service Hub・Content Hub の Starter 以上で利用できます。

認証の全体像はEメール認証の概要にまとまっています。認証が整っていない状態で配信を始めると、到達率が落ちます。

移行直前ではなく、事前に

DNSの変更は、社内の情報システム部門や外部のベンダーに依頼が必要なことが多く、申請から反映まで日数がかかるのが普通です。移行の1〜2週間前に着手しても間に合わないケースがあります。

計画を立てた最初の週に、DNSの管理権限が誰にあるかを確認してください。ここが不明なまま進むと、切り替え当日に止まります。既存のSPFレコードに他のサービスが登録されている場合、追記の仕方を誤ると既存の配信が止まるため、変更内容のレビューも必要です。

並行運用で段階的に切り替える

準備が整ったら、切り替えです。一斉ではなく、準備期・並行期・移行完了期の3つのフェーズに分けます。次の図は、3フェーズの中で旧環境と新環境それぞれに何を動かすかを並べたタイムラインのイメージです。

フェーズ1：準備期（旧環境が正）

コンタクトを移し、購読タイプを作り、ドメイン認証を通す期間です。新環境ではまだ配信しません。テスト配信のみを行い、自社の受信箱に届くこと、認証が通っていることを確認します。

この段階で、旧環境の配信は一切変えません。

フェーズ2：並行期（新規から新環境へ）

新しく発生するリードだけを新環境で扱い始めます。既存のシナリオは旧環境で動かし続けます。

二重配信を防ぐ工夫が要ります。同じ人が両方の環境で配信対象にならないよう、新環境に入れる対象を「移行開始日以降に作成されたコンタクト」に限定するのが分かりやすい方法です。旧環境側でも、その日以降の新規登録を停止します。

フェーズ3：切り替え完了（旧環境を停止）

旧環境で動いていたシナリオを新環境に作り終え、対象者を移し切った時点で旧環境の配信を止めます。ここで初めて、旧環境の契約解除を検討します。

旧環境は、配信を止めた後も1〜2か月は残すことをおすすめします。過去の配信履歴や、移行漏れの確認に必要になる場面があります。

何をもって切り替え完了とするか

「全部移した」ではなく、「旧環境で今週発火したシナリオが0本になった」を完了条件にすると、判定が明確になります。件数で見ると、移し忘れたシナリオが静かに動いている状態を見逃しません。

担当者の記憶や感覚ではなく数値で判定する形にしておくと、担当が変わっても同じ基準で進められます。移行のような長期の作業ほど、人ではなく仕組みで完了を判断する設計が有効です。

シナリオは1対1で移植しない

移行で工数を食いやすいのがシナリオ（ワークフロー）です。ここに考え方の違いが出ます。

移植すると「使われていないシナリオ」まで運ぶ

旧環境のシナリオを1本ずつ同じ形で作り直す方式は、一見すると安全に見えますが、動いていないシナリオまで運ぶことになります。しかも、旧ツールと HubSpot では条件の書き方や実行の仕組みが違うため、同じ形にしようとするほど不自然な構成になります。

移行は棚卸しの好機

現実的なのは、「今、何を自動化したいか」を白紙から書き出し、それに必要なワークフローだけを作る進め方です。旧環境のシナリオは参考資料として見るに留めます。

多くの場合、棚卸しを経るとシナリオの本数は大きく絞られます。動いていなかったものが落ち、重複していたものが統合されるためです。

作る順序

HubSpotのワークフローは、レコードの作成やプロパティーの変更をトリガーに実行できます（ワークフローを作成する）。作る順序としては、①新規リードへの初回フォロー → ②担当者への通知 → ③期限超過の検知 → ④長期育成の配信が扱いやすい並びです。

HubSpotのワークフローはメール配信だけでなく、コンタクトの登録から取引（商談）の作成、担当者への通知まで、コンタクト→取引→顧客という全体フローの各所で動きます。移行で作るシナリオも、配信の再現だけでなく、その先の商談管理や顧客対応とのつながりまで意識して設計すると、移行後の運用が一本につながります。

初めてワークフローを組む場合は、HubSpotのAI機能（Breeze）などに叩き台を作らせてから手動で整える進め方も、取っ掛かりとして有効です。ただし配信条件や停止条件の最終確認は人が行い、確認してから有効化してください。

反響からの一次対応を自動化する設計は不動産の追客管理をCRMで設計する、リードの割り当てはリードの傾斜配布をCRMで自動化するで扱っています。

フォームとランディングページの切り替え順序

配信と並んで、外部に露出している部分の切り替えにも順序があります。入口となるフォームとページ本体では影響範囲が違うため、替える順番を分けて考えます。

フォームを先、ランディングページを後

フォームはCRMへの入口なので、先に切り替えます。既存のページに新しいフォームを埋め込み、送信先だけを新環境に変える。この段階ではページのURLは変わらないため、外部からの流入に影響しません。

ランディングページごと移すのは、フォームの動作が安定してからで構いません。ページのURLが変わると、リダイレクトの設定や外部リンクの張り替えが必要になり、移行の難易度が一段上がります。

旧フォームはすぐに消さない

切り替え後も旧フォームは1か月ほど残し、送信があったら通知が飛ぶ状態にしておいてください。どこかのページに古い埋め込みが残っていた場合、これがないと問い合わせが行方不明になります。

反響取り込み全体の設計は不動産ポータルの反響をCRMに取り込む、移行先のデータ構造をどう組むかは不動産CRMのデータ設計と不動産業界のHubSpot活用ガイドでも扱っています。

体制と期間をどう見積もるか

移行は技術的な作業ではなく、判断の連続です。誰が判断するかを決めておかないと、途中で止まります。

必要な役割は3つ

規模が小さければ1〜2人が兼ねて構いませんが、「移さないものを決める権限」を持つ人だけは明確にしてください。ここが曖昧だと、現場が「念のため全部移す」という判断に流れ、期間が倍になります。

期間の目安

動いているシナリオの本数を基準に見積もるのが実用的です。

ここに、DNSの申請にかかる日数と、繁忙期を避けるための待ち時間が加わります。「準備」に見えない待ち時間が見落とされやすいため、計画には余白を持たせてください。

移行中も日常業務は止まらない

見落とされがちですが、移行期間中も通常の配信と反響対応は続きます。設定担当が本業と兼務の場合、移行に割ける時間は週の2〜3割程度が現実的です。この前提を置かずにスケジュールを引くと、遅れが重なりやすくなります。

移行後に数字が落ちる理由と、その読み方

移行後、しばらく指標が悪化します。これは失敗ではなく、想定内の変動として扱ってください。落ちる理由と数字の読み方を先に決めておくと、移行の成否を落ち着いて判断できます。

開封率・クリック率は一時的に下がります

送信元のドメインやIPが変わると、受信側の評価が積み上がるまでに時間がかかります。配信量を徐々に増やす進め方が推奨されるのはこのためです。

移行直後の1〜2か月の数字を、移行前と直接比較しない。比較するなら、3か月目以降の安定した数字を使ってください。

計測が途切れる期間をどう扱うか

トラッキングの仕組みが変わるため、流入の計測にも段差が出ます。移行の実施日を記録しておき、レポートを見るときにこの日を境に別々に見る運用にすると、誤った判断を避けられます。

移行の効果は「配信できる相手の数」で見る

短期の開封率よりも、購読タイプの整理によって配信対象が維持できているか、新規のリードが取りこぼされずに入っているかを見るほうが、移行の成否を正しく判断できます。

よくある質問

MA移行について、ご相談の場でよくいただく質問をまとめました。

Q1. 並行運用の期間はどれくらい必要ですか。

シナリオの本数と配信頻度によりますが、動いているシナリオが5本以下であれば1〜2か月、それ以上であれば2〜3か月を見ておくと安全です。短くするより、旧環境を早く止めないことのほうが重要です。並行期間を削って事故を起こすと、復旧に同じだけの時間がかかります。

Q2. 過去の配信履歴は移行できますか。

一般に、メールの配信履歴や開封・クリックのログをそのまま新環境へ移すことはできません。集計値としてCSVで保存しておき、必要に応じて参照する形が現実的です。履歴が消えることを前提に、旧環境の契約終了前に必要なレポートを書き出しておくことをおすすめします。

Q3. コンタクトのスコアはどう扱えばよいですか。

旧環境のスコアをそのまま持ち込んでも、算出ロジックが違うため意味が変わります。数値としては参考値のプロパティーに保管し、HubSpot側では新しく設計し直すのが基本です。移行を機に、スコアの項目が実際に商談化と相関しているかを見直す価値があります。

Q4. 旧環境と新環境で同じメールが二重に届く事故は、どう防げますか。

対象者を日付で明確に分けるのが基本の対策です。「移行開始日以降に作成されたコンタクトのみ新環境」と決め、旧環境側では新規の取り込みを止めます。加えて、並行期間中は毎週、両環境の配信予定を突き合わせる運用を置いてください。仕組みだけでは防ぎきれない部分が残ります。

Q5. 移行のタイミングとして避けたほうがよい時期はありますか。

繁忙期は避けてください。不動産であれば、繁忙期に移行のトラブルが重なると影響が大きくなります。もう1つ避けたいのが、担当者が異動する直前です。旧環境の設定意図を知っている人がいなくなると、棚卸しの精度が落ちます。移行は、設定を作った人が在籍しているうちに始めるのが理想です。

まとめ

MAツールの移行は、データの移し替えではなく、配信を止めないための段取りです。要点を整理します。

• やり直しが効かない領域から設計する。オプトアウトの引き継ぎと送信ドメイン認証が、コンタクト移行より先に来ます
• 棚卸しの目的は「移さないものを決める」こと。直近90日で動いていないシナリオとリストは、移さずに作り直すほうが工数を抑えられます
• 配信停止はインポートで引き継げる。ただし一度オプトアウトにしたものは機械的に戻せないため、リストの精度を先に確認します
• 一斉切替をせず、準備期・並行期・完了期の3フェーズで進める。完了条件は「旧環境で今週発火したシナリオが0本」で判定します
• シナリオは1対1で移植しない。今何を自動化したいかを白紙から書き出すと、多くの場合は本数が減って運用が軽くなります

最初の一歩としておすすめしたいのは、「旧環境で直近90日に1回でも発火したシナリオを数え、その一覧を書き出す」ことです。この本数が、移行の実質的な規模になります。全体の本数ではなく、動いている本数から計画を立てるほうが、期間の見積もりが現実に近づきます。

そのうえで、次の順に進めると計画が立てやすくなります。

1. まず動いているシナリオの一覧と配信停止者リストを書き出し、移行の実質規模を把握する
2. DNSの管理権限が誰にあるかを確認し、送信ドメイン認証の申請ルートを押さえる
3. 購読タイプの構成案を作り、並行期の開始日と完了条件（週の発火0本）を関係者で合意する

この3点がそろえば、移行計画の骨格はほぼ決まります。自社のMA移行の進め方を具体的に検討したい場合は、StartLinkの無料相談もご活用ください。CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• 不動産の追客管理をCRMで設計する
• リードの傾斜配布をCRMで自動化する
• 不動産ポータルの反響をCRMに取り込む
• 不動産CRMのデータ設計
• 不動産業界のHubSpot活用ガイド