移行の意思決定は、たいてい比較表の段階で終わっています。機能はおおむね足りる、価格の見通しも立った、経営会議の承認も取れた。ところが実務に降りた瞬間、担当者の手が止まります。プロスペクトのCSVは出せるとして、Engagement Studioのプログラムはどうやって持っていくのか。スコアは引き継ぐのか、ゼロに戻すのか。配信停止にした人のフラグを取りこぼしたら、それは法令違反になるのか。

この段階で参照できる日本語の資料が、ほとんどありません。検索して出てくるのは比較記事ばかりで、移行の作業手順と判断基準を書いたものが見当たらない。結果として、移行の設計が「ベンダーに聞く」か「やりながら決める」のどちらかになります。

本記事は、Marketing Cloud Account Engagement（旧Pardot）からHubSpotへ移行する際に、何がデータとして持ち出せて、何を作り直す必要があるのかを工程順に整理したものです。製品の優劣は扱いません。どちらを選ぶかの比較はHubSpotとAccount Engagementの比較記事にて解説し、ここでは「移行すると決めた後」の設計だけを書きます。従業員1,000名規模で、Salesforceを基幹CRMとして運用しながらマーケティング基盤を入れ替える、という前提で読めるようにしています。

なぜ移行の見積もりは、比較検討のときより膨らむのか？

比較検討の段階で見ているのは機能の有無です。移行の段階で問われるのは、いま動いている仕組みを止めずに別の仕組みへ載せ替える手順です。この2つは別の作業で、後者のほうが時間を食います。

私たちがAccount Engagement（旧Pardot）からの移行を支援する際、工数の見積もりを3つに分けて出しています。データの移送、資産の再作成、そして並行稼働と切り替えの管理です。このうち最も見落とされるのが3つ目で、ここを工程に入れていない計画は、切替日の2週間前に必ず破綻します。

「エクスポートできる」と「移行できる」は、どこで分かれるのか？

Account Engagement（旧Pardot）からCSVで取り出せるのは、プロスペクトのレコードとその項目値、リストのメンバーシップ、一部のアクティビティです。プロスペクトのCSVエクスポートはプロスペクトページのツールから実行し、Account Engagement Administrator、Marketing、またはSales Managerのいずれかのロールが必要です（プロスペクトのエクスポートに関する公式ドキュメント、2026年10月23日取得時点）。

一方、フォーム、ランディングページ、メールテンプレート、Engagement Studioのプログラム、オートメーションルール、ダイナミックリストの定義は、他システムへそのまま移せる形式では出てきません。これらは「移行」ではなく「再作成」の対象です。見積もりが膨らむのはここで、資産の本数を数えずに期間だけ決めると、後から再作成の工数が丸ごと追加されます。

移行の対象を決めるとき、最初に数えるべきものは何か？

私たちが棚卸しの最初にやるのは、資産の本数を数えることではなく、直近12ヶ月で実際に稼働した資産を数えることです。運用歴が長い組織ほど、停止済みのプログラムと使われていないフォームが大量に残っています。全部を移そうとすると、使っていないものを作り直すために工数を払うことになります。

次の一覧は、資産の種類ごとに取り出し方と移行先、そして判断の勘所を整理したものです。注目すべきは右端の列で、ここが「そのまま移すか、作り直すか、捨てるか」の分岐になります。

プロスペクトのデータは、どの順序でHubSpotへ入れるのか？

データ投入は一発勝負にしないのが鉄則です。全件を一度に入れると、項目のマッピング誤りや文字コードの問題が全レコードに波及し、取り消しが利かない状態になります。私たちは必ず、少量の検証インポートを先に通してから本番投入に進みます。

HubSpot側の受け入れ条件は明確に定められています。インポートファイルは.csv、.xlsx、.xlsのいずれかで、列数は1,000未満、有料プランでは1ファイルあたり1,048,576行かつ512MBまでです。無料ツールのみの場合は20MBまで、1日あたり500,000行までという制限がかかります。アカウント全体では1日1,000万行、API経由では1日8,000万行が上限で、同時に処理できるインポートは3ファイルまで（1万行を超えるファイルは2つまで）です（インポートファイルの準備に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。大規模な移行では、API経由のインポートを使うほうが運用が安定します（インポートAPIに関するHubSpotの公式ドキュメント）。

