Migrate from Sugar Sell to Salesforce Sales Cloud

Sugar Accounts map directly to Salesforce Account. The account_name, industry, website, phone, and address fields migrate 1:1. We use the Sugar account_id as an external ID to prevent duplicate Account creation on re-runs. Sugar's team hierarchy (which determines record access) maps to Salesforce Role and Territory if the customer uses those sharing models.

Sugar Contacts do not have a direct Salesforce equivalent because Sugar uses a single Contact object while Salesforce splits unqualified prospects into Leads and qualified buyers into Contacts attached to Accounts. We define the split rule during scoping based on the customer's Sugar contact lifecycle: contacts with a specific status or tag indicating pre-conversion map to Salesforce Lead; all others map to Salesforce Contact attached to the parent Account via AccountId. We preserve the original Sugar contact status in a custom field sugar_original_status__c on both Lead and Contact for audit and reporting continuity.

Sugar Leads map to Salesforce Lead. Sugar lead_status, lead_source, and any custom lead scoring fields migrate to Salesforce Lead. The Salesforce Lead object is created before Contact migration so that the Contact-to-Lead relationship (if the customer converts Leads to Contacts in Sugar) can be resolved during import. Sugar's lead_id is preserved as an external ID for reconciliation.

Sugar Opportunities map to Salesforce Opportunity. The opportunity_name, amount, date_closed, sales_stage, and probability fields migrate 1:1. Sugar pipeline stages map to Salesforce StageName values, and we configure a Sales Process in Salesforce that whitelists the relevant stages before migration. Closed-Lost and Closed-Won dates and reasons migrate as custom fields if present in Sugar.

Sugar separates Activities into Calls, Meetings, and Tasks. Calls migrate to Salesforce Task with TaskSubtype=Call, preserving call disposition, duration, and recording URL in custom Task fields. Meetings migrate to Salesforce Event with StartDateTime, EndDateTime, and Location preserved. Tasks migrate to Salesforce Task with Status, Priority, and ActivityDate preserved. All activity records are linked to the parent Sugar record via the migrated Salesforce ID, and WhoId/WhatId are resolved to the correct Lead, Contact, Account, or Opportunity at migration time.

Sugar Cases (including the Bug Tracker variant) map to Salesforce Case. Case priority, status, resolution, and account/contact links migrate 1:1. Bug Tracker-specific fields (reproducibility, severity, version) have no Salesforce Case equivalent and are preserved in a custom text area field bug_tracker_fields__c as JSON for admin review post-migration.

Sugar Quotes map to Salesforce Quote if the destination org has Sales Cloud with Quotes enabled. Quote line items migrate as QuoteLineItems with Pricebook2 and Product2 references resolved. Tax, discount, and PDF attachment links migrate to Salesforce QuoteDocument if the source PDF was stored as a Sugar file attachment.

Sugar Product Catalog entries (Products, Manufacturers, Product Types) map to Salesforce Product2 records. The Sugar manufacturer_name and product_type fields migrate to custom fields on Product2. Standard Price Book entries are created during migration to enable Quote line item association.

SugarBPM workflow definitions, sequences, and alert templates do not migrate to Salesforce Flow. They are documented as named records with their trigger module, conditions, actions, and sequence ordering preserved in a written workflow inventory document. The customer's Salesforce admin or a Flow developer rebuilds each workflow in Flow Builder. We flag any SugarBPM action types that have no Salesforce Flow equivalent (e.g., certain external HTTP call actions) for manual redesign.

Sugar custom fields added via Studio require extraction from vardef PHP files (not from the Sugar database or CSV export). We read the vardef files during discovery, extract field name, type, label, and default value, then create equivalent Salesforce custom fields via the Salesforce Tooling API or Setup UI before data import begins. Custom field relationships (dependent picklists, formula fields) are also extracted from vardef dependencies and recreated in Salesforce. This step requires the customer's Sugar admin to provide vardef file access or a Module Loader export package.

Sugar Notes (text entries and file attachments) migrate to Salesforce Note records. Text content migrates as Note Body; file attachments are extracted from Sugar's file system or API response and re-uploaded to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Account, Contact, Lead, or Opportunity.

Sugar Tags are flexible labels stored as string values linked to any record. We extract all distinct tag values per module, then either create a Salesforce multi-select picklist field on the relevant object or create a custom tagging object with a junction table depending on the customer's reporting needs. The customer chooses the tag strategy during scoping.

Sugar Users map to Salesforce User records. We resolve users by email match. Any Sugar User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Team membership from Sugar maps to Salesforce Groups or Roles depending on the customer's chosen sharing model.

Sugar Reports and saved Dashboards are stored as serialized view definitions tied to Sugar module field IDs. We migrate the report structure and field names as a written document but field ID references must be remapped manually in Salesforce Reports because Sugar field IDs do not map to Salesforce field IDs. The customer's admin rebuilds each report in Salesforce Report Builder using the migrated field names as a guide.