Migrate from Bento to Twenty CRM

Bento Contacts map directly to Twenty People records. Standard properties (email, firstname, lastname, phone) map 1:1 to Twenty's name.firstName, name.lastName, email, and phoneNumber fields. CreatedAt and updatedAt timestamps migrate to Twenty's displayName.full and dateFields. Custom fields migrate as additional properties on the Person record; we flag any Bento custom field with a data type not natively supported by Twenty for manual type selection during schema setup.

Bento has no native Company or Organization object. If contacts carry company name data in a custom field or in a property like company, we create Organization records in Twenty and link them via a lookup relationship. This requires a preprocessing step to extract unique company names from contact properties, deduplicate them, create Organization records, then backfill the lookup on each Person record.

Bento tags are flat string labels stored as comma-separated values on each contact. We export the full tag taxonomy and re-apply tags as a multi-value property on each Person record. In Twenty, tags become filter criteria that customers use to build saved filter views rather than a native tagging system with tag management UI. The migration brief documents every distinct tag so the customer can recreate them as filter conditions in Twenty.

Bento custom fields have explicit data types (string, number, date, boolean, choice). We map these 1:1 to Twenty custom fields with equivalent types. Choice fields in Bento become picklist fields in Twenty; multi-checkbox fields in Bento become multi-select picklist fields. We pre-create the destination schema in Twenty before import so that the import payload is fully typed and passes any validation rules the customer has configured.

Bento Segments are dynamic filter rules evaluated on contact properties and Custom Events with scheduled re-evaluation. Twenty has no equivalent scheduled re-evaluation engine. We export the complete segment definition as a structured JSON rule document that the customer's admin uses to build equivalent saved filter views in Twenty. Filter views in Twenty are manual and require periodic refreshing rather than automatic re-evaluation.

Bento maintains a separate suppression list of unsubscribed contacts. We export this as a distinct CSV, then import those email addresses into Twenty as Person records (or match to existing Person records) with the handlebars.unsubscribed flag set to true. This prevents any email sending from the Twenty instance to those addresses post-migration. We do not delete or skip these records because the customer may want to re-subscribe them manually after email preferences are reconfirmed.

Bento's bounced contact list contains hard-bounce and soft-bounce addresses identified during send. We export the bounced list separately from unsubscribed and active contacts, then import them as Person records (or match to existing records) with the handlebars.unsubscribed flag set to true. This prevents the customer's transactional email system from attempting delivery to known invalid addresses. We flag any bounced contact that is also active in the main contact list for deduplication review before final import.

Bento Campaigns have subject, HTML content, send timestamp, open rate, click rate, and revenue attribution. Twenty has no Campaign object. We export campaign metadata (name, subject, send date, total sent, open rate, click rate) as a structured summary CSV for reference. The HTML content is exported separately for the customer to archive or rebuild in their chosen email marketing platform. We do not create campaign records in Twenty because there is no equivalent object model.

Bento Automations are visual flow logic stored in a proprietary format that cannot be exported as executable rules. We export each automation's trigger conditions, delay settings, action nodes, and flow structure as a structured JSON brief and annotated screenshots. The customer uses this brief to rebuild equivalent logic in their chosen automation platform (Zapier, Make, a custom API integration, or a future native Twenty workflow feature). We do not rebuild automations as code in the migration scope.

Bento Custom Events track behavioral signals with specific property schemas. Twenty has no event tracking or behavioral data collection feature in the current release. We export the full event schema (event name, property names, property data types) as a structured schema document. The customer uses this document to configure event tracking in their chosen analytics platform (PostHog, Mixpanel, Amplitude, or a custom event pipeline) as a replacement for Bento's behavioral tracking layer.

Bento's transactional email uses SDK credentials (API key, sending domain, template IDs) for Rails, Laravel, Node, Python, Go, and PHP integrations. We document the API credentials, sending domain configuration, and template ID mappings in a structured configuration export. The customer uses this to reconfigure their transactional email service (Postmark, Resend, AWS SES, or similar) and update their application code to point at the new service rather than Bento. We do not transfer SDK code or reconfigure application integrations.