Migrate from Re:amaze to Zendesk

Re:amaze Conversations map to Zendesk Tickets. The conversation subject maps to Ticket Subject, the primary message thread becomes the initial ticket comments, assignee maps to Zendesk Agent, status (open/resolved/archived) maps to Ticket Status, and category maps to Ticket Type or a custom field. We preserve the original Re:amaze conversation ID as a custom field reamaze_conversation_id__c on the Zendesk ticket for cross-reference during the reconciliation window.

Re:amaze Contacts map to Zendesk End Users. Name and email transfer directly; computed attributes (browser, location, last seen) transfer as custom user fields. Re:amaze contacts are the parent of conversations, so Contact records migrate first so that the Zendesk requester_id reference is satisfied at ticket creation time. Any Re:amaze contact without an email address is flagged as a partial record and migrated as an end user with a generated placeholder email for admin resolution.

Re:amaze custom fields have no dedicated definition endpoint; values are stored as attributes on contact records. We discover the field map by sampling 50-100 contact records, extracting all non-standard keys, and typing them (text, number, checkbox, date, dropdown). The resulting field map is validated against the full contact set before import. Each discovered custom field is pre-created as a Zendesk User Field before contact migration begins.

Re:amaze conversation tags (flat string list per conversation, admin-created and agent-applied) map to Zendesk Ticket Tags. Tag names transfer as-is with no transformation. We export all tags in a single pass before conversation migration so that the tag inventory is available for Zendesk tag creation during ticket import.

Re:amaze Quick Answers (canned response templates with title, body content, optional shortcode, and category grouping) map to Zendesk Macros. We preserve the HTML formatting in the macro body, the category becomes the macro folder, and the shortcode is stored as a custom macro field. Macros are created before ticket migration so that agents can apply them immediately at cutover.

Re:amaze FAQ articles (searchable, category-grouped, embeddable) map to Zendesk Guide articles. The category hierarchy migrates as Zendesk Guide Sections and Categories. Article content transfers with HTML preserved. Publish status migrates (published articles become live, draft articles remain draft). Zendesk Guide must be activated in the destination Zendesk instance before article import because it is a separate product requiring manual setup.

Re:amaze agent profiles (name, email, role: admin/agent, avatar, availability status) map to Zendesk Agents. We map agent emails to Zendesk User accounts by email match. Role mapping: Re:amaze admin becomes Zendesk Agent with admin rights; agent becomes Zendesk Agent. The customer provisions the Zendesk agents before migration so that the assignee_id reference on imported tickets is satisfied.

Re:amaze multibrand accounts (separate inboxes, contacts, and reporting per brand via subdomain) require a separate Zendesk instance migration pass per brand. Each brand's data is extracted using the correct brand-specific subdomain in the Re:amaze API request, and loaded into a separate Zendesk instance or organizational structure. We scope and quote each brand pass independently. Zendesk's own Multibrand organizational structure is documented as a separate configuration for the customer admin.

Re:amaze message attachments and contact profile attachments export as file metadata (URL, filename, MIME type, size). Where Re:amaze stores attachments behind signed URLs or on their CDN, we download and re-upload to Zendesk's attachment endpoint. Attachments migrate after tickets so that the ticket_id reference is known at attachment creation time.

Re:amaze Departments map to Zendesk Groups. Group membership on conversations migrates as ticket assignment to the corresponding Zendesk Group. If a Re:amaze department has no Zendesk equivalent, it is stored as a custom ticket field for admin reorganization post-migration.