Migrate your Customer.io data

The core Customer.io object. Every profile has a userId, optional anonymousId, timestamped traits, and event history. We export all attributes including nested JSON and preserve the full event timeline during migration. Deleted profiles that were re-added in the same billing cycle are flagged to prevent double-billing.

Events are created via the track() API and stored with a name, properties object, and sentAt/receivedAt timestamps. We export all event names and property schemas and map them 1:1 into the destination. Event names must be unique strings; we flag any naming collisions before import.

Traits are key-value pairs set on a Person via identify() or track calls. They can take any JSON type including arrays and nested objects. We flatten or preserve nested structure depending on the destination schema, and we flag boolean opt-out fields to ensure GDPR/CCPA compliance in the target system.

Segments are dynamic audience definitions based on trait values and event conditions. We export segment criteria as a structured rule set and rebuild equivalent segments in the destination using that logic. Complex nested conditions may require manual verification in the target system.

Campaigns are automated workflows with entry triggers, branching conditions, and message actions. We export campaign structure including trigger type, wait steps, and channel assignments. Workflow logic (especially branching and A/B split paths) requires field-level mapping to match destination campaign semantics.

Broadcasts are one-time sends to a segment or full audience. We export broadcast name, target segment, content, and send timestamp. API-triggered broadcasts have a rate limit of 1 request per 10 seconds, which we respect during re-import to avoid queue overflow.

Custom Objects (Companies, Accounts, etc.) are stored as separate object_type_id namespaces with their own object_id per record. They can have custom fields and are linked to People via relationships. We export the object type definitions and all object records and rebuild the object_type_id hierarchy in the destination, preserving relationship links to People.

Transactional messages are single, recipient-specific sends (receipts, password resets) that bypass standard unsubscribe rules. We export transactional message templates, content, and delivery logs. Message retention settings must be checked before export — sensitive content may be redacted in stored payloads.

Workspaces contain billing, SSO, IP allowlists, and region settings (US/EU). These are account-level and not migratable across platforms. We exclude workspace config from the migration scope and flag which settings need manual reconfiguration in the destination.

We can export message delivery status (sent, delivered, undeliverable, bounced) for audit and compliance purposes. Delivery logs are linked to Person records via messageId. Undeliverable statuses are preserved so the destination can apply the same suppression rules.