Mailchimp to HubSpot Migration

Mailchimp's Customer Journeys, the visual builder with branching paths and delay steps, have no HubSpot counterpart to import into; the whole thing becomes a Workflows build from a blank canvas.

HubSpot: Workflows

There is no export format to work from, only the canvas as it stands in Mailchimp today, so document it before touching anything. Workflows themselves sit behind a plan tier in HubSpot; check the feature table for which one before promising the rebuild is included.

The older, classic Mailchimp automations that predate Customer Journeys rebuild as HubSpot workflows with delay steps.

HubSpot: Workflows with delay steps

These are the more straightforward rebuild of the two: simpler logic than a full Customer Journey and usually a fairly direct one-to-one translation into HubSpot.

A campaign that Mailchimp generates automatically from a content feed on a fixed schedule needs its own equivalent set up in HubSpot rather than a data migration.

HubSpot: Blog subscription emails or RSS email

HubSpot has a native equivalent for this, so reconfigure the feed URL and the send schedule rather than treating it as a rebuild from nothing.

Transactional sends running on Mailchimp's Mandrill backend need their own migration path entirely, separate from the marketing email rebuild.

HubSpot: Transactional email add-on with the SMTP or single-send API

HubSpot's transactional email, delivered through the SMTP or single-send API, is a paid add-on sitting on top of a plan-gated Marketing Hub tier, not something bundled in. Price it explicitly in the proposal: this is the line item that most often gets left off a Mailchimp migration quote and then surfaces as a surprise once the transactional sends actually need to move.

Subject line and content split tests configured in Mailchimp do not carry over; each one is reconfigured directly in HubSpot's own A/B testing.

HubSpot: A/B testing in marketing emails

Set each test up again per email inside HubSpot. Whatever the past tests concluded in Mailchimp stays there; the results themselves do not transfer, only the practice of running them going forward.

Mailchimp's per-recipient send-time optimization, timing each email to when that individual is most likely to open it, needs its HubSpot equivalent configured separately rather than assumed to carry across automatically.

HubSpot: Send time optimization or scheduled sends

This sits behind a plan tier in HubSpot as well. Below that tier, sends are scheduled manually, and that is a real difference in day-to-day workload worth flagging before the tier decision is made.

Opens, clicks and conversions tracked per campaign in Mailchimp need their HubSpot reporting rebuilt from the point of migration onward; the reports themselves are not part of what the sync carries across.

HubSpot: Marketing email analytics and campaign reporting

Campaign reporting in HubSpot sits behind a plan-gated Marketing Hub tier, so confirm the tier covers it before relying on the feature. Export the Mailchimp history before cutover regardless, since none of it migrates on its own.

The trend line showing subscriber growth and churn over time has to start over in HubSpot; it is rebuilt from HubSpot data going forward rather than carried across from Mailchimp.

HubSpot: List growth and contact analytics

Everything from this point forward is rebuilt inside HubSpot; there is no way to back-fill the historical growth curve, so whatever multi-year trend the account had built in Mailchimp effectively resets at cutover.

Mailchimp's habit of comparing send performance against industry peers is not something that moves across as a report; HubSpot's own benchmarking has to stand in for it.

HubSpot: Email health tool with industry benchmark

HubSpot does offer a version of this through its email health tool, benchmarking performance against both its own aggregate and an industry figure, so the capability survives, just in a narrower form than the Mailchimp comparison it replaces.

Revenue attributed back to a connected store depends entirely on where the order data actually lands after migration, and that decision determines whether this reporting exists in HubSpot at all.

HubSpot: Deal reporting, or the store's own analytics

If the e-commerce platform stays the system of record for orders, the revenue reporting stays there as well rather than moving into HubSpot; only bringing the order data across brings the reporting with it.

Every Mailchimp template, whether built in the drag-and-drop editor or hand-coded, needs its own path into HubSpot; neither kind arrives automatically formatted and ready.

HubSpot: Marketing email templates and coded templates

Export the HTML and adapt it for HubSpot's editor rather than starting from nothing. Every Mailchimp merge tag inside that HTML needs replacing with the equivalent HubSpot personalisation token, and a bilingual template is worth a specific pass here: an Arabic block laid out right to left is easy to break while swapping tokens in an English-first editor, so check the rendering after each template rather than at the end of the batch.

