Migrate from Oncord to Twenty CRM

Oncord's primary Contact record maps to Twenty's People object. Standard fields (name, email, phone, address, website) transfer directly. Owner assignment on Contact (the team member responsible for the record) maps to Twenty's Account Owner field via email match against the Twenty Members list. We extract all Contact records through Oncord's CustomFields API component and account backup. Note that Twenty's People object starts with minimal standard fields out of the box; we create all required custom fields in Twenty's Settings Data Model before running the import, because the CSV import creates records only, not fields.

Oncord does not have a native Company or Account object; contact records store company affiliation in custom fields or the contact's organization name. We extract any explicit company data stored in Oncord's contact records or Custom Fields and map it to Twenty's Company object. The company name becomes the Company Name field; website, industry, and address migrate as Company fields or custom fields. If the customer has not used Oncord's contact schema to store company data separately, we document this gap during scoping and the customer decides whether to create Company records from contact affiliations post-migration.

Oncord Groups function as static segmentation lists attached to Contacts. We export all Group definitions and map each Group membership (contact-to-group relationship) to Twenty's Tag system. Tags in Twenty are stored as a multi-select field on the People record. During import, we resolve each Contact's group memberships and write them as comma-separated or multi-value Tag entries. We note that Twenty's native filtering works on Tags, but Groups used for complex conditional logic in Oncord automations will require manual reconfiguration in Twenty's workflow builder post-migration.

Oncord exposes CustomFields via its internal API component. We extract custom field definitions (name, type, options) and values for each Contact record. Before importing into Twenty, we create matching custom fields in Settings Data Model, mapping Oncord types to Twenty field types (text to Text, number to Number, date to Date, dropdown to Select). Fields must exist in Twenty before the CSV import runs; the import does not create fields, only records. We handle the type mapping and flag any Oncord field types (e.g., complex multi-select or relational fields) that have no direct Twenty equivalent and require a custom field configuration workaround.

Products are available only when the Commerce add-on ($40/month) is active on Oncord. We confirm add-on status during scoping before attempting to export. Product data (name, description, price, SKU, inventory count, images) maps to a Twenty Custom Object named Products or similar. We pre-create the Custom Object schema in Twenty, including fields for name, description, price, sku, and stock_quantity, then import via CSV. The customer should decide during scoping whether historical product data and images are worth the additional migration effort, since this is a best-effort configuration given Twenty's absence of a native e-commerce module.

Events in Oncord include RSVP functionality, attendee lists linked to Contacts, date, location, and capacity. We export event definitions and attendee records (linked to Contact IDs) when the Marketing add-on is active. In Twenty, we create a Custom Object named Events with fields for name, event_date, location, capacity, and status. Attendee records are stored as separate Custom Object entries with a lookup relationship to the People record. The RSVP workflow itself (trigger emails, capacity enforcement) does not migrate and must be rebuilt manually in Twenty's workflow builder post-migration.

Oncord automation workflows trigger on contact activity, group membership, or time-based schedules. We document each workflow's structure including triggers, conditions, filters, and actions, but the workflow logic does not migrate. Twenty's workflow builder uses a different trigger-and-action model, and Oncord's automation engine has no export format compatible with Twenty. We deliver a written inventory of all active Oncord workflows with a description of each trigger, condition branch, and action sequence, so the customer's admin can manually rebuild them in Twenty's workflow builder. Workflows must be recreated as a separate admin task post-migration; this work is outside standard migration scope.

Oncord includes unlimited admin users on base plans. We export user records (name, email, role) and map them to Twenty Members. Owner assignment on Contact records (which team member owns the contact) resolves via email match against the Twenty Members list during import. Any Oncord Owner without a matching Twenty Member is placed in a reconciliation queue, and the customer provisions the missing Member before record import resumes. Role semantics differ between platforms; Oncord role-based access maps to Twenty's workspace Members and permissions model.

Oncord web forms capture contacts and carry custom field mappings per form. We export form definitions and field-to-contact-property mappings as a written inventory. Twenty does not include a native form builder in its standard feature set; the customer rebuilds forms using their preferred form tool (Typeform, Tally, or a custom implementation) and maps form fields to Twenty custom fields documented in the inventory. This is a manual configuration task for the customer's admin post-migration.

Discounts and coupons are available only with the Commerce add-on. We export discount rules, coupon codes, eligibility conditions, and usage limits when the Commerce add-on is active. These map to a Twenty Custom Object named Discounts with fields for code, discount_type, value, eligibility_rules, and usage_limit. Mapping to Twenty's schema is best-effort; the customer should confirm during scoping whether historical coupon data is operationally necessary or can be reconstructed manually in any replacement commerce workflow.