項目のマッピング表は、どこまで細かく作るべきか？

項目名の対応だけを書いたマッピング表は、移行当日に役に立ちません。必要なのは、選択肢の値そのものの対応です。Account Engagement（旧Pardot）側で「見込みあり／検討中／見送り」と入っている選択肢を、HubSpot側でどの内部値に落とすかまで決めておかないと、インポート後に選択肢が増殖します。

私たちがマッピング表を作るときは、項目ごとに「移行元の項目名・型・選択肢の全値」「移行先のプロパティー内部名・型・選択肢の全値」「変換ルール」「移行しない場合の理由」の5列を持たせます。移行しない項目にも理由を書くのは、切替後に「あの項目はどこへ行ったのか」という問い合わせが必ず出るためです。

重複レコードは、移行の前と後のどちらで処理するのか？

移行の前です。HubSpotに入れてからマージする前提で設計すると、取り返しがつかない状態になります。HubSpotのレコードのマージは取り消せません。さらに、2つのレコードが関与したマージの累計が250回以上になると、それ以降マージできなくなります。マージ後は「Merged record IDs」プロパティーで、どのレコードが統合されたかを追跡できますが、統合そのものを戻す手段はありません（レコードのマージに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。マージ後、すべてのアクティビティーが同期するまで最大30分かかる点も、検証スケジュールに織り込んでください。

Account Engagement（旧Pardot）側で同一メールアドレスの複数プロスペクトを許可する設定を使っていた場合は、ここが特に危険です。HubSpotのコンタクトはメールアドレスで一意に扱われるため、どのレコードを正とするかを移行前に決め切る必要があります。名寄せの基準は、最終活動日ではなく「Salesforce側のレコードと紐づいているか」を第一基準にするのが実務的です。

スコアとグレードは、HubSpotでどう作り直すのか？

スコアは値ではなくロジックを移します。Account Engagement（旧Pardot）のスコアはそのシステムの既定点数の上に積み上がった数字であり、同じ数字をHubSpotに入れても意味が変わります。移行を機に、営業がスコアを実際に見て動いているかどうかを確認し、見ていないなら作り直す範囲を狭めるのが現実的です。

既定スコアの点数設計は、そのまま持ち込めるのか？

持ち込めません。両者は点数の付け方の粒度が違います。Account Engagement（旧Pardot）の既定スコアでは、フォーム送信とランディングページの成功がそれぞれ+50、商談の作成が+50、商談の失注が-100、動画を75%以上視聴で+25、ページビューが+1、フォームのエラーが-5といった値が初期設定されています。メールの開封は0点で、2014年4月11日以降にプロビジョニングされたビジネスユニットでは累積スコアリングが無効化され、最初の開封のみが評価されます（既定のスコアリングシステムに関する公式ドキュメント、2026年10月23日にブラウザで取得）。

HubSpotのリードスコアリングは、エンゲージメントスコア（行動）とフィットスコア（属性）を別々に持ち、両者を組み合わせた統合スコアも作れる構造です。コンタクトのスコアはMarketing Hub、会社のスコアはMarketing HubまたはSales Hub、取引のスコアはSales Hubが必要で、いずれもProfessional以上が前提になります（リードスコアリングツールに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。HubSpotのスコアリングの基礎もあわせてご確認ください。

グレード（A+〜F）に相当する仕組みは、HubSpotにあるのか？

フィットスコアが対応します。ただし表現形式が違います。Account Engagement（旧Pardot）のグレードはA+からFまでの尺度で、各段階は1文字の3分の1刻み、コンバージョン時点では既定でDが割り当てられます（プロスペクトのグレーディングに関する公式ドキュメント、2026年10月23日にブラウザで取得）。HubSpotのフィットスコアは数値であり、文字等級ではありません。

ここで「A+を90点、Aを85点」のように機械的に数値へ置き換えると、営業現場の運用が壊れます。グレードは本来「自社の理想顧客像にどれだけ合致しているか」を表す指標なので、移行時にやるべきは点数の換算ではなく、プロファイル条件の棚卸しです。業種・従業員規模・役職の3条件だけで8割の判別ができているなら、HubSpot側のフィットスコアもその3条件で組みます。

移行時にスコアをリセットすべきか、持ち越すべきか？

