Migrate from Customer.io to Twenty CRM

Customer.io People records map to Twenty CRM Person objects. The email address serves as the dedupe key during import. Standard CRM fields (name, email, phone, job title, address components) are extracted from traits where present. The Customer.io userId is stored in a custom field for audit traceability. Any trait that does not map to a native Twenty field is created as a custom field during schema setup. Anonymous profiles with no email are flagged in the reconciliation report and held for admin decision before import. Event history is not embedded in the Person record but migrated as separate Activity records.

Customer.io Custom Objects with object_type_id indicating a company map to Twenty CRM Company records. The company name is the primary field; domain and website are extracted from traits and mapped to the corresponding Company fields. Relationships to People are preserved as a Company-Person association in Twenty. Custom fields on the Customer.io company object migrate to Twenty Company custom fields.

Customer.io segment membership is exported as a list of segment names per Person. In Twenty, each segment name becomes a Tag applied to the Person record. Because segments in Customer.io are dynamic (membership changes with trait updates), we capture membership as a snapshot at migration time. The written handoff document includes the full segment criteria for the customer to rebuild equivalent dynamic segments as Twenty Views and saved filters.

Customer.io Custom Object namespaces beyond Companies (for example Products, Partners, or custom relationship objects) map to Twenty CRM custom objects. We pre-create the destination schema in Twenty before import, including all custom fields matching the source object_type_id field definitions. Lookup relationships between custom objects and People are resolved at migration time using the object_id and the corresponding Person record.

Customer.io custom events (created via track()) migrate to Twenty CRM Activity records. Each Activity record stores the event name, properties as a JSON field, and the original timestamp. The Activity is linked to the corresponding Person record via a Person lookup. Event properties are not flattened into individual fields to preserve schema flexibility. Activity records are readable in the Twenty timeline but do not drive segmentation in the same way Customer.io event triggers do.

Email send events recorded in Customer.io migrate as Activity records in Twenty. The activity title captures the email campaign or broadcast name, and the properties field stores subject line, send timestamp, and delivery status (sent, delivered, bounced, undeliverable). The Activity is linked to the Person record. Note that Customer.io broadcast API has a rate limit of 1 request per 10 seconds; large email send histories are chunked during export to avoid rate-throttle gaps.

Call engagements recorded in Customer.io migrate as Activity records in Twenty with call disposition and duration stored in the Activity properties. Each Activity is linked to the Person record via lookup. Call recording URLs stored in Customer.io are not importable and are flagged in the written handoff for manual re-linking post-migration.

Meeting engagements migrate as Activity records in Twenty with start and end timestamps, location, and attendee list preserved in the properties field. Each Activity links to the Person record. Meeting recording links stored in Customer.io are flagged for manual re-association.

Customer.io note engagements map to Comment records in Twenty CRM linked to the Person timeline. The note body migrates as plain text. Attachments on notes cannot be imported via CSV and are flagged in the written handoff for manual re-upload. Note author is stored in the Comment author field.

Task engagements in Customer.io migrate as Activity records in Twenty. Task status (completed, open) maps to Activity completion. Assigned owner resolves by email match to the corresponding Person record if the assignee is a Customer.io user who also exists as a Person in Twenty.

Customer.io Broadcasts are one-time sends to a segment or full audience. They do not migrate as live automations because Twenty's workflow engine has a different trigger and action model. We export broadcast configuration including name, target segment, content, and send timestamp as a structured JSON document delivered in the written handoff. The customer's admin rebuilds equivalent one-time outreach sequences in Twenty Workflows using the exported criteria.

Customer.io Campaigns and Journeys are automated workflows with entry triggers, branching conditions, and multi-channel message actions. These do not migrate as automation code because Twenty's workflow engine uses a different trigger-action model and does not support the same multi-channel campaign step types. We export the full campaign and journey structure including trigger conditions, wait steps, branching logic, and channel assignments as a structured document. The customer's admin rebuilds equivalent sequences in Twenty Workflows using the exported criteria.