Migrate from Helpshift to Zendesk

Helpshift Issues map directly to Zendesk Tickets. We preserve issue status, priority, created and updated timestamps, assignee (mapped to Zendesk Agent by email match), Tags, and all Custom Issue Field key-value pairs as Zendesk ticket fields. The Helpshift issue ID is stored in a Zendesk custom field hs_issue_id__c for cross-reference audit. Closed tickets in Zendesk cannot be modified after closure, so we validate that all issue status transitions are complete before migration cutover.

Helpshift Custom Issue Fields export from Settings > Workflows as per-app schemas and attach to Issues as typed key-value pairs. We map each CIF to a Zendesk ticket field — text CIFs become Zendesk text fields, number CIFs become integer fields, checkbox CIFs become Zendesk checkbox fields. Dropdown CIFs are mapped to Zendesk dropdown or tag fields, but Zendesk's dropdown field has a practical limit well below Helpshift's 1,000-option cap. If any CIF exceeds this threshold, we split it into multiple Zendesk fields or convert to a text field during transformation.

Helpshift End Users (the consumers submitting Issues) map directly to Zendesk End Users. We preserve email, display name, user metadata fields (device platform, app version, language) as Zendesk user fields. User identity is preserved for issues created under SDK X or SDK versions 6.x and above. Issues created under legacy SDK versions below 6.x may show users as anonymous — we flag this gap in the data audit and annotate affected tickets with a migration note rather than creating false user records.

Helpshift Agents map to Zendesk Agents. Role mapping: Helpshift Admin maps to Zendesk Admin, Helpshift Supervisor maps to Zendesk Agent with group management access, Helpshift Agent maps to Zendesk Agent. We resolve agents by email match against the Zendesk destination user table. Any Helpshift Agent without a matching Zendesk user account is held in a reconciliation queue for the customer's Zendesk admin to provision before the agent-assigned ticket migration begins.

Helpshift Apps define which SDK configurations and settings apply to a given issue stream, with multiple apps potentially feeding a single inbox. Zendesk does not have an equivalent App object — channels (email, chat, web, mobile SDK) are configured independently in Zendesk Admin. We document each Helpshift App's channel bindings, SDK configuration keys, and platform scope during discovery, then translate them to Zendesk channel and widget configuration. This is a manual rebuild step that the customer's Zendesk admin completes using our configuration inventory.

Helpshift FAQs organize into Sections with article body text, section hierarchy, and publication state all exposed via REST API. We map each FAQ Section to a Zendesk Guide Section and each FAQ Article to a Zendesk Article, preserving article body HTML, section parent-child relationships, and draft versus published state. Translation status, language tags, and helpfulness vote counts migrate as article metadata fields. If the destination Guide instance uses the Enterprise hierarchy (up to five nested levels of sections), we preserve the full Helpshift depth.

Helpshift Tags attach to Issues as a flat label list. We export all tag names and their associated issue IDs. Tags migrate to Zendesk Tags with no transformation required — the tag name is the dedupe key. Zendesk Tags attach to Tickets as a flat label list, matching the Helpshift model. During migration, we batch-apply tags to Zendesk Tickets after ticket import completes to avoid write-order conflicts.

Attachments on Helpshift Issues export as file references with metadata. We download binary files from Helpshift via API, store them in a migration blob store, and re-upload to Zendesk with a direct reference back to the parent Ticket. Large binary files may exceed Helpshift API payload limits during extraction — we chunk large file downloads and resume on transient failure. Zendesk enforces file size limits per attachment; we validate attachment sizes against Zendesk's limits during the mapping phase and flag any that exceed the threshold.

Helpshift message threads nested within Issues export via REST API as a flattened per-issue timeline. We map each message to a Zendesk Ticket Comment — the message body becomes comment body, sender identity resolves to the Zendesk user by email match, and timestamp preserves as comment created_at. Both agent and end-user messages are mapped. Public messages map to public comments; internal notes map to internal comments if the destination Zendesk account has the private comments feature enabled.

Helpshift Automations trigger on issue events (create, time-elapsed, keyword match) such as auto-tagging, auto-assigning, or auto-replying. Automations are workspace-level configuration stored in the Helpshift dashboard and are not exposed via REST API as structured exportable data. We document every automation rule (trigger conditions, action types, target filters) during the discovery phase and deliver a written inventory mapping each Helpshift automation to a Zendesk Trigger or Macro equivalent. The customer's Zendesk admin rebuilds these post-migration. We do not migrate automations as code.

Helpshift Smart Views are saved filter sets that organize Issues into queues for agents. Queues define routing and priority. Both are workspace configuration rather than record-level data and are not exportable via API. We document every Smart View's filter conditions, sort order, and column configuration during discovery. Each Smart View maps to a Zendesk View with equivalent filter criteria. Views are recreatable in Zendesk Admin and we deliver the full specification for manual rebuild. This is typically a half-day to one-day effort per environment depending on Smart View count.

Helpshift tracks user-level metadata including device platform, app version, OS version, language, and SDK version. This data is attached to issues rather than stored as a standalone user object. We preserve it by annotating it into Zendesk User fields (for cross-ticket user context) and into custom fields on the Ticket for issue-level reference. If the metadata schema is complex, we may store it as a JSON-encoded custom field value on the User record rather than creating a separate field per metadata key.