私たちが推奨しているのは、旧スコアを参照専用のカスタムプロパティーとして取り込み、新スコアはHubSpot側のロジックで初日からゼロベースで積み上げる方法です。旧スコアを新スコアの初期値に流し込むと、移行前の行動と移行後の行動が同じ尺度で混ざり、どちらの基準でホットなのかが説明できなくなります。

参照専用で残しておけば、切替後3ヶ月の時点で「旧スコア上位のうち何%が新スコアでも上位に入ったか」を検証できます。この検証結果は、スコアリングの閾値を営業と合意し直すときの材料になります。

オプトアウトと配信停止は、どう引き継ぐのか？

移行工程の中で、失敗したときの損害が最も大きいのがここです。データの移送漏れは後から追加で入れ直せますが、配信停止にした相手へ誤って広告メールを送ってしまった事実は取り消せません。この工程だけは、工数ではなくリスクで優先順位を決めてください。

「Do Not Email」と「Opted Out」は、何が違うのか？

Account Engagement（旧Pardot）は配信可否を1つのフラグで持っていません。プロスペクトの配信可否ステータスは、「Do Not Email」項目、「Opted Out」項目、そして過去のバウンス履歴の3つで決まります。どちらかの項目がtrueであればステータスは「Operational Emails Only」になり、マーケティングメールの対象外になります。さらに、ソフトバウンスが5回以上またはハードバウンスが1回あると「Undeliverable」となり、いかなるメールも送れません（プロスペクトの配信可否ステータスに関する公式ドキュメント、2026年10月23日にブラウザで取得）。

つまりエクスポートで1列だけ持ち出しても足りません。「Do Not Email」「Opted Out」「バウンス履歴」の3つを別々の列として取り出し、HubSpot側でどう表現するかを決める必要があります。ここを1列にまとめた時点で、情報が落ちます。

HubSpotの購読タイプとオプトアウトインポートは、どう使い分けるのか？

HubSpotには2つの層があります。1つはコンタクト単位の「Unsubscribed from all email」プロパティーで、すべてのマーケティングメールの対象外にする全停止のフラグです。もう1つは購読タイプ単位のオプトアウトで、「製品のお知らせは受け取るがイベント案内は不要」といった粒度を表現します（コンタクトの配信停止状況の確認に関するHubSpot公式ナレッジベース）。

外部システムで配信停止になった相手を取り込む手段が、オプトアウトインポートです。メールアドレスのみを含むCSVをインポートすると、対象の「Unsubscribed from all email」プロパティーがtrueに設定されます。この方法で追加されたアドレスは、課金対象のコンタクト数に加算されず、コンタクトとしても作成されません。ただし、すでにHubSpotにコンタクトとして存在するアドレスは、配信停止にはなるものの課金対象としては残ります（オプトアウトリストのインポートに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。

移行の設計としては、Account Engagement（旧Pardot）で全停止扱いだったプロスペクトはオプトアウトインポートで入れ、購読タイプの粒度は移行後に改めて取り直す、という順序を推奨しています。旧システムに粒度の情報が無いのに、HubSpot側で勝手に粒度を発明すると、同意の範囲を広げたことになります。

購読状態は、コンタクトとメールアドレスのどちらに紐づくのか？

この仕様が、移行のリハーサルで最も事故を起こします。HubSpotのメール購読設定はコンタクトではなくメールアドレスに紐づいており、コンタクトを削除して同じメールアドレスで作り直しても購読状態は引き継がれます（購読設定の管理に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。

検証用に本番ポータルへテストインポートを流し、誤ってオプトアウトを付けてしまった場合、コンタクトを消しても状態は残ります。しかも、コンタクト本人が自ら配信停止した購読タイプは、一括操作で付け直すことができません。だからこそ、インポートの検証は本番ポータルではなく、使い捨ての検証環境か、本番でも実在しないドメインのダミーアドレスで行う必要があります。

特定電子メール法の同意記録は、移行でどう扱うのか？

日本国内へ広告・宣伝メールを送る場合、特定電子メール法の規律が及びます。総務省の資料では、同意のない相手への広告・宣伝メールの送信は原則禁止であり、同意の記録保存義務、受信拒否者への再送信禁止、表示義務が定められています。命令違反には1年以下の懲役または100万円以下の罰金（法人の場合は3000万円以下の罰金）が科されます（特定電子メール法の概要に関する総務省の公式資料）。同意の取得方法と記録の内容は、総務省と消費者庁が示す特定電子メールの送信等に関するガイドラインに整理されています。

