Migrate from Sugar Serve to Intercom

Sugar Serve Cases map to Intercom Conversations. The mapping is not purely 1:1 on record ID because Intercom does not use a case record type — each Conversation is a thread of messages linked to a Contact or Lead. We map case status (New, Assigned, Pending, Closed) to Intercom conversation state (open, resolved, snoozed) and preserve case priority (High, Medium, Low) as a custom conversation attribute or tag. The original case number from Sugar becomes a custom attribute on the Intercom Conversation for cross-reference during the transition window.

Sugar Serve Accounts map directly to Intercom Companies. The account name becomes the company name, and the service_level field (Sugar Serve's contractual SLA tier) maps to a custom company attribute (e.g., sla_tier) that Intercom Inbox rules or Fin AI routing can reference for SLA-based assignment. We use account name as the dedupe key during import and resolve any account-domain data as the company domain field.

Sugar Serve Contacts map to Intercom Contacts. Email address is the dedupe key. We map contact fields (name, phone, title, address) to the standard Intercom Contact schema and attach the source Account linkage as a company relationship. Any custom Contact fields created in Sugar Studio migrate as custom Contact attributes in Intercom. Contacts without an email address require special handling — we flag these during scoping and either assign a placeholder email or flag them for manual review.

Sugar Serve Leads map to Intercom Leads. Lead status lifecycle (New, Assigned, Converted, Recycled) migrates to Intercom's Lead model with a custom attribute tracking the original Sugar status for audit. Lead sources and scoring values from Sugar migrate as custom attributes on the Intercom Lead.

SugarBPM workflow definitions are configuration metadata, not data records, and do not migrate as executable code to Intercom. We export the workflow package and produce a written inventory of every active SugarBPM workflow with its trigger (record save, field change, time-based), conditions, and actions. Each workflow gets a recommended equivalent in Intercom: Inbox rules for routing, Workflows for automated replies and tag application, or Fin AI rules for AI-handled triage. The customer's Intercom admin rebuilds these post-migration.

Sugar Serve Studio custom modules have unique database schemas that require explicit field-level mapping to Intercom Custom Objects. Intercom Custom Objects support external_id and external_created_at attributes plus relationship links to Contacts or Companies. We inspect all active custom modules during scoping, extract field definitions, and generate a Custom Object schema in Intercom before import. Fields that do not map directly to Intercom's attribute types (dates, numbers, booleans, strings) are stored as string attributes with format documentation for the customer's admin.

Sugar Serve Notes attached to Cases map to internal Conversation Parts in Intercom (the agent-side notes visible within a conversation thread). Notes attached to Accounts or Contacts migrate as Contact or Company notes in Intercom. We preserve the note body and created timestamp, and attach the note to the corresponding Conversation or Contact record via the Intercom API.

Case attachments from Sugar Serve migrate as file attachments on the corresponding Intercom Conversation. We extract file references from Sugar CRM records, download each file, and re-upload to Intercom via the Conversation Attachments API. Intercom enforces a 10 MB per-file limit. Files exceeding 10 MB are flagged during scoping for the customer's admin to handle as external links or archive.

Sugar Serve Projects (enterprise deployments) migrate to an Intercom Custom Object named Projects. Project name, status, milestone dates, and description migrate as custom attributes. Project-to-Case linkage (if present in the source) is preserved as a relationship between the Project Custom Object and the corresponding Conversation.

Sugar Serve Bug records migrate to an Intercom Custom Object named Bug. Bug status, priority, and resolution fields migrate as custom attributes. Linkage to Cases (present in some Sugar Serve deployments) is preserved as a relationship link from the Bug Custom Object to the corresponding Conversation.

Sugar Serve Targets and Target Lists have no direct Intercom equivalent. Targets map to Intercom Leads, and Target Lists map to Intercom Segments (dynamic rules based on contact attributes). We flag Target Lists for the customer's admin to recreate as Intercom Segments using the contact attributes migrated from Sugar.