Helpdesk migration
Field-level mapping, validation, and rollback between Kustomer and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
Kustomer
Source
Zoho Desk
Destination
Compatibility
9 of 12
objects map 1:1 between Kustomer and Zoho Desk.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Kustomer to Zoho Desk is a structural translation, not a record copy. Kustomer's customer-centric timeline with per-conversation message threads has no direct equivalent in Zoho Desk's ticket-centric model—Conversations do not map field-for-field to Tickets; we preserve the full message history inside Zoho Desk's Thread records and decide during scoping whether the timeline ordering metadata carries through. Kustomer's KObjects (custom object schemas) require manual recreation in Zoho Desk as custom modules before any KObject records can import, and we validate each destination definition before data moves. The 30-day CSV export cap means teams relying on Kustomer as a knowledge base need an events-stream export arranged before migration day or a rolling 30-day export strategy. Routing Rules, SLA Policies, and Reports do not migrate; we deliver a written inventory for the customer's admin to rebuild. Zoho Desk's multi-department hierarchy and department-scoped SLAs replace Kustomer's team-based routing model, and the migration scope includes remapping team memberships to the appropriate Zoho Desk departments.
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 Kustomer 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.
Kustomer
Customer
Zoho Desk
Contact
1:1Kustomer Customer records map to Zoho Desk Contact. Email address is the primary dedupe and match key. Standard fields (name, email, phone) map directly; custom properties migrate to Zoho Desk custom fields on the Contact layout. The Zoho Desk Contact is created before any Conversation-to-Ticket migration so that the ContactId reference is satisfied at ticket creation time.
Kustomer
Company
Zoho Desk
Account
1:1Kustomer Company records map to Zoho Desk Account. The Account is created before Contact import so that the AccountId lookup can be resolved during Contact inserts. Company domain and address fields map to Account Website and address fields respectively. Accounts with no associated Contacts are preserved as standalone Account records.
Kustomer
Conversation
Zoho Desk
Ticket
1:1Kustomer Conversation maps to Zoho Desk Ticket as the primary ticket record. The conversation status (Done/Open) maps to Zoho Desk Ticket Status (Open, Pending, On Hold, Closed). Priority, channel type, and any SLA metadata migrate as standard Ticket fields. Conversation subject becomes Ticket Subject; full message history migrates into Ticket Threads and Ticket Comments. We preserve the original Kustomer conversation ID in a custom field kustomer_conversation_id__c for audit traceability.
Kustomer
Message (within Conversation)
Zoho Desk
Thread + Comment
1:1Kustomer Messages map to Zoho Desk Ticket Threads (the structured message sequence) with individual comments as Thread entries. Author attribution (agent vs customer) maps to the Thread author type. We preserve message timestamps to maintain chronological ordering. Attachments embedded in messages are extracted and re-uploaded to Zoho Desk as Ticket Attachments linked to the parent Thread. Kustomer's internal notes migrate as internal Ticket Comments with a visibility flag.
Kustomer
User (Agent)
Zoho Desk
Agent
1:1Kustomer Users (agents) map to Zoho Desk Agents by email match. We preserve the agent's display name, email, and role. Team memberships in Kustomer map to Zoho Desk Department membership during import. Any Kustomer User without a matching Zoho Desk Agent is held in a reconciliation queue for the customer's admin to provision before the ticket import phase begins.
Kustomer
Team
Zoho Desk
Department
lossyKustomer Teams (used for queue assignment and routing) map to Zoho Desk Departments. Each Kustomer Team becomes a Zoho Desk Department with its own agent roster, ticket queue view, and routing rules. Department-level SLA policies are set up in Zoho Desk as a post-import configuration step. We deliver a mapping table of Kustomer Teams to Zoho Desk Departments as part of the migration handoff.
Kustomer
Channel
Zoho Desk
Channel Type
1:1Kustomer Channel records (email, phone, chat, SMS, social) map to Zoho Desk Channel Types. Standard Kustomer channels (email, phone, chat) map directly. Non-standard or app-added channels are flagged during discovery and mapped to the closest Zoho Desk channel type, or mapped to a custom channel field if no standard equivalent exists.
Kustomer
KObject (Custom Object)
Zoho Desk
Custom Module
1:1Kustomer KObjects (custom schemas with user-defined fields, relationships, and validation rules) are recreated as Zoho Desk Custom Modules. We inspect the source KObject definition during discovery, document the field types and relationship graph, then create matching custom fields in Zoho Desk before importing any KObject records. Validation rules and cross-KObject relationships require manual re-implementation in Zoho Desk as they cannot be automatically translated. Custom module definitions are validated in a sandbox before production import.
Kustomer
Tag
Zoho Desk
Tag
1:1Kustomer Tags (applied across Customers and Conversations) migrate to Zoho Desk Tags. Zoho Desk's native tagging supports plain-text tags. Multi-value tag sets stored as arrays in Kustomer custom properties are flattened to comma-separated tags in Zoho Desk. The customer chooses whether tag scope applies per-record or globally during scoping.
Kustomer
Attachment
Zoho Desk
Attachment
1:1Files attached to Kustomer Messages and Notes are extracted from the export, re-uploaded to Zoho Desk via the API, and linked to the parent Ticket Thread record. Attachment metadata (filename, MIME type, size, upload timestamp) is preserved. Inline images within message bodies are handled as embedded attachments with relative URLs updated to point to the new Zoho Desk attachment URLs post-import.
Kustomer
Routing Rules
Zoho Desk
Blueprint (no migration)
lossyKustomer routing rules determine queue assignment and conversation routing. These are platform-specific configuration files that cannot be meaningfully translated to Zoho Desk's rule engine. We do not migrate routing rules as code. We deliver a written inventory of every active Kustomer routing rule with its trigger conditions, priority, and target queue, plus a recommended Zoho Desk Blueprint or workflow equivalent for the customer's admin to rebuild.
Kustomer
SLA Policy
Zoho Desk
SLA Policy (post-migration)
lossyKustomer SLA policies define first-response and resolution time commitments per conversation. Zoho Desk supports SLA policies scoped to departments and ticket categories. We document the source SLA definitions (threshold, priority mapping, business hours calendar) during discovery and deliver an SLA configuration guide for Zoho Desk rather than migrating the policies directly. The customer's admin applies the SLA policy to the appropriate Zoho Desk departments post-import.
| Kustomer | Zoho Desk | Compatibility | |
|---|---|---|---|
| Customer | Contact1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Conversation | Ticket1:1 | Fully supported | |
| Message (within Conversation) | Thread + Comment1:1 | Fully supported | |
| User (Agent) | Agent1:1 | Fully supported | |
| Team | Departmentlossy | Fully supported | |
| Channel | Channel Type1:1 | Fully supported | |
| KObject (Custom Object) | Custom Module1:1 | Fully supported | |
| Tag | Tag1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Routing Rules | Blueprint (no migration)lossy | Fully supported | |
| SLA Policy | SLA Policy (post-migration)lossy | 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.
Kustomer gotchas
Annual billing with 8-seat minimum inflates entry cost
30-day CSV export cap limits conversation history
API rate limits vary by pricing tier
Custom KObject schemas must be manually recreated in the destination
UTF-8 CSV encoding requirement can silently corrupt non-ASCII data
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 export arrangement
We audit the Kustomer portal across version tier (Enterprise or Ultimate), seat count, Customer volume, Conversation volume, active KObject definitions, channel types in use, team structure, and custom attributes. We confirm whether the events-stream export contract is in place for customers needing full historical conversation data, or agree on a rolling 30-day export strategy. The discovery output is a written migration scope document that identifies any KObject schemas, non-standard channels, and tag sets that require special handling.
Schema translation and KObject pre-creation
We translate the Kustomer schema to Zoho Desk: Customer to Contact, Company to Account, Conversation to Ticket, Message to Thread, Team to Department. Any KObject definitions found during discovery are pre-created as Zoho Desk custom modules with matching field types before data import begins. Zoho Desk's custom module definitions are validated in the destination portal before the first data record moves. We design the department structure to match the Kustomer team map and agree on the SLA policy translation approach with the customer's admin.
Export extraction and encoding validation
We extract data from Kustomer via CSV export (rolling tranches if events-stream is not available) or the events-stream API if contracted. Every extracted CSV is validated for UTF-8 encoding, row count against Kustomer's record counts, and field completeness. We flag any truncated conversation history due to the 30-day window and confirm with the customer whether a separate export run is needed to fill the gap. Attachments are extracted from the export package and staged with parent-record references for re-upload to Zoho Desk.
Sandbox test migration and reconciliation
We run a test migration into a Zoho Desk sandbox using a representative sample of the production data volume. The customer's Zoho Desk admin reviews imported Contacts against source Customers (spot-checking 25-50 records), verifies Ticket thread ordering, confirms KObject record linkage, and signs off the field mapping before production migration begins. Any schema corrections, field mapping adjustments, or department structure changes are made here. This step prevents post-go-live data quality issues.
Production migration in dependency order
We run production migration in Zoho Desk's required order: Agents first (by email match), then Accounts (from Kustomer Companies), Contacts (with AccountId resolved), then Tickets (with ContactId and AgentId resolved). Message history migrates as Ticket Threads and Comments with timestamps preserved for chronological ordering. KObject records migrate last, after all parent-object lookups are satisfied. Each phase emits a row-count reconciliation report before the next phase begins. We handle Zoho Desk's 30MB and 10,000-row file-size limits by chunking large datasets into multiple import batches.
Cutover, delta sync, and workflow handoff
We freeze Kustomer writes during cutover, run a final delta migration of any records created or modified during the migration window, then enable Zoho Desk as the system of record. We deliver the routing-rule inventory, SLA policy configuration guide, and KObject relationship diagram for the customer's admin to implement post-migration. We offer a one-week hypercare window to resolve any reconciliation issues reported by the support team. Routing rules, SLA policies, and reporting dashboards are not migrated as code and are excluded from standard scope.
Platform deep dives
Kustomer
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 Kustomer 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
Kustomer: Tier-based and not publicly documented; visible in response headers (x-ratelimit-limit, x-ratelimit-remaining) and Settings > Platform > Platform Usage.
Data volume sensitivity
Kustomer 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 Kustomer to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your Kustomer 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 Kustomer
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.