移行で問題になるのは、同意を取得した事実の記録が旧システムの中にしか無い場合です。同意日時や取得経路がAccount Engagement（旧Pardot）のフォーム送信履歴にしか残っていないなら、その履歴は項目値として取り出してHubSpot側のカスタムプロパティーに保持してください。旧システムを解約した後に「いつ同意を得たのか」を問われて答えられない状態は避けるべきです。個人データの取扱いは、個人情報の保護に関する法律についてのガイドライン（通則編）に沿って設計してください。

Salesforce連携は、どの順序で切り替えるのか？

Account Engagement（旧Pardot）からHubSpotへ移行する企業の大半は、Salesforceを残します。つまりこの移行は「MAの入れ替え」であると同時に「SalesforceとMAの接続点の張り替え」です。接続点を2本同時に生かす期間が必ず発生するため、どちらがどの項目を書き換えるのかを先に決めておかないと、値が往復して上書きし合います。

コネクタはどこを突き合わせのキーにしているのか？

Account Engagement（旧Pardot）のSalesforceコネクタは、プロスペクトとSalesforceのリード・取引先責任者・個人取引先の間に1対1の関係を作り、CRM IDを突き合わせのキーとして使います。CRM IDを持たないプロスペクトについては、同じメールアドレスのレコードがSalesforceにあればそれに同期し、同じメールアドレスのレコードが複数ある場合は最初に見つかったレコードに同期します。同期は最短2分間隔で発生します（Salesforceコネクタv2の公式ドキュメント、2026年10月23日取得時点）。

HubSpot側のSalesforce連携は、Marketing Hub・Sales Hub・Service Hub・Content HubいずれかのProfessional以上が必要で、Salesforce側はAPIアクセスのあるエディションまたはSalesforce Professionalが条件です。Salesforce Group Editionには対応していません（HubSpot-Salesforce連携のインストールに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。設定の全体像はHubSpotとSalesforceの連携解説にまとめています。

二重更新と同期ループを、どう止めるのか？

並行稼働中に両方のコネクタを同時に書き込み可能にすると、Salesforceの同じ項目を2つのシステムが交互に書き換えます。実務で起きるのは、リードステータスとキャンペーンメンバーのステータスが数分おきに入れ替わる現象です。

私たちが設計する際は、並行稼働に入る前にAccount Engagement（旧Pardot）側のコネクタを読み取り専用に寄せるか、同期対象のレコード範囲をMarketing Data Sharingで絞ります。同期の方向を「HubSpotが書く／Account Engagementは読むだけ」に固定してから並行稼働に入るのが、最も事故が少ない順序です。

同期対象は、最初から全件にしてよいのか？

HubSpot側の連携を有効にする最初の数日は、同期対象を限定するインクルージョンリストで絞ってください。全件同期を初日から開けると、Salesforce側のAPIコール消費と、HubSpot側のマーケティングコンタクト数の両方が一気に動き、何が原因で数字が動いたのかを切り分けられなくなります。

並行稼働の期間は、どう設計するのか？

並行稼働は「念のため両方動かす」期間ではありません。何を検証するために両方動かすのかを定義しない並行稼働は、二重配信のリスクを増やすだけです。私たちは並行稼働の目的を、配信の検証ではなくデータの突合に置いています。

並行稼働中に「二重配信」をどう防ぐのか？

最も確実なのは、並行稼働の初日にAccount Engagement（旧Pardot）側のメール送信を停止することです。データ同期とトラッキングは残し、送信機能だけを止めます。両方のシステムから配信できる状態を1日でも作ると、配信停止の反映タイミングのずれによって、停止済みの相手へ送ってしまう経路ができます。

送信を止められない事情がある場合は、送信主体をセグメントで完全に分離してください。「このリストはHubSpotからのみ、このリストはAccount Engagementからのみ」という分け方にし、両方に属するレコードをゼロにしてから配信を開始します。

切替日に凍結するのは何か？

