MarketoからHubSpotへ移ると決めた後、最初に止まるのはデータ抽出の工程です。管理画面からCSVを落とせば終わりだろうと見積もったチームが、Bulk Extract APIの1日の割当量にぶつかり、抽出だけで2週間を消費する。あるいは、Smart Campaignの本数を数えて「この程度なら1ヶ月」と書いた工程表が、フロー内の分岐と待機ステップを開いた瞬間に崩れる。
比較検討の資料はいくらでも見つかります。ところが「で、どうやって移すのか」を工程順に書いた日本語の資料が見当たらない。結果として、移行の実務が属人化し、切替日が近づくほど判断が特定の担当者に集中します。
本記事は、Adobe Marketo EngageからHubSpotへ移行する際の手順を、データ抽出・アセットの再設計・購読管理・トラッキング・切り替えの5工程に分けて整理したものです。どちらの製品が優れているかという話は扱いません。製品選定の比較はHubSpotとMarketoの比較記事に譲り、ここでは「移行すると決めた後」の設計だけを書きます。従業員1,000名規模で、複数の事業部がそれぞれMarketoのワークスペースを使っている、という状況を想定した内容です。
目次
移行の見積もりが外れる原因は、ほぼ例外なく「データは移せる、アセットは移せない」という線引きを工程表に反映していないことにあります。人（リード）とアクティビティはAPIで取り出せます。一方、Program、Smart Campaign、ランディングページ、フォーム、メールテンプレートは、他システムへ移植できる形式では出てきません。
私たちがMarketoからの移行を支援する際、見積もりを「抽出」「再設計」「切り替え管理」の3つに分けて出しています。このうち抽出はAPIの制限値から所要日数が計算できるため、最も精度が高く見積もれます。精度が低いのは再設計で、ここはアセットの本数ではなくステップ数で測らないと外れます。
次の一覧は、Marketoの主要な資産ごとに、取り出し方とHubSpot側の受け皿、そして判断の勘所を整理したものです。注目すべきは右端の列で、ここが「そのまま移す／作り直す／捨てる」の分岐になります。アセットの移行可否そのものより、作り直す範囲をどこで切るかが工数を決めます。
| Marketoの資産 | 取り出し方 | HubSpot側の受け皿 | 判断 |
|---|---|---|---|
| People（リード）と項目値 | Bulk Lead Extract | コンタクトのインポート | そのまま移す。項目マッピングを先に確定 |
| アクティビティ履歴 | Bulk Activity Extract | カスタムプロパティー／外部保管 | 必要な種類だけ。全件は移さない |
| Program Member（メンバーシップ） | Bulk Program Member Extract | 静的リスト／キャンペーン関連付け | 直近の稼働分のみ移す |
| カスタムオブジェクト | Bulk Custom Object Extract | カスタムオブジェクト | エディション要件を先に確認 |
| Static List | Bulk Lead Extractのフィルター | 静的リスト | 稼働中のものだけ移す |
| Smart List | 定義は出せない | 動的リスト（セグメント） | 条件を読み取って再作成 |
| Program | 出せない | キャンペーン＋ワークフロー | 1対1で移さない。分解して再構成 |
| Smart Campaign | 出せない | ワークフロー | 再設計。適格性ルールの読み替えが必須 |
| ランディングページ | 出せない | ランディングページ | 再作成。URLのリダイレクト設計が必要 |
| フォーム | 出せない | HubSpotフォーム | 再作成。埋め込み先のHTML改修が伴う |
| メールテンプレート | HTMLは取り出せる | マーケティングEメール | 再作成。モジュール構造が異なる |
| 配信停止フィールド | Bulk Lead Extract | 購読タイプ／オプトアウトインポート | 最優先。取りこぼしは法令リスク |
Marketoからの一括抽出は、管理画面のエクスポートではなくBulk Extract APIを使います。管理画面のエクスポートは件数の上限と実行時間の制約が厳しく、数十万件規模のデータベースでは現実的ではありません。Bulk Extractはリード、アクティビティ、プログラムメンバー、カスタムオブジェクトの4種類を対象にしています（Bulk Extractに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
抽出の所要日数は、感覚ではなく割当量から計算できます。同時に実行できるエクスポートジョブは2件、キューに入れられるジョブは実行中を含めて10件までです。生成されたファイルの保持期間は7日間で、1日の割当量は500MB、この割当量はリード・アクティビティ・プログラムメンバー・カスタムオブジェクトの4種類で共有されます。割当量はCST/CDTの午前0時にリセットされます。
この500MBという数字が、移行計画の最初の制約になります。アクティビティ履歴を全件抜こうとすると、数百MB規模のファイルが毎日生成され、リードの抽出に割り当てる余地がなくなります。私たちが計画を立てる際は、リードの抽出を先に完了させ、アクティビティは必要な種類に絞って後から回す順序にしています。
Bulk Lead Extractは4つの段階を踏みます。ジョブの作成、キューへの投入、進捗のポーリング、ファイルの取得です。ジョブのステータスはCreated、Queued、Processing、Completedと遷移し、Canceled・Failedで終わることもあります。ステータスの更新は60秒より高い頻度では行われず、多くのユースケースでは5分間隔のポーリングが推奨されています（Bulk Lead Extractに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
フィルターは5種類あり、1つのジョブで使えるのは1種類だけです。createdAtとupdatedAtはいずれも範囲が31日以内という制約があるため、運用歴が5年あるインスタンスを作成日で分割して抜くと、それだけで60回以上のジョブが必要になります。静的リスト単位のフィルターを併用して分割数を減らすのが、実務上は現実的な設計です。出力形式はCSVが既定で、TSVとSSVも選べます。
Bulk Activity ExtractもcreatedAtの範囲が31日以内に制限されます。activityTypeIdsで種類を絞れますが、「Delete Lead」のアクティビティは対象外です。フォームやプログラム、リストといった特定のアセットに絞る場合、指定できるIDまたは名前は1つのフィルターあたり最大50件です。既定では8つの項目が出力されます（Bulk Activity Extractに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
私たちがアクティビティの抽出範囲を決めるときの基準は単純で、「HubSpot側で再現できるか」ではなく「監査または商談の根拠として後から参照されるか」です。メールの開封やページ閲覧の個票は、移行後のレポートに統合されないまま容量を消費します。残すべきは、フォーム送信の記録と、同意取得の根拠になるアクティビティです。プログラムメンバーシップはBulk Program Member Extractに関するAdobeの公式ドキュメントの手順で別途取得します。
Bulk Extractの割当量とは別に、REST API全体の上限があります。この上限は移行専用に確保されているわけではなく、既存の連携や社内ツールと共有されます。移行作業を始めた途端に、既存の連携がエラーを返し始めるという事故は、ここを確認していないことが原因です。
多くのサブスクリプションには1日50,000回のAPIコールが割り当てられ、割当量はCSTの午前0時にリセットされます。レート制限は1インスタンスあたり20秒間に100回、同時実行は最大10件です。バッチサイズはLead DBが300レコード、Asset Queryが200レコードで、RESTのペイロードサイズは1MB、バルクインポートのファイルサイズは10MBです。レート制限を超えると606のエラーコードが返ります（Marketoの連携に関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
1インスタンスあたり少なくとも10,000回のREST APIコールが割り当てられ、50,000回以上が一般的です。Bulk Extractの容量は500MB以上です。自社のインスタンスがどの水準かは管理画面で確認できるため、移行計画を書く前に実値を押さえてください。公開情報の一般値で計画を立てると、抽出の日数が2倍ずれます。
抽出が終われば次は投入です。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日取得時点）。
つまり律速になるのはHubSpot側ではなく、Marketo側のBulk Extractです。投入のほうが速いため、抽出が終わった分から順次投入していく並行処理の設計にすると、全体の日数を圧縮できます。インポートの実務はHubSpotへのデータインポートの解説とオブジェクトのインポートに関するHubSpot公式ナレッジベースにまとめています。
項目のマッピング表は、項目名の対応だけでは足りません。必要なのは選択肢の値そのものの対応です。Marketo側で「A／B／C」と入っている選択肢を、HubSpot側のどの内部値に落とすかまで決めておかないと、インポート後に選択肢が増殖し、既存のリストが機能しなくなります。
Marketoのカスタム項目は、作成時に入力した名前からAPI名が自動生成され、保存後は変更できません。項目名の先頭に使えない文字もあります（カスタム項目の作成に関するAdobeの公式ドキュメント、2026年10月23日取得時点）。長く運用したインスタンスほど、表示名とAPI名が乖離した項目が溜まっています。
抽出で取れるのはAPI名のほうです。表示名だけを見てマッピング表を作ると、同じ意味の項目が2つあるのに片方しか移らない、という事故が起きます。マッピング表には「表示名」「API名」「型」「選択肢の全値」「HubSpot側の内部名」「変換ルール」「移行しない場合の理由」を持たせてください。移行しない項目にも理由を書くのは、切替後に必ず「あの項目はどこへ行ったのか」と聞かれるためです。
移行の前です。HubSpotに入れてから整理する前提で設計すると、取り返しがつかなくなります。HubSpotのレコードのマージは取り消せません。さらに、2つのレコードが関与したマージの累計が250回以上になると、それ以降マージできなくなります。マージ後は「Merged record IDs」プロパティーで統合元を追跡できますが、統合そのものを戻す手段はありません（レコードのマージに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。マージ後、すべてのアクティビティーが同期するまで最大30分かかる点も検証計画に織り込んでください。
ここが移行設計の中心です。1対1で対応づけようとすると必ず破綻します。Marketoは「Programという容れ物の中にアセットとSmart Campaignを入れる」構造で、HubSpotは「キャンペーンでアセットを束ね、ワークフローで自動化を回す」構造です。容れ物と自動化が同じ単位か別の単位か、という設計思想の差があります。
Programは両方に分解されます。Programは単一のマーケティング施策を表し、ランディングページ・メール・Smart Campaignといったローカルアセットを含む容れ物です。種類はEvent、Engagement、Email、Defaultの4つがあります（Programに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
HubSpotでは、アセットを束ねる役割はキャンペーンが担います。キャンペーンツールはMarketing Hub ProfessionalとEnterpriseで利用でき、複数のアセットを1つのキャンペーンに関連付けて成果をまとめて測る設計です（キャンペーンの理解に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。MarketoのPeriod Costに相当する費用管理は、キャンペーンの予算タブで予算項目と支出項目として登録し、予算合計・支出合計・残予算を把握します（キャンペーン予算の管理に関するHubSpot公式ナレッジベース）。
Smart CampaignはSmart List、Flow、Scheduleの3つの領域で構成されます。Smart Listは対象者の定義でフィルターとトリガーを持ち、Flowは実行するステップ（待機や分岐を含む）、Scheduleは実行タイミングを制御します。Smart Campaignを別のProgramへ移動しても、Smart ListやFlowが元のProgramを参照している場合、その参照は自動では更新されません（Smart Campaignに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
HubSpotのワークフローでは、Smart Listが登録トリガー、Flowがアクション、Scheduleが実行設定に対応します。ワークフローはMarketing Hub Professional以上などで利用でき、登録トリガー・再登録・登録解除を編集時に明示的に設定する構造です（ワークフローの作成に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。移行の際は、ワークフローの基礎と登録解除の設計をあわせてご確認ください。
移行後の二重配信は、ほぼすべてここの読み替えミスから発生します。Marketoの適格性ルールは、同じ人がフローを何回通れるかを制御する設定で、既定では複数回トリガーされても1回しか通りません。設定は「only once」「every time」「once every # days / weeks / months」から選べます。日単位のルールは時間に換算され、1ヶ月は常に30日として数えられます（適格性ルールに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。コミュニケーション制限は、既定ではSmart Campaignに適用されません。
HubSpotのワークフローでは、この「何回通すか」が再登録（re-enrollment）の設定として表現されます。既定値のまま移すと、Marketoで1回しか通らなかった施策が、HubSpotでは条件を満たすたびに動く、あるいはその逆が起こります。私たちがワークフローを移すときは、Smart Campaign1本ごとに「適格性ルールの設定値」「HubSpot側の再登録設定」「想定される通過回数」の3点を書き出した対応表を作り、レビューを通してから実装しています。
移行工程の中で、失敗したときの損害が最も大きいのがここです。データの移送漏れは後から入れ直せますが、配信停止にした相手へ広告メールを送ってしまった事実は取り消せません。この工程だけは、工数ではなくリスクで優先順位を決めてください。
Marketoには、人（Person）オブジェクト上のブール型項目として4種類の配信停止が組み込まれています。Unsubscribedは標準の配信停止ページまたはメール内のリンクで設定され、マーケティングメールは届かなくなりますがオペレーショナルメールは届きます。Marketing Suspendedは一時的な配信停止で、手動またはChange Data Valueのフローステップでのみ設定されます。Email Suspendedはハードバウンス発生後24時間メール送信をブロックする状態で、24時間経過後もチェックは残ります。Blocklistedは、オペレーショナルを含むすべてのメールを送らない状態です（配信停止に関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
この4つを1列にまとめてエクスポートした時点で、情報が落ちます。移行の設計では、4項目を別々の列として取り出し、それぞれHubSpot側で何に対応させるかを個別に決めてください。特にEmail Suspendedは「本人の意思による停止」ではなくバウンス由来の技術的な状態なので、HubSpot側で恒久的なオプトアウトとして入れると、本来配信できる相手を永久に失います。
Marketoのオペレーショナルメールは、UnsubscribedとMarketing Suspendedのステータスを無視し、コミュニケーション制限の対象外になります。使うべきなのは重要なメールと自動返信のみで、マーケティングメールには適しません。エンゲージメントプログラムは、メールのオペレーショナル設定を無視します（オペレーショナルメールに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
HubSpotで相当するのはトランザクションメールです。トランザクションメールは専用IPアドレスから送信するアドオンで、Marketing Hub ProfessionalとEnterpriseが対象です。購読設定、隔離ステータス、過去のバウンス、非マーケティングコンタクトの状態にかかわらず送信でき、除外されるのは「unknown user」としてバウンスした履歴のあるコンタクトだけです（トランザクションメールの送信に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。アドオンの購入が前提になるため、Marketoでオペレーショナルメールを常用しているなら、移行の見積もりにこのアドオンを含める必要があります。
HubSpotの購読タイプはマーケティングメールのカテゴリーを表す仕組みで、1アカウントあたり最大1,000件まで作成できます。Marketing Hub Starter以上、またはContent Hub Professional以上で利用できます（購読タイプの設定に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。
外部システムで配信停止になった相手を取り込む手段が、オプトアウトインポートです。メールアドレスのみのCSVを取り込むと、対象の「Unsubscribed from all email」プロパティーがtrueに設定されます。この方法で追加されたアドレスは課金対象のコンタクト数に加算されず、コンタクトとしても作成されません（オプトアウトリストのインポートに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。コンタクト単位の全停止フラグと購読タイプ単位のオプトアウトは別の層なので、どちらに落とすかを項目ごとに決めてください（配信停止状況の確認に関するHubSpot公式ナレッジベース）。
メールアドレスです。HubSpotのメール購読設定はコンタクトではなくメールアドレスに紐づいており、コンタクトを削除して同じアドレスで作り直しても購読状態は引き継がれます。さらに、本人が自ら配信停止した購読タイプは、一括操作で付け直すことができません（購読設定の管理に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。
この仕様が、移行リハーサルで最も事故を起こします。本番ポータルへ検証用のインポートを流し、誤ってオプトアウトを付けてしまうと、コンタクトを消しても状態が残ります。検証は本番ポータルではなく、使い捨ての検証環境か、実在しないドメインのダミーアドレスで行ってください。
日本国内へ広告・宣伝メールを送る場合、特定電子メール法の規律が及びます。総務省の資料では、同意のない相手への広告・宣伝メールの送信は原則禁止であり、同意の記録保存義務、受信拒否者への再送信禁止、表示義務が定められています。命令違反には1年以下の懲役または100万円以下の罰金（法人の場合は3000万円以下の罰金）が科されます（特定電子メール法の概要に関する総務省の公式資料）。同意の取得方法と記録の内容は、総務省と消費者庁が示す特定電子メールの送信等に関するガイドラインに整理されています。
Marketoでは、同意取得の事実がフォーム送信のアクティビティや独自のカスタム項目に残っていることが多く、この情報は人の項目値だけを抜いても出てきません。同意日時・取得経路・同意文面のバージョンの3点がどこに保持されているかを、抽出設計の段階で特定してください。個人データの取扱いは、個人情報の保護に関する法律についてのガイドライン（通則編）に沿って設計してください。
両方のトラッキングコードが同時にサイトに載る期間は必ず発生します。問題は、2つのコードが設置の前提を共有していないことです。同じつもりで置くと、計測が欠けるか、二重に計上されます。
Munchkinは、非同期版のコードを各ページのhead要素の中に置くことが推奨されています。コードの種類はSimple、Asynchronous、Asynchronous jQueryの3つで、ほとんどの場合は非同期版を使います。設置範囲は「追跡したいページ」であり、小規模サイトでは全ページ、動的生成ページやフォーラムが多いサイトでは主要ページのみ、という使い分けになります。Marketoで作成したランディングページには自動的にトラッキングコードが含まれます（Munchkinトラッキングコードの設置に関するAdobeの公式ドキュメント、2026年10月23日取得時点）。
HubSpotのトラッキングコードは、外部ホストのページでは終了bodyタグの直前に貼ります。HubSpotでホストしているブログ・ランディングページ・ウェブサイトページには自動で含まれます（トラッキングコードのインストールに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。つまり設置位置がheadとbody終端で異なり、片方のルールで両方を置くと、どちらかが意図した位置に入りません。
壊れるのは、同じシステムのコードを重ねたときです。1つのページに複数のHubSpotトラッキングコードを設置してはいけません。複数設置された場合、最初に読み込まれたものだけが発火し、以降のコードは読み込まれません。重複設置は、データの二重計上などのエラーにつながります。Munchkin側にも同様の注意があり、1つのページに複数のパーティション／ワークスペース向けのトラッキングスクリプトを含めてはいけません。
実務で起きるのは、タグマネージャー経由の設置とテンプレート直書きの設置が重なるパターンです。移行のタイミングでタグマネージャーに追加し、以前からテンプレートに入っていることに気づかない。ブラウザの開発者ツールでスクリプトの読み込み回数を数えれば検出できるため、切替日の前に必ず確認してください。
Munchkinは匿名の訪問者もIPアドレスなどの情報とあわせて追跡し、その記録は「Visit Web Page」「Clicked Link on Web Page」というアクティビティとしてSmart ListやSmart Campaignのトリガーに使えます（Munchkinのリードトラッキングに関するAdobeの公式ドキュメント、2026年10月23日取得時点）。月間数十万訪問を超えるサイトでは、匿名の人物を追跡しない設定が推奨されています。
匿名訪問をトリガーに使っているSmart Campaignがある場合、HubSpot側で同じ条件をそのまま再現できるとは限りません。移行前に、匿名トラッキングに依存している施策を洗い出し、既知コンタクトの行動に基づく条件へ置き換えられるかを判定してください。ここを確認せずに切り替えると、移行後に「動かなくなった施策」として報告が上がります。
並行稼働は「念のため両方動かす」期間ではありません。何を検証するために両方動かすのかを定義しない並行稼働は、二重配信のリスクを増やすだけです。私たちは並行稼働の目的を、配信の検証ではなくデータの突合に置いています。
最も確実なのは、並行稼働の初日にMarketo側のメール送信を停止することです。Munchkinによるトラッキングとデータの抽出は続け、送信機能だけを止めます。両方から配信できる状態を1日でも作ると、配信停止の反映タイミングのずれによって、停止済みの相手へ送ってしまう経路ができます。
送信を止められない事情がある場合は、送信主体をリストで完全に分離してください。「このセグメントはHubSpotからのみ、このセグメントはMarketoからのみ」と分け、両方に属する人をゼロにしてから配信を開始します。リストの作り方はリストの作成に関するHubSpot公式ナレッジベースに手順があります。
凍結すべきはレコードそのものではなく、レコードを増やす経路です。具体的には、Webサイト上のフォーム、インポート、外部ツールからのAPI書き込みの3つです。この3つを止めてから最終差分をBulk Extractで取り、HubSpotへ投入します。人の編集そのものを止める必要はありません。
ここでBulk Extractの制約が効いてきます。ジョブの投入からファイル取得までに時間がかかるため、最終差分の取得は「切替日の当日に始める」のではなく、前日までにリハーサルで所要時間を実測しておいてください。私たちはこの所要時間を「空白時間」として計画書に明記し、4時間を超える場合は差分の取り方を見直すか、週末に切り替える判断をしています。
解約日ではなく、レポートの締めが終わった日です。Munchkinを先に外すと、Marketo側のレポートがその日以降ゼロになり、移行前後の比較ができなくなります。切替後1ヶ月のレポート出力が終わるまでMunchkinを残し、その後まとめて撤去する運用にしてください。
MarketoとHubSpotでは課金の単位が違います。移行するレコード件数がそのまま契約プランに直結するため、抽出の範囲を決める段階で課金の条件を確認しておく必要があります。
HubSpotのMarketing Hubでは、マーケティング活動の対象とするコンタクトを「マーケティングコンタクト」として扱い、その件数でコンタクトティアが決まります。マーケティング対象にしないコンタクトは非マーケティングコンタクトに設定でき、ティアにも料金にも影響しません。マーケティングコンタクトの仕組みは、2022年9月より後に作成されたMarketing Hubアカウントに含まれています（マーケティングコンタクトに関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。
この仕組みがあるため、「Marketoのデータベース件数＝HubSpotの課金対象件数」にはなりません。配信停止済みのレコードをオプトアウトインポートで入れれば課金対象に加算されず、過去に一度も反応していないレコードは非マーケティングコンタクトとして投入できます。移行の設計次第で、ライセンス費用は大きく変わります。
なお、Marketo Engageの価格については、Adobeの公式サイトに価格表の記載を確認できませんでした（2026年10月23日時点）。両製品のライセンス費用を比較する場合は、Adobeおよびパートナーへの見積もり依頼が前提になります。
工程表で重要なのは、各工程の長さよりも「どの工程が終わらないと次へ進めないか」の依存関係です。次の一覧は、私たちが大手企業のMA移行で使っている標準的な工程の並びです。期間はアセットの本数とデータ件数で変わるため、依存関係のほうを先に読んでください。
| 工程 | 主なタスク | 完了条件 | 次工程への依存 |
|---|---|---|---|
| 1. 棚卸し | Program・Smart Campaign・フォーム・項目の一覧化と稼働判定 | 移行する／しないの判定が全件終わっている | これが終わらないと見積もりが出ない |
| 2. API上限の実測 | 自社インスタンスの割当量とBulk Extract容量の確認 | 抽出の所要日数が算出できている | 工程表の日数が確定しない |
| 3. マッピング設計 | API名ベースの項目対応表、選択肢の値変換 | 選択肢レベルまで対応が決まっている | 投入の前提 |
| 4. 検証抽出・検証投入 | 少量のBulk Extractとインポート、件数照合 | 想定どおりの件数と値になっている | 本番投入の前提 |
| 5. アセットの再設計 | ワークフロー・フォーム・ページ・テンプレート | 適格性ルールの対応表がレビュー済み | 並行稼働の前提 |
| 6. 配信可否の移送 | 4種類の配信停止項目の振り分け、同意記録の保持 | 件数がMarketoと一致している | 配信開始の前提 |
| 7. 並行稼働 | Marketoの送信停止、データ突合 | 差分がゼロに収束している | 切替の前提 |
| 8. 切り替え | 流入経路の凍結、最終差分、公開 | 空白時間内に投入が完了している | 監視の前提 |
| 9. 切替後監視 | 配信・計測の監視、Munchkin撤去 | 1ヶ月のレポート締めが終わっている | Marketo解約の前提 |
この並びで最も圧縮しにくいのが2と6です。API上限の実測を飛ばすと工程表の日数が根拠を失い、配信可否の移送は件数照合が必要なため作業を並列化できません。期間を詰めたい場合は、5のアセット再設計の範囲を絞るのが現実的な判断になります。
Marketoのスコアは、Smart Campaignの中で「Change Score」のフローステップを積み重ねた結果として存在しています。つまりスコアのロジックは1箇所にまとまっておらず、複数のSmart Campaignに分散しています。移行時にこれを1本ずつ追いかけるのは、現実的な工数に収まりません。
私たちが推奨しているのは、旧スコアを参照専用のカスタムプロパティーとして取り込み、HubSpot側のスコアはゼロベースで組み直す方法です。HubSpotのリードスコアリングは、行動に基づくエンゲージメントスコアと属性に基づくフィットスコアを別々に持てる構造で、Marketing Hub ProfessionalまたはSales Hub Professional以上が前提になります（リードスコアの作成に関するHubSpot公式ナレッジベース、2026年10月23日取得時点）。考え方はHubSpotのスコアリングの基礎にまとめています。
参照専用で旧スコアを残しておけば、切替後3ヶ月の時点で「旧スコア上位のうち何%が新スコアでも上位に入ったか」を検証できます。この検証結果が、スコアリングの閾値を営業と合意し直すときの材料になります。
まず抽出対象を減らしてください。アクティビティの種類を絞り、項目も必要なものだけに限定すると、ファイルサイズは大きく下がります。それでも足りない場合、追加の容量はサブスクリプションの一部として購入できます。日数をかけて分割抽出する方法もありますが、7日間のファイル保持期限との兼ね合いで管理が煩雑になります。
使えません。MarketoのランディングページはMarketo側のドメイン配下で配信されているため、HubSpotへ移すとURLが変わります。外部からリンクされているページ、広告の遷移先、印刷物に記載したURLの3つは、リダイレクトを設定しないと到達できなくなります。移行前に、流入のあるランディングページをアクセス解析で特定し、リダイレクト対象の一覧を作ってください。
並行稼働に入る前であれば、Marketo側で走らせて問題ありません。並行稼働に入った後は、新規の施策はHubSpot側だけで実施してください。両方で新規施策を走らせると、配信停止の反映ずれによる二重配信の経路ができます。どうしてもMarketoで走らせる必要がある場合は、対象リストの重複をゼロにしてから実施します。
事業部ごとにポータルを分けるか、1ポータル内でブランドやチームの権限で分けるかの判断になります。判断軸は、コンタクトを事業部間で共有するかどうかです。共有する前提なら1ポータル、完全に分離する前提なら複数ポータルが基本です。この判断は移行開始前に確定させてください。後から分割も統合も、インポートのやり直しになります。
切替後1ヶ月のレポート締めが終わり、Munchkinを撤去しても問題ないと確認できた後です。契約上の解約予告期間がある場合は、予告だけ先に出し、停止日を上記の条件に合わせて設定してください。解約を急いでインスタンスへアクセスできなくなると、移行漏れが見つかったときに取り返しがつきません。
Bulk Extractの実行は、スクリプトを書ける担当者が1名いれば数日で組めます。社内に不在の場合、この工程だけを外部に切り出す進め方が現実的です。逆に、情報システム部門の協力がどうしても必要なのは、DNSレコードの変更とトラッキングコードの設置の2点です。この2点に絞って依頼を切り出すと、調整が進みやすくなります。
私たちが受けている範囲で多いのは、抽出スクリプトの実装・マッピング設計・ワークフローの再設計・並行稼働の管理です。社内でしか決められないのは、移行するアセットの取捨選択と、スコアリングの基準を営業とどう合意するかの2点です。外部に任せる範囲を決める際は、「判断」と「作業」を分け、判断を社内に残す切り分けをお勧めしています。
MarketoからHubSpotへの移行で、技術的に難しい工程はほとんどありません。Bulk Extractで抜いて、マッピングして、入れる。難しいのは、APIの割当量から抽出の日数を現実的に見積もることと、Smart Campaignの適格性ルールをワークフローの再登録設定へ正しく翻訳することと、4種類の配信停止項目を1件も取りこぼさないことです。
この3つはいずれも、切り替え当日の作業ではなく、その前の設計で決まります。棚卸しとAPI上限の実測に十分な時間を取ったプロジェクトは、切替日が拍子抜けするほど静かに終わります。設計を飛ばして作業から入ったプロジェクトは、切替日当日に意思決定が集中し、判断を誤ります。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、大手企業のマーケティング基盤の移行を支援しています。アセットの棚卸しだけ、あるいは抽出計画のレビューだけといった部分的なご相談もお受けしています。お問い合わせフォームよりご連絡ください。
関連する記事として、MAツール全般の選定軸はMAツールの比較記事、SalesforceからHubSpotへの移行は移行ガイド、移行後のデータ基盤はSSOTの設計に関する記事、部門間の分断についてはデータのサイロ化がもたらす影響をご参照ください。
本記事に記載したAdobe Marketo EngageおよびHubSpotの仕様・上限値は、2026年10月23日取得時点の各社の公式ドキュメントの内容に基づいています。仕様・上限・価格はいずれも変更される可能性があるため、実際の計画策定時には各公式ページで最新の内容をご確認ください。APIの割当量はサブスクリプションによって異なるため、自社インスタンスの実値を管理画面でご確認ください。