Helpdesk migration
Field-level mapping, validation, and rollback between Thulium and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
Thulium
Source
Zoho Desk
Destination
Compatibility
10 of 16
objects map 1:1 between Thulium and Zoho Desk.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from Thulium to Zoho Desk is a structural migration that requires flattening Thulium's embedded conversation threads into Zoho's Ticket Thread model, mapping nine distinct Thulium custom field types to Zoho's field equivalents, and resolving Agent-to-Case assignments against Zoho's department-centric agent hierarchy. Thulium stores individual email, chat, and voice interactions as sub-objects within a Case; we extract and flatten these into a linear chronological thread before loading into Zoho Desk. We preserve the original Thulium Case status, priority, and assignee fields and map them to Zoho Ticket status, priority, and agent assignment. Thulium's CRM Contacts and Companies migrate to Zoho Desk Contacts and Accounts with the relationship linkage intact. We do not migrate Thulium automations or custom workflows as code; we deliver a written inventory of these for the customer's admin to rebuild in Zoho Desk's rule engine post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Thulium object lands in Zoho Desk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Thulium
Case
Zoho Desk
Ticket
1:1Thulium Cases map directly to Zoho Desk Tickets. The Thulium Case ID becomes the Ticket number or a custom lookup field for traceability. We preserve Case Subject, Description, Status, Priority, Created timestamp, and Last Modified timestamp by mapping them to Zoho Ticket Subject, Description, Status, Priority, Created Time, and Modified Time respectively. Thulium's Case resolution time migrates to a custom field if the customer's Zoho Desk tier supports it.
Thulium
Conversation (embedded in Case)
Zoho Desk
Ticket Thread
1:manyThulium stores individual email, chat, and voice interactions as sub-objects within a Case. We extract each interaction as a separate Ticket Thread record in Zoho Desk. Each thread captures the channel type (Email, Chat, Phone), direction (Incoming/Outgoing), author name and email, body content with HTML formatting preserved, and timestamp. Thread ordering is preserved chronologically within the parent Ticket. This flattening step is required because Zoho Desk expects threads as child records rather than an embedded array.
Thulium
Contact
Zoho Desk
Contact
1:1Thulium CRM Contacts map to Zoho Desk Contacts. We map First Name, Last Name, Email, Phone, and any custom field values. The Contact email address serves as the dedupe key during import. Thulium Contact-to-Company linkage migrates to Zoho Contact-to-Account linkage by resolving the Thulium Company reference ID to the corresponding Zoho Account record before Contact insert.
Thulium
Company
Zoho Desk
Account
1:1Thulium Companies map to Zoho Desk Accounts. We preserve Company name, address fields (street, city, state, postal code, country), phone, website, and any custom field values. Zoho Desk Accounts must exist before Contact import so that the Contact-to-Account lookup relationship is satisfied at the moment of Contact insert.
Thulium
Contact-to-Company linkage
Zoho Desk
Contact-to-Account linkage
1:1Thulium's Contact-to-Company relationship (a reference ID on the Contact pointing to the Company) migrates to Zoho Desk's Contact-to-Account lookup. We resolve the Thulium Company ID for each Contact before importing and populate the Zoho Account ID field on the Contact record. If a Contact has no Company in Thulium, it is imported as a standalone Contact with no Account lookup.
Thulium
Custom Field (text, large text, email, numeric, link, date)
Zoho Desk
Custom Field (single-line, multi-line, email, number, URL, date)
lossyThulium custom fields with types text, large text, email, numeric, link, and date map directly to Zoho Desk equivalent field types. We create the corresponding Zoho custom field with the matching type before migration and populate values directly from the Thulium export. Email-type fields in Thulium preserve format validation in Zoho.
Thulium
Custom Field (list type)
Zoho Desk
Custom Field (picklist or multi-select picklist)
lossyThulium list-type custom fields map to Zoho Desk picklist fields. We extract the list values from Thulium, create the Zoho picklist with those exact values, and populate each record's field value against the Zoho picklist. If a Thulium list field is multi-select (checkbox-style), we map it to a Zoho multi-select picklist. Any Thulium list values not found in Zoho are flagged during scoping for the customer's admin to add or consolidate.
Thulium
Custom Field (yes/no type)
Zoho Desk
Custom Field (checkbox or multi-select picklist)
lossyThulium yes/no boolean fields map to Zoho Desk checkbox fields. We set the Zoho checkbox to true if Thulium value is yes, false if no. If Zoho Desk edition constraints prevent checkbox creation, we use a picklist with Yes and No values instead.
Thulium
Agent
Zoho Desk
Agent
1:1Thulium Agents map to Zoho Desk Agents. We extract Agent name, email, and role from Thulium and resolve by email match against the Zoho Desk agent table. If a Thulium Agent has no matching Zoho Desk Agent account, the record goes to a reconciliation queue for the customer's admin to provision the Zoho user before migration resumes. Role assignments (Admin, Agent) map to Zoho Desk role equivalents.
Thulium
Case assignee (Agent-to-Case linkage)
Zoho Desk
Ticket Agent assignment
1:1Thulium assigns Agents to Cases via a reference ID rather than a flattened user field. We resolve each Thulium Agent reference ID against our Agent mapping table and populate the Zoho Desk Ticket's Assignee field. If the destination Zoho Desk org uses Department-based ticket routing or shared queues, we configure the assignment logic during scoping to match the customer's workflow.
Thulium
Attachment
Zoho Desk
Attachment
1:1Files attached to Thulium Cases or Contacts are exported from Thulium's storage, downloaded with original filenames preserved, and uploaded to Zoho Desk as attachments on the corresponding Ticket or Contact record. We preserve the attachment-to-record linkage by uploading each file to the Zoho record that corresponds to the Thulium record it was attached to. Note that Zoho's native Zwitch migration tool does not migrate attachments; we handle this as a separate import phase using Zoho Desk's REST API.
Thulium
Tag
Zoho Desk
Tag or Label
1:1Thulium Tags on Cases migrate to Zoho Desk Tags or to a custom multi-select picklist depending on the customer's Zoho Desk edition. We build a value-mapping table during scoping to translate Thulium tag names to Zoho tag names, handling any naming differences or consolidations. If a Thulium tag has no Zoho equivalent, the customer chooses whether to create a new Zoho tag or map to an existing one.
Thulium
Case Status
Zoho Desk
Ticket Status
lossyThulium Case status values (e.g., Open, Pending, Resolved, Closed) map to Zoho Desk Ticket status values via a status-mapping table created during scoping. We preserve the original Thulium status name where Zoho supports an equivalent, or map to the closest Zoho default (Open, Pending, On Hold, Closed) with a note for the customer's admin to adjust if needed.
Thulium
Case Priority
Zoho Desk
Ticket Priority
lossyThulium Case priority values (e.g., Low, Medium, High, Urgent) map to Zoho Desk Ticket priority values via a priority-mapping table. Zoho Desk supports a configurable priority scale, typically Low, Medium, High, or Urgent, which we align to Thulium's existing priority tiers during schema setup.
Thulium
Case Created timestamp
Zoho Desk
Ticket Created Time
1:1Thulium Case creation timestamps migrate to Zoho Desk Ticket Created Time. We preserve the exact original timestamp to maintain audit history. If the customer's Zoho Desk tier limits backdating, we flag this during scoping.
Thulium
Case history timestamps
Zoho Desk
Ticket Thread timestamps
1:1Individual Thulium conversation thread timestamps migrate as Thread creation timestamps in Zoho Desk. We preserve the original date and time of each email, chat, or voice interaction to maintain the chronological conversation history within each Ticket. Thread author information (agent name or contact name) maps to Zoho Thread Author.
| Thulium | Zoho Desk | Compatibility | |
|---|---|---|---|
| Case | Ticket1:1 | Fully supported | |
| Conversation (embedded in Case) | Ticket Thread1:many | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Contact-to-Company linkage | Contact-to-Account linkage1:1 | Fully supported | |
| Custom Field (text, large text, email, numeric, link, date) | Custom Field (single-line, multi-line, email, number, URL, date)lossy | Fully supported | |
| Custom Field (list type) | Custom Field (picklist or multi-select picklist)lossy | Fully supported | |
| Custom Field (yes/no type) | Custom Field (checkbox or multi-select picklist)lossy | Fully supported | |
| Agent | Agent1:1 | Fully supported | |
| Case assignee (Agent-to-Case linkage) | Ticket Agent assignment1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Tag | Tag or Label1:1 | Fully supported | |
| Case Status | Ticket Statuslossy | Fully supported | |
| Case Priority | Ticket Prioritylossy | Fully supported | |
| Case Created timestamp | Ticket Created Time1:1 | Fully supported | |
| Case history timestamps | Ticket Thread timestamps1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Thulium gotchas
Custom field type mismatches require field-level mapping
Conversation history embedded in Cases requires flattening
Agent-to-Case linkage must be preserved explicitly
Zoho Desk gotchas
Agent email identity determines comment ownership after migration
Blueprints and SLA policies do not export via API
File upload capped at 10GB per migration batch
Tier-gated export and migration capabilities
Inbound migration is two-phase with a hard Phase 2 cutoff
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the Thulium portal for record counts across Cases, Contacts, Companies, Agents, Attachments, and Tags. We inventory all custom fields by type (text, large text, email, numeric, link, list, yes/no, date) and extract list values for each list-type field. We document the conversation thread volume per Case to estimate the thread-flattening workload. We confirm the Zoho Desk edition (Free, Standard, Professional, or Enterprise) and verify which custom field types are available at that tier. The discovery output is a written migration scope, a field-mapping table per object, and a Zoho schema checklist for the customer's admin to complete.
Zoho Desk schema setup and agent provisioning
We guide the customer's Zoho Desk admin through schema setup: creating custom fields matching Thulium's field types, configuring picklist values for list-type fields, setting up Ticket status and priority values aligned to Thulium's, and configuring Departments if department-based routing is required. We also produce an Agent mapping table listing every Thulium Agent and the corresponding Zoho Desk Agent email, with any unresolved agents flagged for admin provisioning. Migration cannot proceed past Case import until all Agent assignments can resolve to a valid Zoho Agent.
Data extraction and transformation
We extract data from Thulium in dependency order: Contacts and Companies first, then Cases with conversation threads flattened. For each Case, we decompose the embedded conversation sub-objects into individual Ticket Thread records with channel type, direction, author, body, and timestamp. Attachments are downloaded separately with their parent record ID logged for Zoho re-attach. Tags are extracted as a value-mapping table. Custom field values are extracted in their native types for direct mapping to Zoho field equivalents. The transformation phase produces a Zoho-ready import dataset organized by object with all lookups and references resolved.
Sample migration and reconciliation
We run a sample migration using a subset of Thulium data (typically 50-100 Cases with associated Contacts, Companies, threads, and attachments) into the customer's Zoho Desk sandbox or trial environment. The customer reconciles record counts, spot-checks field mappings for 25-50 random records against the Thulium source, and reviews the thread chronology in Zoho Tickets to confirm conversation history is preserved correctly. Any mapping corrections, missing picklist values, or status-mapping adjustments are documented and resolved before the full migration. We do not proceed to production migration until the customer signs off on the sample reconciliation.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Thulium Companies), Contacts (with Account lookup resolved), Agents (validated against the provisioning list), Tickets (with Assignee resolved and threads attached), Attachments (via Zoho REST API after ticket creation), and Tags (mapped via the value-mapping table). Each phase emits a row-count reconciliation report. We apply Zoho API rate-limit handling with exponential backoff and batch chunking to prevent throttling. During migration, the customer's Thulium instance remains live so that no new data is created in the migration window without a delta sync.
Cutover, delta sync, and automation handoff
We freeze writes to Thulium during cutover, run a final delta migration of any records created or modified during the migration window, then set Zoho Desk as the system of record. We deliver a written inventory of Thulium automations and custom workflows with a Zoho Desk rule-equivalent recommendation for each. We do not rebuild Thulium automations as Zoho rules as part of the migration scope; that is a separate engagement or an internal admin task. We support a one-week hypercare window to resolve reconciliation issues raised during the customer's first week in Zoho Desk.
Platform deep dives
Thulium
Source
Strengths
Weaknesses
Zoho Desk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 4 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Thulium and Zoho Desk.
Object compatibility
4 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Thulium: Not publicly documented.
Data volume sensitivity
Thulium doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Thulium to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your Thulium to Zoho Desk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Thulium
Other ways to arrive at Zoho Desk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.