Migrate from BenchmarkONE to Twenty CRM

BenchmarkONE Contacts map to Twenty People. All standard fields (firstName, lastName, email, phone, title, address, social profiles) map 1:1. The BenchmarkONE Temperature field (lead scoring proxy) has no native Twenty equivalent and is preserved as a custom number field temp_score__c. Contact Status maps to a custom single-select field contact_status__c. Lead Source maps to a custom field lead_source__c. Tags migrate as a comma-separated string field that we normalize into Twenty Topics after import.

BenchmarkONE Company records map directly to Twenty Company records. Company Name maps to displayName, Website maps to domainName, and the associated contacts are linked via the Twenty person-company relationship. We use domain as the dedupe key during import. The BenchmarkONE Account Company ID is preserved in a custom field benchmarkone_company_id__c for reconciliation.

BenchmarkONE Deals map to Twenty Opportunities. The pipeline stages map to Twenty Opportunity stage values that we configure before import. Deal amount, close date, and assigned sales rep transfer directly. Any custom deal fields become Twenty custom fields on the Opportunity object. We create the opportunity stage values in Settings → Data Model before migration begins.

BenchmarkONE Tasks linked to Contacts, Companies, or Deals map to Twenty Tasks. Due date, status, priority, and assignee transfer directly. Tasks are imported after their parent Contact or Company record exists in Twenty so that the relationship is satisfied at insert time. Task body migrates as a text field on the Task object.

BenchmarkONE tags are stored as comma-separated strings on Contact records. We split each tag list and create corresponding Twenty Topics via the Twenty API. The migration user chooses at scoping whether to use Topics (recommended for segmentation and filtering) or a custom multi-select field on Person (recommended if tag count is small or tags are used as labels rather than categories). This is a configuration decision made before import begins.

BenchmarkONE custom fields on Contacts and Companies are audited during scoping. Field definitions and values are included in the full database export. We pre-create matching custom fields in Twenty via Settings → Data Model before any record import. Field type mapping: BenchmarkONE text becomes Twenty text, date becomes date, number becomes number, checkbox becomes boolean, dropdown becomes select. Fields must exist in Twenty before the CSV import runs; Twenty's import creates records, not fields.

BenchmarkONE user accounts map to Twenty WorkspaceMembers. We extract every distinct owner referenced on Contacts, Companies, Deals, and Tasks and match by email against the Twenty workspace members list. Twenty requires that all users be invited and have accepted their invitations before owner lookups on imported records are satisfied. Missing users are held in a reconciliation queue; the customer's admin provisions them before the record import phase resumes.

BenchmarkONE stores social profile URLs (LinkedIn, Twitter/X, Facebook, etc.) on the Contact record. We map each social profile to a named URL field on the Twenty Person object. If the social platform is not a standard Twenty field, it is stored in a custom URL field named for the platform (e.g., linkedin_url__c).

BenchmarkONE email campaign metadata (name, send date, audience count) migrates as a written reference document, not as a live record. Twenty CRM has no native email campaign object. We preserve campaign names and send dates in a custom object email_campaign_ref__c so the customer's admin has an audit trail of what campaigns existed in BenchmarkONE. Actual campaign content, templates, and performance data (opens, clicks) do not migrate; these are reconstructed in the customer's chosen email marketing platform.

BenchmarkONE automations are platform-native workflow constructs triggered by form submissions, website visits, tag changes, or purchases. Twenty CRM does not have a native automation builder in v1. We document every active automation's trigger, conditions, and actions during discovery and deliver a written automation inventory with recommended equivalents (e.g., manual task creation, third-party automation tools, or custom scripts). This is a manual reconstruction step, not a data migration, and is scoped separately.