Migrate from Hesk to Salesforce Service Cloud

Hesk Tickets map directly to Salesforce Case records. Hesk's ticket ID becomes the Case CaseNumber or is stored in a custom field hesk_ticket_id__c for audit traceability. Hesk status (open, pending, resolved, closed) maps to Salesforce Case Status picklist values, and Hesk priority (low, medium, high, critical) maps to Case Priority. Owner assignment resolves via email match to the destination Salesforce User. Custom fields on Hesk tickets migrate to custom Case fields with equivalent data types.

Hesk stores the requester as a name and email within the ticket record (or as a linked user). We extract the requester into a Contact record first, then set Case ContactId as a Lookup during Case import. If the requester email matches an existing Salesforce Contact, we link to that record; otherwise we create a new Contact. Name, email, IP address (for audit), and creation date transfer. GDPR anonymisation requests are handled before Contact creation if requested.

Hesk Knowledge Base articles with title, HTML content, category association, and optional attachments map to Salesforce Knowledge articles. Hesk KB categories map to Salesforce Knowledge data category groups that the customer's admin defines during scoping. Articles are imported in Draft status first, reviewed, and then published by the admin post-migration. Inline images in article HTML are handled as ContentDocument attachments linked via ContentDocumentLink.

Hesk ticket categories (support, billing, technical, etc.) map to Salesforce Case Record Types with corresponding Page Layouts and Business Hours assignments. If the customer uses Hesk category-specific routing, we document the mapping for Omni-Channel routing rule configuration in Service Cloud post-migration.

Hesk end-user accounts (customers who submit tickets) map to Salesforce Contact records. Fields migrated include name, email, IP address (for compliance and audit), account creation date, and any user-level custom fields. Users without emails (phone-only contacts in Hesk) are created with email as a required field on Salesforce Contact using a generated placeholder if necessary.

Hesk staff accounts (agents and administrators) map to Salesforce User records. Role hierarchy in Hesk (administrator, manager, agent) maps to Salesforce Role hierarchy and Profile assignments that we configure during migration. Password hashes do not transfer; the customer resets passwords post-migration. Staff custom fields migrate to User custom fields.

Hesk ticket custom fields are stored as field definition rows and value rows in MySQL. We enumerate all custom field definitions during discovery, map each to a Salesforce custom field on Case with the equivalent data type (text, picklist, date, number, checkbox), and import the values during Case migration. Field-level security is set to read-write for the relevant Profiles during import and tightened post-migration.

Hesk user custom fields migrate to Salesforce Contact or User custom fields depending on whether they are staff or end-user fields. We pre-create the destination fields before user migration and map values during the user import phase.

Hesk canned responses (pre-written reply templates with title and HTML content) map to Salesforce Email Templates or Macros. If the customer uses Salesforce Macros for agent productivity, we map canned responses to Macro definitions with target objects and field values. Email templates are imported as Salesforce Content objects for use in Case Email Actions.

Hesk ticket attachments live on the server file system with paths stored in MySQL. We export the entire attachments directory alongside the database extract, verify path consistency, and re-upload each file as a Salesforce ContentVersion linked to the parent Case record via ContentDocumentLink. If the destination Salesforce org uses a different domain, attachment URLs are re-mapped post-import.

Hesk ticket history logs events (opened, replied, status changes, assignment) in a history table. We merge these into Salesforce as Case Feed entries (via Connect API for Chatter feed) or as EmailMessage records representing each reply and status change. The full original timestamp and actor (staff name) are preserved in the body text. If the destination org does not use Chatter, we document the history mapping for manual reconstruction.

Hesk settings (email routing, ticket field labels, status names, branding) are exported as a configuration bundle and delivered as a written document. Equivalent settings in Salesforce are applied by the admin during post-migration configuration: Case Status values, Case Priority values, Salesforce Email-to-Case routing, and Org Branding. This is a manual configuration step, not an automated data import.