Migrate from Sugar Serve to Zendesk

Sugar Serve Cases map to Zendesk Tickets with Case priority, status, type, and description preserved. The case_to_account linkage resolves to a Zendesk Organization lookup; the case_contact_id resolves to a Zendesk User (requester). We preserve the original Sugar Serve case number in a custom ticket field original_sugar_case_id for cross-referencing. If the source instance uses portal-visible case status flags, we map those to standard Zendesk ticket statuses during import.

Sugar Serve Accounts map to Zendesk Organizations. The service_level field (Sugar Serve's SLA tier indicator) maps to a custom Organization field sla_tier__c that we create in Zendesk before import. Account name becomes Organization name, and we use the domain field from Sugar as a secondary identifier for deduplication. If the source uses parent-account hierarchies, we preserve those as Zendesk Organization parent relationships.

Sugar Serve Contacts map to Zendesk Users (agent-type = end-user). The contact_to-account relationship resolves via the Organization lookup. We map email, phone, title, and any custom Contact fields from Studio to Zendesk User fields or custom user fields. Contact primary_address and other_address fields map to Zendesk's user location and address fields.

Sugar Serve Leads map to Zendesk Users in end-user type. Lead status lifecycle migrates to a custom user field lead_status__c. If the customer's Zendesk setup uses the potential customer organization pattern (grouping pre-contact leads under a placeholder Organization), we configure that during scoping based on the customer's ticket routing preferences.

Sugar Serve Notes attached to Cases migrate as Zendesk Ticket Comments. We resolve the related_id linkage to the target Ticket during import. Note body (rich text) migrates as HTML-formatted comment body. Notes attached to Accounts or Contacts without a case linkage migrate as Zendesk User or Organization comments.

Case and record attachments are extracted from Sugar Serve's file repository and re-uploaded to Zendesk via the Zendesk API. We handle file type detection and size validation at import time. Attachments exceeding Zendesk's 50MB per-file limit are flagged for the customer to host externally with a link stored in the ticket.

Each Sugar Serve custom module is a separate database table with a unique schema defined in Studio. During scoping, we inspect all active custom modules, extract field definitions, and create equivalent Zendesk Custom Objects with matching field types. Zendesk's new Custom Objects framework (post-September 2023) uses a flat field schema; any Sugar custom modules with nested or hierarchical data require redesign into multiple separate objects. We document this remapping explicitly during discovery.

The service_level field on Sugar Serve Accounts captures contractual tier (Tier 1, Tier 2, etc.) for SLA routing. Zendesk has no native SLA tier field on Organizations, so we create a custom Organization field sla_tier__c in Zendesk before migration and populate it from the source service_level values. This field can then be used in Zendesk SLA policy routing rules.

SugarBPM workflow definitions are configuration metadata, not data records. We export the workflow package and deliver a written inventory of every active SugarBPM workflow with its trigger conditions, field update actions, email alerts, and record save actions mapped to equivalent Zendesk triggers and macros. The customer or a Zendesk partner rebuilds these post-migration.

Sugar Serve's Projects module migrates as Zendesk Tickets tagged with a project identifier, or as a Zendesk Custom Object depending on the customer's preference. Project tasks and milestone dates migrate as ticket due dates or custom date fields. Resource assignments (user allocations) do not map directly to Zendesk agents because Zendesk is ticket-centric, not project management-oriented; we flag this gap for the customer to address with a project management integration.

Sugar Serve Bug records migrate as Zendesk Tickets with a bug_ticket__c custom field flag and the original bug status preserved. Linkage to Cases is resolved by matching the related_case_id to the migrated ticket number and stored as a custom ticket field linked_bug_id.