Migrate from Salesforce Sales Cloud to Twenty CRM

Salesforce Account maps to Twenty Company. Account.Name becomes Company.name, Account.Industry maps to a Company industry picklist, Account.AnnualRevenue and Account.NumberOfEmployees migrate to Company fields. Parent-Account hierarchies require sequence: we import root Accounts first, then child Accounts with a parent_company_id reference resolved to the previously imported root. If the org uses Salesforce Territory Management, Territory Account assignments migrate as Company tags or a custom Company field rather than a native territory object — Twenty does not replicate Salesforce's Territory model.

Salesforce Contact maps to Twenty Person. Contact.FirstName, Contact.LastName, Contact.Email, Contact.Phone, Contact.Title migrate directly. The Contact.AccountId lookup maps to a Person-Company relationship in Twenty that we resolve after both Company and Person records are committed. A Contact without a populated AccountId migrates as a Person with no company linkage, which is valid in Twenty's data model.

Salesforce's many-to-many Account Contact Relation junction object has no direct Twenty equivalent. Each Contact that has multiple Account relationships via AccountContactRelation must be handled as a 1:N split: we import the primary Contact-to-Account link as the Person-Company relationship, then capture additional Account relationships as Company tags or a custom multi-value field on the Person record. If the customer needs full fidelity on the many-to-many relationships, we flag this during scoping and the customer decides whether to accept the tag-based representation or manually recreate non-primary relationships post-migration.

Salesforce Lead maps directly to Twenty Person. Lead.FirstName, Lead.LastName, Lead.Email, Lead.Phone, Lead.Company, Lead.Status, Lead.Rating, LeadSource migrate to corresponding Person fields. The Lead.IsConverted flag is preserved as a custom field on the Person so that pre-conversion Lead records can be distinguished from native Person records after migration. Converted Leads do not create Accounts and Contacts in Twenty — we import them as Person records at their pre-conversion state with a flag.

Salesforce Opportunity maps to Twenty Opportunity with StageName, Amount, CloseDate, Probability, Description, Type, and LeadSource preserved. Opportunity.AccountId maps to the Twenty Opportunity-Company relationship via the Company ID resolved from the migrated Account. Opportunity.OwnerId maps to the Twenty User ID resolved via email match during Owner reconciliation. Multi-currency Opportunity amounts migrate as the numeric Amount with the currency code stored in a custom field; Twenty does not have native multi-currency support so the customer sets a single base currency for the workspace.

Salesforce Case maps to Twenty Task records or a custom Case object depending on the customer's configuration preference. Case.Status becomes Task status, Case.Priority becomes Task priority, Case.Subject becomes Task name, and Case.Description becomes Task body. Case.ContactId maps to the Person ID resolved from the migrated Contact. If the org uses Salesforce Entitlement Management or multi-step case resolution workflows, we flag these as post-migration configuration items because Twenty's Task model is simpler and does not include entitlement SLA tracking natively.

Salesforce Campaign maps to a Twenty custom object (Campaign) because Twenty does not have a native Campaign object. We pre-create the custom Campaign object in the Twenty workspace with fields for Name, Budget, Status, Type, StartDate, and EndDate. Campaign Members (Contact or Lead responses) migrate as Task records linked to the Campaign custom object, or as Campaign-related Tags on Person records — the customer chooses the representation during scoping.

Salesforce Contract maps to a Twenty custom object (Contract) if the customer needs structured contract lifecycle data, or to a Note attached to the relevant Company record for simpler cases. Contract.StartDate, Contract.EndDate, Contract.Status, Contract.AccountId migrate to the custom object fields or Note body. Contract Line Items require a separate custom object migration pass after Contracts are committed.

Salesforce Products (Product2) map to a Twenty custom object (Product) with Name, ProductCode (from Standard Pricebook), Description, and IsActive preserved. Pricebook Entries require a separate pass: we create the Pricebook as a custom object and associate Product-Pricing records as child entries.

Salesforce OpportunityLineItem maps to a Twenty custom object linked to the migrated Opportunity. Quantity, UnitPrice, and TotalPrice migrate directly. We resolve the Pricebook2 and Product2 references at migration time after both the Pricebook custom object and Product custom object are committed.

Salesforce Task maps to Twenty Task with Subject, Status, Priority, ActivityDate, Description, and OwnerId preserved. Task subtyping (Call, Email) is stored in a custom Task type field in Twenty if the native task model does not support subtype distinction. Task WhatId references (Account, Opportunity, Case) are resolved to Twenty Company, Opportunity, or Task IDs respectively after parent records are committed.

Salesforce Event maps to Twenty Task with StartDateTime as ActivityDate, EndDateTime captured in a custom end_time field, Location preserved, and Description. Event attendees are not a native Twenty object — we create Tasks for each invited Contact or Lead with an attendee flag, or we create a Note on the primary Event-Task capturing the attendee list as text.

Salesforce Notes (the legacy Note object) migrate to Twenty Note records linked to the parent record (Person, Company, or Opportunity). Note.Body migrates as Note body text, and Note.Title becomes the Note name. Notes attached to multiple parent records create separate Note records in Twenty per parent link.

Salesforce Custom Objects migrate to Twenty custom objects of equivalent name within the Twenty workspace. We pre-create the destination schema using the Twenty workspace schema builder, including all custom fields, picklist values, and lookup relationships, before any data import. Each custom object in Salesforce that has lookup relationships to standard objects requires those lookups to be resolved to the migrated IDs of the parent records. Custom object naming preserves the __c suffix convention in a comment field for audit trail.

Salesforce User records map to Twenty User by email match. Active Users get Active=True in Twenty; inactive Users can be imported as inactive Twenty Users or flagged for manual provisioning. Salesforce Profile and Role assignments are not replicated in Twenty's simpler role model — we document the original Role hierarchy as a written handoff for the customer's admin to reconfigure Twenty workspace roles post-migration.