Migrate from HubSpot to Customer.io: The SaaS Team's Guide

HubSpot was built for sales teams. Customer.io was built for lifecycle teams. Both are excellent at their respective jobs. The problem arises when a product-led company tries to use HubSpot's marketing hub to run lifecycle marketing that depends on product behavioral signals — and discovers that HubSpot's architecture sees those signals as an afterthought.

SaaS teams migrate from HubSpot to Customer.io at a predictable moment: when their lifecycle program has grown sophisticated enough that HubSpot's property-update trigger model, its CRM-centric data hierarchy, and its contact-to-deal relationship structure are actively working against what the lifecycle team needs to build. Trial expiration sequences that need to fire the second a trial ends, not when a property syncs. Onboarding Campaigns that branch on which features a user has actually adopted, not on a contact property updated by a Zap. Payment failure sequences that fire from Stripe in real time, not from a workflow delay.

At Propel, we've run this migration for SaaS teams across multiple verticals. This guide covers what the shift from HubSpot to Customer.io actually requires.

What HubSpot Can't Do That Drives the Migration

Property-update triggers vs. event triggers. HubSpot's workflow logic is property-based. A workflow fires when a contact property changes — "Trial Status" changes to "Active," "Plan" updates to "Pro." The change is often created by a Zap, a manual update, or a delayed sync. Customer.io workflows fire on events — trial_started fires from your backend the moment a trial begins, with properties like plan_type, trial_length_days, and acquisition_source immediately available for branching and personalization. The precision and speed are structurally different.

CRM hierarchy vs. flat person model. HubSpot's data model is Contact → Company → Deal. Lifecycle marketing on HubSpot for B2C or product-led SaaS teams means working within a B2B CRM architecture that adds relationship layers that don't reflect how product users actually exist. Customer.io's Person model is flat and event-rich — every user has Attributes and Events, with no company or deal hierarchy required unless your use case genuinely needs it.

Workflow complexity ceiling. HubSpot workflows are sequential and property-conditioned. For lifecycle programs with more than 10–15 active automations, complex conditional branching, or real-time behavioral triggers across multiple product systems, HubSpot's workflow builder becomes an operational burden. Customer.io's Journeys handle complexity without the workarounds HubSpot requires at scale.

No native event tracking. HubSpot doesn't have a native event stream from your product. Events require custom code, Segment integration, or a third-party connection. Customer.io's API and SDKs are the primary instrumentation mechanism — event tracking is built into the platform's core, not bolted on.

The Architecture Shift: HubSpot to Customer.io

HubSpot's model: Object-relational and CRM-centric. Contacts are linked to Companies and Deals. Workflows trigger on contact property changes, list membership, or form submissions. Email is the primary lifecycle channel. Marketing sequences are separate from sales sequences. The data model reflects B2B sales process, not product-led user behavior.

Customer.io's model: Event-driven and person-centric. Every person has Attributes (profile properties with no CRM hierarchy) and receives Events (behavioral actions from any source, with properties). Campaigns trigger on Events fired in real time. Segments filter on Attributes and event history. The data model reflects product behavior, not sales stage.

The migration consequence: HubSpot contact properties map to Customer.io Attributes. HubSpot workflow triggers — property changes, list additions — must be converted to Customer.io event triggers, which requires identifying the source event (backend action, SDK fire, or API call) that causes the property change HubSpot was reacting to. HubSpot workflows become Customer.io Campaigns rebuilt from the entry event up.

This is the most intellectually interesting part of the HubSpot migration. You're not just rebuilding workflows — you're tracing back from property-based triggers to the underlying product events those properties were proxies for. In most cases, that tracing reveals that the event itself is a more precise trigger than the property update was. A trial_activated event that fires the moment a trial begins is a better onboarding Campaign trigger than a "Trial Status = Active" property update that fires with a 5-minute delay.

What Transfers and What Doesn't

Transfers With Mapping ✅

Contact properties → Attributes. HubSpot contact properties — first name, last name, company, plan type, lifecycle stage, custom fields — map to Customer.io Attributes. Document every property used in active workflows, email templates, or segment definitions. Unused properties don't migrate.

Email unsubscribes and hard bounces. HubSpot's unsubscribed and hard bounced contacts transfer to Customer.io's global suppression before any active contacts are imported. This is the non-negotiable first step in data migration.

Email templates (with rebuild). HubSpot's template syntax is proprietary. Templates must be rebuilt in Customer.io's email editor with Liquid personalization replacing HubSpot's token system. {{ contact.firstname }} becomes {{ customer.first_name }}. The logic is identical; the syntax differs.

Must Be Rebuilt 🔄

Every workflow becomes a Campaign. HubSpot workflows cannot be imported into Customer.io. Every automation — onboarding sequences, trial conversion, payment failure, re-engagement — must be rebuilt natively as a Customer.io Campaign. Rebuild in revenue-impact priority order. For SaaS churn prevention, rebuilding the trial-to-paid conversion Campaign first is almost always the right call.

