Migrate from Sugar Serve to HubSpot Service Hub

Sugar Serve Cases map to HubSpot Tickets. The case priority, status, type, and resolution fields map to HubSpot Ticket priority, status, pipeline, and resolution fields. The case-to-account linkage migrates by resolving the Sugar Account name to the HubSpot Company record, and the case-to-contact linkage resolves to the HubSpot Contact record. We create the Company and Contact records first so that the ticket association is satisfied at insert time. Case number is preserved as a custom field hs_case_number__c for audit and cross-reference.

Sugar Serve Accounts (organizations) map to HubSpot Companies. The service_level field on the Sugar Account is Sugar Serve-specific, capturing contractual tier (Tier 1, Tier 2, etc.) used for SLA routing. We preserve this as a custom HubSpot property (e.g., service_tier__c) on the Company record so that SLA policies can reference it post-migration. Account name is the dedupe key during Company import.

Sugar Serve Contacts map directly to HubSpot Contacts. The contact-to-account relationship is preserved by resolving the Sugar Account ID to the HubSpot Company ID during import. Any custom Contact fields created in Sugar Studio require pre-creation of matching HubSpot custom properties before import. Contacts are imported after Companies to satisfy the Company association.

Sugar Serve Leads migrate to HubSpot Leads with status lifecycle preserved. Custom Lead fields from Sugar Studio are mapped to HubSpot custom properties on the Lead object. Lead score values migrate to a custom hubspot_lead_score__c property. If the destination HubSpot account uses Contacts for all person records, the customer chooses during scoping whether to convert Leads to Contacts post-migration or maintain the dual-model approach.

SugarBPM workflow definitions are configuration metadata, not data records. They do not migrate as executable logic. We export the workflow package (triggers, conditions, actions, field updates, email alerts, and branching paths) and deliver a written workflow inventory that maps each SugarBPM rule to the equivalent HubSpot Workflow, List, or Playbook (Enterprise) action. The customer's admin rebuilds these in HubSpot post-migration. SugarBPM modules with complex branching or cross-module triggers require a separate scoping session.

Portal-visible cases in Sugar Serve are gated by the Enterprise license. If the source Sugar Serve instance has cases with portal-specific status flags (e.g., awaiting_customer_reply from portal), we map these to standard HubSpot Ticket statuses and document which statuses should be associated with the customer portal view. The customer portal in HubSpot Service Hub is available from the Professional tier, so license alignment is verified during scoping.

Case and record attachments are extracted from Sugar's file repository and re-imported to HubSpot as Files attached to the corresponding Ticket, Contact, or Company via ContentDocumentLink. File type (PDF, image, document) is preserved. Inline images embedded in case descriptions are handled separately because HubSpot does not support inline image migration; these are flagged for manual re-insertion or CDN re-hosting.

Sugar Serve Notes attached to Cases, Accounts, Contacts, and other records migrate to HubSpot Engagement Notes linked to the corresponding Contact or Company record. Rich text formatting in Sugar Notes is preserved as HTML in HubSpot Notes body. Note timestamps migrate as activity dates for timeline ordering.

Sugar Serve Bug records can be mapped to a HubSpot custom object (if Professional or Enterprise tier) or to Tickets with a Bug-specific pipeline. Bug status, priority, and resolution fields migrate. The linkage to Cases requires re-establishment in HubSpot because Bugs in Sugar can link to multiple Cases; in HubSpot, a custom object relationship or a tag on the Ticket is used to maintain the association. The customer chooses the model during scoping.

Sugar Serve Projects (enterprise deployments) with tasks and milestone dates migrate to a HubSpot custom object if the destination is Professional or Enterprise. Project resource assignments (users assigned in Sugar) require remapping to HubSpot Users by email resolution. If the customer uses Deals for project-like tracking, we document a Project-to-Deal mapping option during scoping.

Sugar Serve Targets (pre-qualified prospects) map to HubSpot Leads. Target Lists map to HubSpot static Lists. Campaign association from Target Lists migrates to HubSpot Campaigns with Campaign Member status preserved. Target scoring values migrate as a custom property on the Lead record.

Sugar Studio custom modules have unique database schemas that require per-instance field discovery. During scoping, we inspect all active custom modules, extract field definitions (field name, type, required/optional, default value), and generate a custom field mapping table. We pre-create HubSpot custom objects with matching property definitions before any data import. Custom modules with lookup relationships to standard objects (Cases, Accounts, Contacts) require HubSpot custom object associations to be created first so that the lookup resolution is satisfied at insert time. Modules with unmapped fields fail silently during import if not explicitly declared.

The service_level field on Sugar Accounts captures contractual tier (Tier 1, Tier 2, etc.) used for SLA routing and agent assignment. We preserve this as a HubSpot custom property (service_tier__c) on the Company object. HubSpot SLA policies can reference this property to set different response and resolution targets per tier. The customer confirms the picklist values during scoping.