Migrate from Thena to Zendesk

Thena Request maps to Zendesk Ticket as the primary object. Subject maps to Ticket Subject; Description maps to Ticket Description; Source maps to Ticket Via (Slack, Email, MS Teams, Discord as values); Sentiment and Urgency from Thena's AI inference migrate as custom ticket fields sentiment__c and urgency__c. We preserve the original Thena Request ID in a custom field thena_request_id__c for cross-reference. Status mapping resolves Thena's main status (Open, In Progress, On Hold, Closed) against Zendesk's status taxonomy, with sub-status values mapped to a custom field thena_substatus__c if the customer uses Thena's sub-status feature.

Thena Conversations nested under Requests via GET /rest/v2/requests/{id}/conversations map to Zendesk Ticket Comments. Each message thread entry becomes a Zendesk Comment with the original timestamp preserved. We set the Comment public/private flag by matching Thena's internal/external thread designation. Message author resolves to Zendesk Agent (from Users mapping) or Requester (from Contact/Organization mapping). Rich text formatting (bold, italic, strikethrough, lists) migrates; underline and colored text are not supported in Thena's bidirectional sync and do not transfer.

Thena Account maps to Zendesk Organization. Account name maps to Organization name; Account domain maps to Organization domain (used for automatic ticket merging in Zendesk). Account custom fields map to Organization custom fields. Account-to-Contact relationships in Thena map to Zendesk Organization's secondary contacts, with the primary contact mapped as the Organization's primary contact. We pre-create the Organization in Zendesk before importing any Tickets so the OrganizationId lookup is satisfied at insert time.

Thena Users map to Zendesk Users with the role set to Agent or Admin based on Thena user role. GET /rest/v2/users extracts name, email, and role. Email becomes the unique identifier for matching; we resolve existing Zendesk users by email and create any new records. Active and inactive status maps directly. If the destination Zendesk instance uses a different email domain for agents, we flag the mismatch in the scoping report for the customer's admin to resolve before migration.

Thena custom fields are retrieved via GET /rest/v2/custom-fields with full schema including type, required flag, and dropdown options. We pre-create equivalent Zendesk ticket fields (dropdown, text, boolean, integer) in the destination Zendesk instance before migration. Dropdown options in Thena map to Zendesk custom field options in the same order. Boolean and integer types map directly. Custom field values on Requests migrate as typed field values in Zendesk tickets.

Thena sub-statuses are per-workspace and live under main statuses. We extract the full sub-status tree during scoping and map each to Zendesk's status configuration. For Zendesk, we configure a custom ticket field thena_substatus__c of type dropdown populated with the Thena sub-status values. This preserves the full sub-status label while avoiding Zendesk's standard status whitelist constraint. The customer's admin chooses whether to surface this field in ticket views or keep it as a reference field.

Thena Workflows built from Triggers, Conditions, and Actions (status change, assignee change, custom field change, Slack notification) are exported as a structured JSON summary. We do not migrate Workflows as code because Thena's workflow model and Zendesk's Trigger/Automation model are structurally different. The written inventory includes the original trigger name, trigger event, all conditions with operators, and all actions with their configured values, plus a Zendesk Trigger equivalent recommendation for each workflow. The customer's admin rebuilds triggers in Zendesk post-migration.

Thena Forms supporting create, batch update, get, and search via the v2 API are exported with their full field schema. Form submission data maps into Zendesk Ticket fields based on field type matching. We deliver a form mapping document listing each Thena form, its fields, and the recommended Zendesk Ticket Form equivalent. The customer's admin configures Zendesk Ticket Forms in the Admin Center using the mapping document as a guide.

Thena does not have a native Knowledge Base product; however, if the customer has exported Help Center articles via a third-party tool or manual export, we map them to Zendesk Guide. Categories map to Guide Categories; Sections map to Guide Sections; Articles map to Guide Articles with title, body, author, and position preserved. Zendesk Guide requires activation and is available from the Support Enterprise tier or any Suite plan. We flag Knowledge Base migration as a conditional scope item based on the customer's data audit.

If Thena custom objects are in use (Standard and Enterprise tiers), we migrate them to Zendesk's new Custom Objects using the v2 API. We pre-create the destination custom object schema (object key, title, title_pluralized) and all custom fields before data import. Custom objects link to Tickets, Users, and Organizations via lookup relationship fields. Note: Zendesk's new Custom Objects experience does not support one-to-one enforced relationships; we model these as lookup fields without uniqueness constraints and document the relationship model in the schema design phase.