Migrate from Sugar Serve to Salesforce Service Cloud

Sugar Serve Cases map directly to Salesforce Service Cloud Cases with CaseNumber preserved (either the source auto-number or a mapped custom field if the source uses user-assigned numbering). Status maps to Case Status picklist; Priority maps to Case Priority; Type maps to Case Type. The case-to-account linkage resolves via Account lookup by account name match at migration time. Closed cases, open cases, and their full status history migrate with original dates preserved.

Sugar Serve Accounts map to Salesforce Account. The service_level field on Sugar Serve Accounts (Tier 1, Tier 2, etc.) has no standard Salesforce equivalent; we preserve it as a custom field service_level__c on Account with the same picklist values. Account is migrated first so that the AccountId lookup is satisfied when Cases and Contacts import.

Sugar Serve Contacts map to Salesforce Contact. The contact-to-account relationship migrates by resolving the Sugar Serve Account name to the newly created Salesforce AccountId. Custom Contact fields created in Sugar Serve Studio migrate as custom Contact fields in Salesforce with equivalent data types. Contacts without a matching Account are held in a queue for manual resolution.

SugarBPM workflow definitions are configuration metadata, not data records, and cannot be imported into Salesforce. We export the full SugarBPM process definition package and produce a written Flow inventory that maps each SugarBPM process trigger, condition branch, field update action, and email alert to a corresponding Salesforce Flow (record-triggered, scheduled, or screen) or Process Builder equivalent. The customer's Salesforce admin or a certified partner rebuilds the automations post-migration.

Sugar Serve Leads migrate to Salesforce Lead with their status lifecycle preserved. Any lead_score or custom scoring field from Sugar Serve maps to a custom Lead field lead_score__c. Lead conversion settings in the destination Salesforce org (the lead status values that qualify as Converted) are configured during scoping to match the source lifecycle.

Portal-visible cases in Sugar Serve carry portal-specific status flags that are gated by the Enterprise license. We identify these cases during scoping, map the portal-specific statuses to standard Case statuses, and flag which cases require Experience Cloud portal provisioning in the destination. Portal user records and access settings do not migrate; these are provisioned separately in Experience Cloud.

Sugar Serve's service_level field on Account drives SLA tiering at the case level. In Salesforce, Entitlement records link to Account and define the SLA terms; Entitlement Process defines milestone targets (First Response, Resolution) per entitlement. We split the source service_level into Entitlement records (one per Account tier) with milestone definitions, and link each Case to its Account's Entitlement by matching the tier value.

Sugar Serve Notes attached to Cases, Accounts, and Contacts migrate as Salesforce Note records linked via ContentDocumentLink to the parent record. Note body migrates as rich text. The related_id and related_type from Sugar Serve are resolved to the Salesforce record IDs generated during the migration so that parent linkage is preserved.

Case and record attachments stored in Sugar Serve's file repository are extracted and re-imported as Salesforce ContentVersion records linked to the parent Case, Account, or Contact via ContentDocumentLink. We handle file type detection, charset normalization for international filenames, and size limits ( Salesforce's 25 MB per file limit) by splitting large attachments. The original Sugar Serve attachment filename is preserved in the ContentVersion Title field.

Sugar Serve's Bugs module (tracking product defects linked to Cases) can migrate to Salesforce as Case records with a custom record type (Defect) or as a custom object depending on whether the customer wants defects in the same case management stream or a separate object. We recommend during scoping based on the customer's existing Salesforce configuration. Status, priority, and resolution fields migrate; linkage to Cases requires the parent Case ID resolution step.

Sugar Serve Studio allows entirely custom modules with arbitrary schemas. Each custom module is a separate database table; we perform field-level discovery during scoping, extract all custom field definitions, pre-create the corresponding Salesforce custom object schema (with __c API names) in the destination org, and import the records after parent standard objects are migrated. Custom module relationship fields (lookups to Cases, Accounts, Contacts) require ID resolution after parent migration.