Migrate from Customer.io to Nutshell

Customer.io People records map to Nutshell Contacts. The userId maps to Contact email as the primary lookup key; anonymousId records with no email are flagged for identity resolution before import. All trait key-value pairs migrate as custom fields or mapped standard fields (email, name, phone, address) where the field name matches a Nutshell standard field. Nested JSON trait values flatten into separate custom fields. Profile created_at and last_seen timestamps migrate as custom date fields for audit and recency analysis.

Customer.io Custom Objects with a company-like schema (name, domain, industry, employee_count) map to Nutshell Accounts. Each Custom Object type_id namespace becomes a distinct record set, and we pre-create the Nutshell custom field schema before import. If the Customer.io workspace has Companies linked to People via relationships, we resolve the link and attach the Contact to the Account during import. Custom Objects without a People relationship are imported as standalone Accounts.

Customer.io Segments are dynamic audience definitions based on trait conditions and event triggers. Nutshell Groups are manually managed membership lists. We export each segment's criteria as a structured rule set and create a corresponding Nutshell Group with a documented membership criteria note. Full dynamic-segment behavior cannot be replicated in Nutshell; the Group is created with its current membership snapshot and maintained manually post-migration. If the customer uses segments as tags rather than dynamic lists, we map them to Nutshell Tags instead.

Customer.io event history (track calls) is event-driven and stored as a first-class object with name, properties, sentAt, and receivedAt timestamps. Nutshell has no native event store. We transform the event history into Nutshell Activity records (type Note) on the Contact, with the event name in the activity subject, event properties as plain-text body, and the original timestamp preserved. High-volume event histories are batched via the Nutshell API with rate-limit handling to avoid throttling during import.

Trait key-value pairs on Customer.io People map to Nutshell custom fields. Standard Nutshell fields (name, email, phone, address) are used where schema alignment exists; non-standard traits create new custom fields in Nutshell before migration. Array and nested-object trait values are serialized as JSON strings in the corresponding custom field. We flag any traits that share a name with existing Nutshell standard fields to avoid collision during import.

Customer.io Campaigns and Journeys are automated workflows with triggers, branching conditions, and multi-channel message actions. These do not migrate as automation code because Nutshell Pipelines track deal stages, not campaign logic. We export the campaign structure (name, trigger type, steps, channels, and wait conditions) as a structured document and deliver it to the customer's admin. The admin rebuilds outreach sequences as Nutshell email templates and manual or semi-automated follow-up tasks. Broadcast sends are documented separately for manual re-execution.

Customer.io one-time broadcast sends are exported with target segment, content, and send timestamp. Nutshell does not support broadcast sending as a platform feature. We export the broadcast name, audience, content, and send timestamp as a written record so the customer can re-execute or adapt the send manually post-migration. If the broadcast targeted a Customer.io segment, we document the segment membership snapshot as a Nutshell Group for manual reference.

Customer.io counts profiles deleted within the current billing cycle as billable. We flag any profiles deleted between the migration export date and the billing cycle close date so the customer can assess whether they need to act before month-end billing recalculates. We also flag active integrations that could re-import deleted profiles mid-migration, recommending the integration be suspended before the final export to prevent billing duplicates.

Customer.io Custom Object types beyond Companies that do not map to a standard Nutshell object (e.g., Products, Subscriptions, Projects) are handled as custom fields on the related Account or Contact record. We pre-create the Nutshell custom field schema before migration, defining the field type to match the source data (text, number, date, dropdown). Relationships between Custom Objects and People in Customer.io become cross-field references or linked Contact records in Nutshell.

Customer.io transactional messages (password resets, order receipts, shipping notifications) are exported with their content, trigger conditions, and delivery logs. Nutshell has no transactional message capability. We deliver the transactional message content as a structured export file so the customer's engineering team can route these sends through a dedicated transactional email service (such as SendGrid, Postmark, or AWS SES) post-migration. Any unsubscribe or preference flags migrate to Contact email opt-out status.