Landing pages hosted on their own Mailchimp URLs need a visual rebuild in HubSpot; nothing about the page itself, design or URL, carries across.

HubSpot: Landing pages

Treat it as a full visual rebuild, and set up redirects from the old Mailchimp URLs to the new HubSpot ones before decommissioning; skip that step and any inbound traffic or bookmarked link to the old page simply stops working.

Every form embedded across the site that currently posts into Mailchimp has to be found and swapped, one by one, for its HubSpot equivalent.

HubSpot: Forms

Rebuild the forms in HubSpot, then work through the site replacing every embed. Inventory the embed locations first rather than relying on memory, because a form that gets missed keeps quietly posting into the retired Mailchimp account with nobody noticing it stopped arriving anywhere useful.

Pop-up capture running through Mailchimp needs its own equivalent set up in HubSpot rather than being assumed to migrate with the forms it feeds.

HubSpot: Pop-up and banner CTAs

HubSpot's CTA tool covers pop-up, banner and slide-in formats between them, but only on a paid plan, so confirm which tier actually includes it from the feature table before promising it is a like-for-like swap.

The SPF, DKIM and DMARC records currently pointing at Mailchimp have to be re-pointed at HubSpot's sending infrastructure before HubSpot can send on the organisation's behalf at all.

HubSpot: Connected email sending domain

This is DNS work with a propagation delay built in, so start it well before cutover rather than on the day itself. Sending reputation depends on it being correct, and reputation is not something that can be rushed back into place once a cutover date has already been announced to the team.

Posts already scheduled to publish from Mailchimp's social tool need a home in HubSpot's equivalent before the Mailchimp account goes away.

HubSpot: Social tool

HubSpot's social tool is itself plan-gated, and regardless of which tier applies, anything scheduled but not yet published in Mailchimp has to be recreated by hand: there is no automatic carry-over of a scheduled queue.

User accounts carrying account-level roles in Mailchimp have to be recreated as HubSpot users with their own role assignment; the role itself does not transfer, only the need to have one.

HubSpot: HubSpot Users, teams and permission sets

The role mapping between the two systems is loose rather than exact, and HubSpot's teams and permission sets each sit on their own plan requirement. Check both tiers against the feature table before assuming the permission structure the account is used to is included by default.

Any external system holding an API key that writes into Mailchimp is a dependency that has to be found and re-pointed, not just the obvious integrations inside Mailchimp's own settings screen.

HubSpot: HubSpot private app tokens

List every external system holding a Mailchimp key before revoking a single one of them, and re-point each to a HubSpot private app token in its turn. Revoke first and something breaks days later with no obvious cause, because whatever depended on that key gave no warning when it stopped working.

A store platform such as Shopify or WooCommerce that currently feeds Mailchimp needs reconnecting to HubSpot directly rather than assumed to follow the contact data automatically.

HubSpot: E-commerce integrations from the App Marketplace

Reconnect the store to HubSpot through the App Marketplace, and re-verify what actually lands once it does: product and order sync behaviour is not identical to how it worked against Mailchimp, so check the result rather than assuming parity.

A third-party form tool posting its submissions into Mailchimp needs a decision, not just a reconnection: rebuild the form natively in HubSpot, or keep the external tool and capture what it collects a different way.

HubSpot: Forms, or non-HubSpot form capture via the tracking code

Rebuild it as a HubSpot form, or keep the external tool in place and capture submissions through the HubSpot tracking code instead. The tracking code route needs no field mapping contract to set up, but it also ignores any hidden field on the form, which is worth checking before choosing it.

Where a CRM currently reaches HubSpot indirectly, syncing into Mailchimp rather than into HubSpot itself, that hop is worth retiring rather than reproducing.

HubSpot: Direct CRM integration or Data Sync

Connect the CRM directly to HubSpot and retire the Mailchimp hop entirely, rather than rebuilding the same indirect path with HubSpot standing where Mailchimp used to. A direct connection is one fewer system in the chain and one fewer place data can go stale.

Any Zap that triggers off Mailchimp or writes into it needs its trigger and action swapped for a HubSpot equivalent; none of it repoints itself.

HubSpot: Zapier HubSpot triggers and actions

Go through each Zap individually: re-select the trigger, re-select the action, and redo the field mapping from scratch rather than assuming the old mapping still applies once the endpoint has changed.