凍結すべきは、レコードそのものではなく「レコードを増やす経路」です。具体的には、Webサイト上のフォーム、インポート、外部ツールからのAPI書き込みの3つです。この3つを止めてから最終差分を取り、HubSpotへ投入します。レコードの編集そのものを止める必要はありません。

最終差分の取得から投入完了までの時間を、私たちは「空白時間」と呼んで計画書に明記しています。この時間が4時間を超えるなら、差分の取り方を見直すか、週末に切り替えるかの判断が必要です。

トラッキングコードの二重設置は、何を壊すのか？

移行期間中、サイトには両方のトラッキングコードが載ります。これ自体は避けられませんが、2つのシステムは設置の思想が違うため、同じつもりで置くと計測がずれます。

2つのトラッキングは、設計思想がどう違うのか？

Account Engagement（旧Pardot）のトラッキングコードは、キャンペーンごとに固有のコードが発行されます。設置するのはランディングページや特定の製品ページといった価値の高いページのみで、トップページのような一般的なページには置かないことが推奨されています。トラッカードメインはCNAMEレコードをgo.pardot.comへ向けて設定し、DNSの伝播には最大24時間かかります。2023年2月13日以降に作成されたビジネスユニットは、既定でファーストパーティートラッキングを使います（Account Engagementセットアップの公式実装ガイド、2026年10月23日取得時点）。

HubSpotのトラッキングコードは逆で、サイト全体に1つ置く設計です。HubSpotでホストしているブログ・ランディングページ・ウェブサイトページには自動で含まれ、外部ホストのページには終了bodyタグの直前に貼ります（トラッキングコードのインストールに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。つまり「キャンペーン単位で点在させる」思想から「サイト全体に1つ」の思想への切り替えが起きます。

二重設置で壊れるのは、どの数値か？

壊れるのはHubSpot側ではなく、同じシステムのコードを重ねたときです。1つのページに複数のHubSpotトラッキングコードを設置してはいけません。複数設置された場合、最初に読み込まれたものだけが発火し、それ以降のコードは読み込まれません。重複設置は、データの二重計上などのエラーにつながります。

実務で起きるのは、タグマネージャー経由の設置とテンプレート直書きの設置が重なるパターンです。移行のタイミングでタグマネージャーに追加し、以前からテンプレートに入っていたことに気づかない。この状態はブラウザの開発者ツールでスクリプトの読み込み回数を数えれば検出できるので、切替日の前に必ず確認してください。

旧トラッキングコードは、いつ撤去するのか？

解約日ではなく、レポートの締めが終わった日です。Account Engagement（旧Pardot）のトラッキングを先に外すと、旧システムのレポートがその日以降ゼロになり、移行前後の比較ができなくなります。私たちは、切替後1ヶ月のレポート出力が終わるまで旧コードを残し、その後まとめて撤去する運用にしています。

Engagement Studioのプログラムは、どう読み替えるのか？

Engagement Studioのプログラムをワークフローへ写すとき、1対1で移すと高確率で破綻します。両者は動作モデルが違い、特に「同じ人が何度入れるか」の扱いが異なるためです。

プログラムの本数と複雑さを、どう測るのか？

Account Engagement（旧Pardot）のEngagement Studioには、エディションごとの上限があります。Growthは合計20・繰り返し10、Plusは合計100・繰り返し10、Advancedは合計200・繰り返し10、Premiumは合計200・繰り返し15です。パフォーマンスの観点からは1プログラムあたり300ステップ未満が推奨され、1つのルールステップで評価できる条件は最大5つ、30日間新規の追加も移動も無いプログラムは非アクティブとして扱われます（Engagement Studio利用時の考慮事項に関する公式ドキュメント、2026年10月23日にブラウザで取得）。

移行の見積もりでは、プログラムの本数ではなくステップ数の合計を数えてください。20本あっても合計150ステップなら1週間で書き起こせますが、5本で合計800ステップなら設計から作り直す判断になります。Engagement Studioの全体像はEngagement Studioに関する公式ドキュメントに整理されています。

ワークフローに移すとき、最初に決めることは何か？

登録条件と再登録の可否です。HubSpotのワークフローはMarketing Hub Professional以上などで利用でき、登録トリガー・再登録・登録解除の設定を編集時に明示的に決める構造になっています（ワークフローの作成に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。ここを既定値のまま進めると、移行後に同じ人へ同じメールが再送されます。ワークフローの登録解除設計とワークフローの基礎もあわせてご確認ください。

