MAツールからHubSpotへ移行する設計｜配信を止めずに移す手順とオプトアウトの引き継ぎ

MAツールの乗り換えを検討するとき、多くの方が最初に気にするのは「データを全部移せるか」です。しかし実際の移行で事故が起きるのは、データではありません。配信の切り替えです。

配信が止まった数週間、あるいは配信停止の意思表示が引き継がれずに旧オプトアウト者へメールが飛んだ。この2つが、MA移行で最も起きやすく、最も取り返しがつかない失敗です。

MA移行の設計とは、移す対象を数え、やり直しが効かないものから順に片づけ、旧環境と新環境を並行させながら切り替える段取りを決める作業です。データ移行の作業手順に見えますが、実際には「どの順番で何を止め、何を動かし続けるか」を決めるリスク設計です。

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

MAの乗り換えを検討している方、移行プロジェクトの計画を立てる立場の方に向けた内容です。次の4点がわかります。

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

読み終える頃には、自社の移行計画をどの順序で組むかの判断ができる状態になります。ぜひ最後までご確認ください。

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

まず、移行の難所がどこにあるのかを整理します。

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

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

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

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

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

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

「一斉に切り替える」が最も危険

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

並行期間を設けて段階的に移す。これが唯一の現実解です。並行期間の費用は、事故のリスクに対する保険と考えるのが妥当です。

移行対象の棚卸し

計画の最初にやるべきは、移す対象を数えることです。感覚で「だいたい移せる」と判断すると、期間の見積もりが大きく外れます。

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

6区分で数える

ここで大事なのは、「ある数」と「使われている数」を分けて数えることです。多くの環境では、シナリオもリストも、実際に動いているのは全体の3割程度です。

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

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

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

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

移行の設計で最初に決めるべきは、配信停止の意思表示をどう引き継ぐかです。

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

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

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

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

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

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

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

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

不動産であれば、たとえば「新着物件のご案内」「セミナー・イベント案内」「契約後のお知らせ」といった分け方が考えられます。分けておくと、片方だけ止めたい人を全停止にせずに済み、配信対象が痩せていくのを抑えられます。

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

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

配信を止めないためには、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つのフェーズに分けます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

移行は棚卸しの好機

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

多くの場合、10本以上あったシナリオが3〜4本に集約されます。動いていなかったものが落ち、重複していたものが統合されるためです。

作る順序

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

反響からの一次対応を自動化する設計は不動産の追客管理を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回でも発火したシナリオを数え、その一覧を書き出す」ことです。この本数が、移行の実質的な規模になります。全体の本数ではなく、動いている本数から計画を立てるほうが、期間の見積もりが現実に近づきます。

そのうえで、DNSの管理権限が誰にあるかを確認する。この2つが終われば、移行計画の骨格はほぼ決まります。

自社のMA移行の進め方を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の環境をうかがったうえで、移行の順序と期間の目安をご提案します。