Trigger logic. Every HubSpot property-update trigger must be converted to a Customer.io event trigger. This requires identifying the source action — the API call, the product event, the Stripe webhook — that was causing the property to update, and connecting that source directly to Customer.io instead. Our events and attributes architecture service manages this mapping as a formal pre-migration deliverable.

Segments. HubSpot's smart lists are rebuilt as Customer.io segments using Attribute and event filters. The conditions are translatable in concept; the syntax is platform-specific.

Stays in HubSpot ❎

CRM, sales sequences, deal pipelines. HubSpot continues to handle B2B CRM functions if your team uses them. Customer.io handles lifecycle marketing for your product users. These are parallel tools for parallel jobs — the migration is a functional split, not a full replacement. Many SaaS teams run both post-migration. Clarify which contacts migrate to Customer.io (product users) and which stay in HubSpot (sales pipeline contacts) before the migration starts.

The Event Instrumentation Phase: What HubSpot Teams Need to Know

This is the phase that most HubSpot teams underestimate, because HubSpot doesn't require it. HubSpot's workflows run on property updates that your existing CRM sync or Zapier connection manages. You've never had to think about your event schema.

Customer.io requires a designed and instrumented event stream. Every trigger in every Campaign corresponds to an Event that fires from your product backend, your app, or your data pipeline directly to Customer.io. That Event must have the right name, the right properties, and the right data types — and it must fire at the right moment in the user journey.

This is not a significant engineering lift for most SaaS teams. Customer.io's API is well-documented and straightforward. But it is a deliberate step that requires technical involvement from day one. The event schema design happens before any Campaign is built. Our lifecycle strategy engagement starts with this schema work — mapping your product's key behavioral moments to the event names and properties that will power your Campaigns.

For fintech teams with complex event schemas across multiple product systems, or teams in health and fitness with app behavioral data spanning multiple touchpoints, this design phase is worth investing extra time in. It determines the ceiling of what your Customer.io program can do.

Migration Checklist: HubSpot to Customer.io

Pre-Migration

• Inventory all active HubSpot workflows — trigger condition, channel, entry volume, 30-day performance.
• Map every workflow trigger — property update or list enrollment — to its source product event.
• Document all contact properties in active use across workflows and email templates.
• Identify which contacts are product users that migrate to Customer.io versus sales pipeline contacts that remain in HubSpot.
• Design the Customer.io event schema based on the trigger mapping exercise.

Data Migration

• Export HubSpot unsubscribed contacts — import to Customer.io global suppression first.
• Export hard bounces — import to Customer.io suppression.
• Export active product-user contacts with all relevant properties — import as Customer.io People with Attributes.
• Segment import by engagement tier before uploading.

Technical Setup

• Instrument Customer.io API and SDK events per the designed event schema.
• Validate every event fires with correct properties via Customer.io's activity log.
• Configure sending domain in Customer.io — DKIM, SPF, DMARC. Reference email deliverability channel health standards.
• Set up subscription preferences and global unsubscribe in Customer.io.

Campaign Rebuild

• Rebuild Campaigns in priority order — onboarding, trial conversion, retention, re-engagement.
• Rebuild email templates with Customer.io Liquid personalization.
• QA every Campaign with test events before activating.
• Deactivate the equivalent HubSpot workflow the moment the Customer.io Campaign is live.

Go-Live

• Email deliverability warm-up — engaged contacts first, expanding weekly over 4–6 weeks.
• Monitor bounce and complaint rates daily during warm-up.
• Keep HubSpot Marketing Hub in read-only mode for 30 days post-migration.

Stakeholder Expectations

Lifecycle and marketing team: Budget 8–12 weeks. The trigger logic redesign — from property-update to event-based — is the most strategically demanding phase. It requires lifecycle team input on what behaviors should trigger what messages, and engineering input on what events are technically available to fire.

Engineering team: 2–3 weeks for event instrumentation and validation. This is the phase that HubSpot teams are least prepared for because HubSpot didn't require it. Plan it explicitly in the migration timeline.

Sales team: HubSpot stays. The migration is a lifecycle marketing function split. Sales workflows, sequences, and CRM functions are unaffected. Brief the sales team before migration starts.

Leadership: Set the 90-day post-migration baseline before the transition begins. Brief leadership on the deliverability warm-up period — the first 4–6 weeks of reduced send volume is structural, not a performance signal.

Working With Propel on Your HubSpot to Customer.io Migration

Propel is a certified Customer.io partner. We have run HubSpot-to-Customer.io migrations for SaaS and subscription brands navigating the B2B-CRM-to-behavioral-messaging transition. Our practice covers the trigger logic redesign — the most HubSpot-specific part of this migration — as well as event schema design, Campaign rebuild, and deliverability management.

If you're earlier in the decision process, our guide on the full migration to customer.io scope covers the platform-agnostic migration framework in detail.

Talk to a Propel operator about your HubSpot to Customer.io migration.