フォームとランディングページの再作成で、見落としやすいものは何か？

フォームの再作成は、見た目を揃える作業だと思われがちです。実際に時間を取られるのは、フォームの外側にある仕組みのほうです。埋め込み先のHTML、送信後の遷移先、フォーム送信をトリガーにしている社内の通知、そしてフォーム項目とCRMプロパティーのマッピング。この4つを棚卸ししないと、フォームだけ動いて後続が止まります。

HubSpotのフォームは、HubSpotでホストするページには自動で載り、外部サイトには埋め込みコードで設置します（フォームの作成に関するHubSpot公式ナレッジベース）。実装の手順はHubSpotフォームの埋め込み方法とHubSpotフォームの基礎にまとめています。

ランディングページについては、URLの扱いが論点になります。Account Engagement（旧Pardot）のランディングページはトラッカードメイン配下のURLで公開されているため、HubSpotへ移すとURLが変わります。外部からリンクされているページ、広告の遷移先に設定されているページ、印刷物に載せたページの3つは、リダイレクトを設定しないと到達できなくなります。

メール配信の認証設定は、移行でどこまでやり直すのか？

送信ドメインの認証は、移行で必ずやり直す領域です。Account Engagement（旧Pardot）ではSPFが既定で構成され、DKIMとDMARCの追加設定が推奨されています（Account Engagementのメール到達性に関する公式ガイド、2026年10月23日取得時点）。HubSpot側でも送信ドメインの接続とメール認証の設定が必要で、DNSレコードの追加が伴います（メール認証の管理に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。

ここで起きがちな事故が、旧システムのDNSレコードを切替日に消してしまうことです。認証レコードを消すと、配信途中のメールや、まだ送信キューに残っているメールが認証に失敗します。旧システムのDNSレコードは、解約が完了して送信が完全に止まったことを確認してから削除してください。

移行のコストは、どこを見積もればよいのか？

見積書の総額を1つの数字として眺めていると、どこを削れるのかが見えません。移行のコストは、ライセンスの二重課金期間、データ移送の工数、資産再作成の工数、そして社内調整の工数に分解すると判断しやすくなります。このうち金額として動かしやすいのは、二重課金期間だけです。

Account Engagement（旧Pardot）の価格はいくらか？

日本向けの公式価格ページでは、Growth+が月額150,000円、Plus+が月額330,000円、Advanced+が月額528,000円、Premium+が月額1,800,000円と表示されています（いずれも組織あたり・年間契約、2026年10月23日）。アドオンの追加プロスペクトは、10,000件あたり月額100米ドルです（Marketing Cloud Account Engagementの価格ページ）。価格は変更される可能性があるため、判断の際は必ず公式ページでご確認ください。

同じページのよくある質問には、Marketing Cloud Account Engagementにサポート終了（EOL）、販売終了（EOS）、ロードマップ終了（EOR）の予定は無いと記載されています。製品が終わるから移るという前提で稟議を書くと、事実と異なる説明になります。移行の理由は「製品の終了」ではなく「自社の収益プロセスをどう作るか」に置いてください。

二重課金の期間を、どう圧縮するのか？

年間契約の更新日から逆算して切替日を置くのが基本です。更新日の3ヶ月前に移行を開始し、更新日の2週間前までに切り替えを終える計画にすると、二重課金は3ヶ月で収まります。ここを逆にして、HubSpotの契約から始めて旧システムの更新日を待つ設計にすると、最大で1年分の二重課金が発生します。

HubSpot側の費用はエディションとマーケティングコンタクト数で決まるため、移行するコンタクト件数が契約プランに直結します。配信停止済みのレコードをオプトアウトインポートで入れると課金対象に加算されない点は、ここで効いてきます。

移行プロジェクトは、どんな工程に分かれるのか？

工程表を作るときに重要なのは、各工程の長さよりも「どの工程が終わらないと次へ進めないか」の依存関係です。次の一覧は、私たちが大手企業のMA移行で使っている標準的な工程の並びです。期間は資産の本数によって変わるため、依存関係のほうを先に読んでください。

この並びで最も圧縮しにくいのが5と6です。配信可否の移送は件数照合が必要で、並行稼働は時間を短縮すると突合の精度が落ちます。期間を詰めたい場合は、4の資産再作成の範囲を絞るのが現実的な判断になります。

