Migrate from Customer.io to HubSpot

Customer.io people map directly to HubSpot contacts. Email serves as the primary identifier for both platforms. Custom traits on the profile become HubSpot custom properties — we create each property in HubSpot's schema before migration and preserve the original attribute values.

Customer.io segment membership is a dynamic filter result, not a static list. We capture segment membership at migration time and write each segment name as a HubSpot custom property (Segment_Membership__c) so you can rebuild equivalent segments in HubSpot using list membership or static lists.

Customer.io companies map 1:1 to HubSpot companies. The company identifier (id or external_id from Customer.io) is stored as a custom property for traceability. HubSpot company properties like domain, industry, and employee count map from corresponding Customer.io company attributes. All standard HubSpot company properties receive data where Customer.io provides equivalent attributes.

Customer.io's person-to-company relationship (identifying which people belong to which company) migrates to HubSpot's contact-company association. HubSpot supports primary and secondary company associations — the primary company from Customer.io becomes the primary association in HubSpot. Multi-company memberships are preserved as secondary associations in HubSpot.

Customer.io custom objects (Accounts, Employers, etc.) map 1:1 to HubSpot custom objects. We create the custom object type in HubSpot, map all custom attributes to HubSpot custom properties, and preserve object-to-object relationships using HubSpot's association labels. Each custom object requires schema configuration in HubSpot before migration data is loaded.

Customer.io events are arbitrary behavioral track calls with custom event names and properties. We categorize common event patterns (page_view → logged page view, purchase → deal activity) and map them to HubSpot engagement types where semantically equivalent. Less common events migrate as custom event properties on the contact record for reference and future HubSpot workflow triggers.

HubSpot sets CreatedDate at migration time. Customer.io's created_at timestamp is preserved as a custom datetime property (Original_Create_Date__c) on each contact so reporting continuity is maintained and historical analysis reflects the original account creation date. This ensures all historical reports reference the true first contact date.

Customer.io's internal person ID (cio_id) is stored as a custom text field (Source_System_ID__c) on the HubSpot contact for traceability, delta-run de-duplication, and audit purposes. This prevents duplicate contact creation on subsequent migration runs and enables accurate record matching across platform syncs.

Customer.io has no native deal or opportunity object. If your team has built deal-like structures as custom objects in Customer.io, we map those to HubSpot's native Deals object or to a custom object with deal-equivalent properties (amount, stage, close_date, contact_role). Your admin configures the pipeline and stage model before migration.

Customer.io has no native support-ticket model. If your team manages support case data, we can create a HubSpot Ticket object or custom object to receive that data. Ticket properties (subject, status, priority, pipeline) require HubSpot Service Hub configuration before data lands.

Customer.io workflows and journeys contain campaign logic, trigger conditions, and branching that cannot be exported in a runnable form. We extract your workflow definitions as documentation (trigger names, conditions, action steps) for your HubSpot admin to rebuild using HubSpot's automation tools (workflows, sequences, bots).