Migrate from UseResponse to Zendesk

UseResponse Tickets map directly to Zendesk Tickets. We preserve ticket subject, description (migrated as first comment), status, priority, assignee (via owner email lookup), and topic association. Topic assignments map to Zendesk Tags by default unless the customer configures a custom ticket field for topic routing. Custom ticket fields require pre-enumeration against the UseResponse API because every account has a different schema; we map each by type (text, dropdown, checkbox) to a matching Zendesk field type before import.

UseResponse Agents map to Zendesk Users with the role of agent or admin preserved. We resolve agents by email match against the destination Zendesk org. Any Agent without a matching Zendesk User goes to a reconciliation queue for the admin to provision before ticket import begins, because Zendesk requires a valid assignee reference at the time of ticket creation. On Zendesk Team and above, agents can be assigned to groups for queue-based routing.

UseResponse Customers map to Zendesk End Users (the requester field on Tickets). We preserve email, name, company name (mapped to Zendesk organization if present), and any lifecycle stage or contact property as a custom field. End Users are created before Tickets so the requester_id reference is satisfied at the moment of ticket insert.

UseResponse Topics are categories that group and route tickets to specific teams. Zendesk has no native Topics object; we map Topics to Tags by default, applying the source topic name as a Zendesk tag. If the customer wants team-based routing in Zendesk, we recommend configuring Zendesk Groups and mapping Topics to group membership instead, which requires manual group setup in Zendesk Admin before migration.

UseResponse Comments on tickets migrate as Zendesk Ticket Comments. We preserve comment authorship (mapped to the Zendesk User), comment body (converted from UseResponse HTML to plain text or Zendesk-supported markup), and timestamp (ActivityDate on the comment). The internal-vs-public visibility flag from UseResponse maps to Zendesk's public (comment visible to end user) or internal (note) distinction. We flag any comments exceeding 65,536 characters for manual review as Zendesk has a body field limit.

Attachments on tickets and comments migrate as Zendesk Ticket Attachments (inline images) or file attachments via the Zendesk API. We preserve original filenames and MIME types. Inline images embedded in comments migrate separately from file attachments. Any attachment exceeding Zendesk's 50 MB per-file limit is flagged for the customer's admin to store externally and link via URL. Inline images in HTML-formatted comments are extracted and re-hosted as Zendesk inline attachments.

UseResponse KB Articles map to Zendesk Guide Articles with title, body (HTML content), and visibility preserved. Articles are the most complex mapping object because UseResponse's flat category model differs from Zendesk Guide's section hierarchy. We map UseResponse categories to Zendesk Guide sections at the same level of nesting as the source, but deeply nested hierarchies (more than 5 levels in Zendesk Guide Enterprise) require consolidation during import. Article attachments migrate as Guide article attachments.

UseResponse Knowledge Base categories map to Zendesk Guide Sections. We preserve section name, sort order, and parent-child hierarchy. On Zendesk Suite Enterprise Guide, sections support up to 5 levels of subsection nesting; on lower tiers the hierarchy is flat. We flag any category with more nesting than the destination plan supports and consolidate into a flat section structure with article titles prefixed to indicate hierarchy.

UseResponse configurable ticket statuses (New, Open, Pending, Solved, Closed, and any custom labels) map to Zendesk Ticket Status values. We preserve custom status-to-status transition labels but Zendesk's status model uses a simpler open-pending-closed triad at the API level. Custom status labels are mapped to Zendesk status field values, and the customer configures any non-standard transitions in Zendesk Admin post-migration.

UseResponse custom fields on tickets are account-specific and require enumeration against the account's API before mapping. We capture field label, data type, and any picklist options during discovery. Each enumerated field maps to a Zendesk custom ticket field of the matching type (text, dropdown, checkbox, date, etc.). Fields with validation rules (required, format regex, conditional required) are flagged because Zendesk will reject imported values that violate destination validation rules; we either disable those rules during import or map to a less restrictive field type.

UseResponse tags applied to tickets and articles map to Zendesk Tags by name. We preserve the tag name and associations to the parent record. Zendesk Tags are flat (no hierarchy) while UseResponse tags can have a flat structure; we do not preserve UseResponse tag grouping if any exists. Tags with special characters are sanitized to Zendesk's tag name constraints (alphanumeric, hyphens, underscores).

UseResponse's Feedback System tracks user-submitted ideas and votes. Zendesk has no native feature-request or feedback-voting object. We do not migrate Feedback Items as records; instead, we export Feedback Item titles, descriptions, vote counts, and status to a CSV delivered to the customer's Zendesk admin. The admin rebuilds these as a private ticket queue in Zendesk (with tags for categorization) or implements a third-party feedback tool such as Canny, ProductBoard, or UseResponse's own Feedback System re-enabled as a separate integration. This is explicitly a rebuild scope, not a data migration.