よくある質問

アクティビティ履歴は、どこまで移すべきですか？

原則として移さないことをお勧めしています。メールの開封・クリックの個票を移しても、新しい環境でのレポートに統合されず、容量と工数だけが増えます。移す価値があるのは、商談や契約に直結する履歴と、同意取得の記録の2つです。過去のレポートが必要な場合は、旧システムで出力したレポートをPDFとCSVで保管する方法で足ります。

Salesforceを残したままでも、HubSpotへ移行できますか？

できますし、実際にはその構成が最も多いパターンです。Salesforceを取引の正とし、HubSpotをマーケティングの実行基盤とする分担になります。重要なのは、両方が書き込める項目を作らないことです。項目ごとに「どちらが正か」を決め、片方向の同期に寄せる設計が、長期的に最も壊れません。

移行中に新しいキャンペーンを走らせても大丈夫ですか？

並行稼働に入る前であれば、旧システム側で走らせて問題ありません。並行稼働に入った後は、新規のキャンペーンはHubSpot側だけで実施してください。両方で新規施策を走らせると、配信停止の反映ずれによる二重配信の経路ができます。どうしても旧システムで走らせる必要がある場合は、対象リストの重複をゼロにしてから実施します。

移行前のデータ品質が悪いのですが、先に掃除すべきですか？

全部は掃除しないでください。掃除の対象は、重複レコードと配信可否の2つに絞るのが費用対効果の面で妥当です。役職名の表記ゆれや業種の分類といった項目は、移行後にHubSpot側のプロパティー設計と合わせて整えるほうが、二度手間になりません。データ基盤の考え方はSSOTの設計に関する記事にまとめています。

社内にリソースが無く、情報システム部門も協力的ではありません

DNSレコードの変更とトラッキングコードの設置だけは、情報システム部門の協力が不可欠です。この2点に絞って依頼を切り出し、それ以外の工程をマーケティング部門と外部で完結させる進め方を取ってください。全工程への関与を求めると調整に時間がかかりますが、2点だけなら作業時間として合意を取りやすくなります。

旧システムの解約タイミングは、いつが適切ですか？

切替後1ヶ月のレポート締めが終わり、旧システムのDNSレコードを撤去しても問題ないと確認できた後です。契約上の解約予告期間が必要な場合は、予告だけ先に出し、実際の停止日を上記の条件に合わせて設定してください。解約を急いで旧システムへアクセスできなくなると、移行漏れが見つかったときに取り返しがつきません。

移行を外部に頼むと、何をどこまで任せられますか？

私たちが受けている範囲で最も多いのは、マッピング設計・資産の再作成・並行稼働の管理の3つです。逆に、社内でしか決められないのは、移行する資産の取捨選択と、スコアリングの基準を営業とどう合意するかの2点です。外部に任せる範囲を決める際は、「判断」と「作業」を分けて、判断を社内に残す切り分けをお勧めしています。

まとめ：移行の成否は、切り替え当日より前に決まる

Account Engagement（旧Pardot）からHubSpotへの移行で技術的に難しい工程は、実はほとんどありません。CSVを出して、マッピングして、入れる。難しいのは、何を移さないかを決めることと、配信可否を1件も取りこぼさないことと、2つのシステムが同時に動く期間を安全に設計することです。

この3つはいずれも、切り替え当日の作業ではなく、その前の設計で決まります。棚卸しとマッピング設計に十分な時間を取ったプロジェクトは、切替日が拍子抜けするほど静かに終わります。逆に、設計を飛ばして作業から入ったプロジェクトは、切替日の当日に意思決定が集中し、判断を誤ります。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、大手企業のマーケティング基盤の移行を支援しています。資産の棚卸しだけ、あるいはマッピング設計のレビューだけといった部分的なご相談もお受けしています。お問い合わせフォームよりご連絡ください。

本記事に記載したAccount Engagement（旧Pardot）およびHubSpotの仕様・上限値・価格は、2026年10月23日取得時点の各社の公式ドキュメントおよび公式価格ページの内容に基づいています。仕様・上限・価格はいずれも変更される可能性があるため、実際の計画策定時には各社の一次情報で最新の内容をあたってください。