Migrate from Thena to Zoho Desk

Thena Requests map to Zoho Desk Tickets. The Request Subject becomes Ticket Subject, Description maps to the first thread entry, and Source maps to Zoho Desk's channel field with value normalization (Slack Channel, Email, MS Teams, Discord to their Zoho Desk equivalents). Status maps from Thena's main status (Open, In progress, On hold, Closed) to Zoho Desk's status picklist. Assignee resolves via email match to Zoho Desk Agent records. Sentiment, urgency, and AI tag fields from Thena migrate to custom fields on the Zoho Desk Ticket; we flag null AI fields during validation because Thena's inference pipeline may not populate these on older historical tickets.

Thena Accounts map directly to Zoho Desk Accounts. The Account name, domain, phone, website, industry, and description fields map to their Zoho Desk equivalents. Account-to-contact relationships in Thena carry through via account_id and resolve to Zoho Desk Account lookups on the Contact record. Account is created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

Thena Users map to Zoho Desk Agents. We extract user email, name, role, and active/inactive status from GET /rest/v2/users. Agent resolution uses email as the dedupe key; any Thena User without a matching Zoho Desk Agent goes to a reconciliation queue for your admin to provision before the ticket import phase begins. Inactive Thena users map to inactive Zoho Desk agents to preserve assignment history.

Thena Conversations nested under Requests (GET /rest/v2/requests/{id}/conversations) map to Zoho Desk Threads and Comments. The first Thena message in a conversation becomes the Zoho Desk Ticket description; subsequent messages become Comment records on the Thread. Author attribution resolves by email match to Zoho Desk Agent records. Thread direction (incoming vs outgoing) is preserved in a custom field since Zoho Desk does not natively track thread direction on all comments; we flag direction mapping during scoping if the customer relies on it for reporting.

Thena custom fields from GET /rest/v2/custom-fields map to Zoho Desk custom fields on the Ticket and Contact modules. Field types are mapped by data type: Thena string and text fields map to Zoho Desk string fields, Thena boolean maps to checkbox, Thena dropdown maps to picklist. Zoho Desk custom fields are department-specific, so we identify which department(s) each custom field applies to in Thena and recreate them in the corresponding Zoho Desk department layout. We extract the full custom field schema before migration and map values for every record, ensuring dropdown options and boolean states transfer correctly.

Thena sub-statuses are workspace-scoped custom status values that live under main statuses. Zoho Desk does not have a native sub-status concept; sub-statuses must be implemented as status picklist values or as Blueprint stages. We extract the full sub-status tree during scoping (main status + sub-status pair), map each to a Zoho Desk status value using a flat naming convention (e.g., Open - Awaiting Customer), and deliver a configuration summary for your Zoho Desk admin to implement as status values in the relevant department's layout. Sub-statuses do not migrate as data because Zoho Desk's status model differs structurally from Thena's.

Thena Workflows built from Triggers, Conditions, and Actions (status change, assignee change, custom field change, Slack notification) do not migrate as code. We export the workflow configuration as a structured summary including trigger type, condition logic, action list, and any Slack channel routing. Zoho Desk's Blueprint and Macros builder handles similar automation use cases differently, so we deliver a written inventory with a recommended Zoho Desk equivalent for each workflow. Your admin rebuilds these in Zoho Desk post-migration.

Thena Forms support create, batch update, get, and search via the v2 API. Form definitions and field schemas are exported as a structured configuration summary. Zoho Desk uses a different form model tied to its Help Center and department routing; we document the Thena form schema and field mapping for your admin to rebuild in Zoho Desk's form builder or as a Zoho Creator custom form if the use case requires it. Form submission data maps into destination ticket records based on field mapping defined during scoping.

Thena AI-assisted Knowledge Base articles, categories, and Help Center content map to Zoho Desk's Knowledge Base module. Article title, body content, status (draft or published), author, and category assignments migrate to Zoho Desk Articles and Categories. Attachments embedded in articles migrate as file attachments on the Zoho Desk Article record. If Thena's Knowledge Base uses a specific folder hierarchy, we map it to Zoho Desk's category tree structure. We flag any Thena KB content that relies on Thena AI generation features not available in Zoho Desk.

Thena Products (if present in the workspace) map to Zoho Desk Products. Product name, SKU, description, and unit price migrate to Zoho Desk Product records. Products in Zoho Desk are used for tracking product-related tickets and linking to the Contracts module in higher Zoho Desk editions. We resolve the Product lookup on migrated Tickets during the import phase.

File attachments on Thena Requests and Conversations migrate to Zoho Desk Ticket Attachments. Attachments are downloaded from Thena's file storage, uploaded to Zoho Desk's file repository during migration, and linked to the corresponding Ticket or Comment record. We handle attachment filename preservation and validate that file size does not exceed Zoho Desk's attachment limits. Inline images embedded in ticket descriptions and comments migrate as separate file attachments.

Thena's AI-detected sentiment, urgency, and tag fields are included in the XLSX/JSON export but are populated by Thena's inference pipeline and may not be set on older historical tickets. We migrate available AI fields to custom fields on the Zoho Desk Ticket (e.g., ai_sentiment__c, ai_urgency__c) and flag records with null values in the migration validation report. This coverage gap is documented in the migration summary so your team knows which tickets lack AI enrichment after cutover.