Migrate your Thena data

Requests are the primary ticket object with a documented export to XLSX or JSON covering Subject, Description, Source, Sentiment, Urgency, Status, assignee, reply count, and timestamps. We pull via the v2 REST API and preserve all standard fields 1:1.

Thena maintains an Accounts endpoint at GET /rest/v2/accounts. Standard field mapping applies. Account-to-contact relationships in the destination are mapped via the account_id reference carried through the migration.

Users are manageable via GET /rest/v2/users and GET /rest/v2/users/{id}. User email, name, and role are exported and mapped to owner or assignee fields in the destination platform. Active and inactive status is preserved.

Custom fields are a first-class API resource at GET /rest/v2/custom-fields. We retrieve the full schema before migration and map custom field values for every record, ensuring dropdowns, booleans, and text fields land with correct types in the destination.

Conversations are nested under Requests via GET /rest/v2/requests/{id}/conversations. The Request export includes Number of replies; we reconstruct the full message thread, preserving timestamps, internal notes, and public replies.

Sub-statuses are custom-configured per workspace and live under main statuses (Open, In progress, On hold, Closed). We extract the full sub-status tree during scoping and map each to an equivalent status in the destination, flagging any that have no natural equivalent.

Thena Workflows are built from Triggers, Conditions, and Actions (status change, assignee change, custom field change, Slack notification). We export the workflow configuration as a structured summary but do not replicate automation logic into the destination, which requires re-implementation.

Forms support create, batch update, get, and search via the v2 API. Form definitions and field schemas are migrated; form submission data is mapped into destination ticket or contact records based on field mapping rules established during scoping.