Migrate from Sugar Sell to Twenty CRM

Sugar Accounts map to Twenty Companies. The Account name becomes Company.displayName, industry maps to Company.industry, website to Company.domain, and billing address fields map to Company.address fields. We resolve the Account ID foreign keys on Contact, Opportunity, and Case before importing those related records. If the source uses multi-address accounts, the primary billing address is used for Company and secondary addresses are stored as Note attachments for manual reconciliation.

Sugar Contacts map to Twenty People. Name fields (first_name, last_name) map to Person.name; email maps to Person.email; phone maps to Person.phone; title maps to a custom field (Person.jobTitle is available as a standard field in Twenty). The Contact-to-Account relationship (account_id) maps to a Company relation on Person. We use email as the dedupe key during import to catch duplicate contacts that may exist in Sugar.

Sugar Leads map to Twenty People rather than a separate Lead object, because Twenty does not ship a distinct Lead object by default. Lead status (New, Assigned, In Progress, etc.) is preserved in a custom text field lead_status__c on the Person record. Lead source, score fields, and any custom lead fields migrate as custom fields on Person. The customer's admin decides post-migration whether to use a Person type or tag to distinguish converted leads from imported contacts.

Sugar Opportunities map directly to Twenty Opportunities with amount, close_date, and pipeline stage preserved. Stage names are mapped via a translation table at migration time. Opportunity amount maps to Opportunity.amount; probability maps to a custom field probability__c since Twenty does not include a native probability field on Opportunity. The Opportunity-to-Account relationship resolves to Opportunity.company via the Company lookup.

Sugar's separate Calls, Meetings, and Tasks objects all map to Twenty Task records. We add a custom field task_type__c (Call, Meeting, Task) to distinguish the original Sugar type. Duration, status, date, and related parent fields (contact_id, lead_id, opportunity_id) migrate with the Who and What relation resolved to the corresponding Twenty Person or Opportunity record. The related Account is resolved via the parent Person or Opportunity lookup.

Sugar Cases map to Twenty Task records with case-specific fields (priority, resolution, case_number) stored as custom fields on the Task. If the customer's Twenty workspace has a custom Case object defined, we use that instead. The Case-to-Account and Case-to-Contact relationships resolve to Company and Person lookups respectively. Bug Tracker-specific fields (found_in_version, fixed_in_version) are stored as text fields and flagged for manual review.

Sugar Quotes migrate as Opportunity attachments rather than a native quote object, because Twenty does not include a standard Quotes module. We extract Quote PDFs and line item data as Note records or attachments on the linked Opportunity. The Quote number and total amount are preserved in custom fields on the Opportunity for reference. If the customer requires native quoting, Twenty's roadmap may include it; we flag this as a known gap and recommend the customer monitor Twenty's release notes.

Sugar Product Catalog entries map to a Twenty Custom Object named Product. Product name, SKU, pricing, description, and categorization fields map to custom fields on the Product object. If the destination Twenty workspace uses a different product-related object name, we align during scoping. Product bundles from Sugar map to Note attachments on the Product record.

SugarBPM workflow definitions do not migrate as automation code. We extract every active SugarBPM workflow during discovery, documenting its trigger module, condition logic, action sequence, and any external HTTP call or assign-team steps that may not have a Twenty equivalent. This inventory is delivered as a written document with Twenty's workflow builder referenced as the rebuild target. Workflows that reference custom fields require those fields to be created in Twenty first.

Sugar Studio custom fields are defined in vardef PHP files and stored in the Sugar database. We extract custom field definitions (field name, type, required flag, dropdown options, relationship definitions) during discovery and deliver a written field inventory that maps each Sugar vardef to a Twenty custom field created via Settings / Data Model. The Twenty /metadata GraphQL API is used to create fields programmatically before data import begins. Fields must exist before the CSV import runs.

Sugar Notes migrate to Twenty Note records. Text content maps to Note.body; attachment files are extracted from Sugar's file system or API response and re-uploaded to Twenty as file attachments linked to the parent record (Person, Company, or Opportunity). We preserve the Note creation timestamp and the associated parent record type and ID from Sugar.

Sugar Users map to Twenty WorkspaceMembers. We resolve by email match. Any Sugar User without a matching Twenty WorkspaceMember is held in a reconciliation queue for the customer's admin to provision before record import resumes. Team membership (which determines record-level access in Sugar) maps to Twenty's workspace member roles, which the admin configures in Settings after migration.

Sugar Tags are stored as string values linked to records. We extract all Tags across modules, create matching tag sets in Twenty, and relink to the migrated Person, Company, and Opportunity records. The customer's admin chooses whether to use Twenty's native Tag feature or a custom multi-select field for Sugar tag equivalents.