Helpdesk migration
Field-level mapping, validation, and rollback between eDesk and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
eDesk
Source
Zoho Desk
Destination
Compatibility
10 of 12
objects map 1:1 between eDesk and Zoho Desk.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from eDesk to Zoho Desk is a data-model translation that requires careful attention to three structural differences: eDesk's channel-centric ticket organisation versus Zoho Desk's department-centric hierarchy, eDesk's per-agent billing model versus Zoho Desk's per-agent pricing that does not gate ticket volume, and the absence of native marketplace channel inbox equivalents in Zoho Desk that requires channel attribution to be stored as custom fields and tags. We export full ticket history including conversation threads, attachments, SLA metadata, and contact records from eDesk's API, transform the data to Zoho Desk's CSV import format or API-driven structure, and validate record counts before and after each import phase. eDesk Smart Rules and Message Rules do not migrate as automation code; we export their logic as machine-readable configuration metadata and deliver a written rebuild guide for the customer's Zoho Desk admin. The Zoho ecosystem's department-scoped custom fields mean we create department-specific field layouts before importing tickets so that custom properties are visible on the correct department forms.
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 eDesk 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.
eDesk
Ticket
Zoho Desk
Ticket
1:1eDesk Tickets map directly to Zoho Desk Tickets with full conversation thread history, attachments, status, priority, and SLA metadata preserved. The eDesk channel assignment (Amazon, eBay, Shopify, email, social) is stored as a custom ticket field rather than a native routing mechanism since Zoho Desk routes to departments. We preserve the original channel value in a custom field edesk_channel__c and optionally apply a Zoho Desk tag matching the channel name for filtering.
eDesk
Contact
Zoho Desk
Contact
1:1eDesk customer contact records including name, email, phone, and marketplace identity map to Zoho Desk Contacts. Custom contact fields migrate field-by-field with type mapping (eDesk string, decimal, integer, currency, checkbox map to Zoho Desk equivalent field types). Zoho Desk Contacts can be linked to an Account; we create Account records from eDesk contact organisations during the accounts phase before Contact import.
eDesk
Agent
Zoho Desk
Agent
1:1eDesk Agent accounts and role assignments map to Zoho Desk Agents by email match. We verify that the Zoho Desk destination has a provisioned user account for each eDesk agent before migration begins. Agents without a matching Zoho Desk user go to a reconciliation queue for the customer's admin to provision. eDesk's per-agent pricing context means we flag the agent count at scoping so the customer confirms the correct Zoho Desk plan covers the team.
eDesk
Channel
Zoho Desk
Department + Custom Field
lossyeDesk channels (Amazon, eBay, Walmart, Shopify, email, social, and 200+ more) have no direct Zoho Desk equivalent because Zoho Desk routes tickets to departments rather than channels. We create a Zoho Desk Department per eDesk channel grouping, create a custom picklist field edesk_channel__c on the Ticket module, and assign tickets to the corresponding department while preserving the channel tag. For teams with fewer than 10 distinct active channels, department creation is straightforward; for teams with 50+ channel variations, we group by channel type (marketplace, D2C, social) to keep department count manageable.
eDesk
Knowledge Base Article
Zoho Desk
Help Center Article
1:1eDesk Knowledge Base articles and their category assignments migrate to Zoho Desk Help Center articles. We preserve internal/external visibility flags (Zoho Desk supports public, internal, and login-required article visibility), article-to-category assignments, and article content including formatted text and embedded images. KB article attachments migrate as linked file attachments. Note: Zoho Desk Help Center articles are scoped to departments; we assign articles to the department corresponding to the original KB category's channel grouping.
eDesk
Smart Rules
Zoho Desk
Workflow (configuration documentation)
lossyeDesk Smart Rules (available on all plans) and Message Rules (Professional and Enterprise only) are eDesk-proprietary automation logic that has no direct equivalent in Zoho Desk. We export every Smart Rule and Message Rule as structured JSON metadata capturing the trigger condition, filter criteria, and actions. This export is delivered as a machine-readable configuration document that the customer's Zoho Desk admin uses to rebuild equivalent Workflows using Zoho Desk's Blueprint and Workflow modules. We do not migrate automation rules as functional code.
eDesk
AI Classification
Zoho Desk
Custom Picklist Field
1:1eDesk AI Classifications (the taxonomy used for auto-categorising tickets) are not a standalone exportable object — they are a classification schema applied at ticket-level. We capture the AI Classification value from each ticket as a custom picklist field edesk_ai_classification__c in Zoho Desk, preserving the classification history without attempting to recreate the AI taxonomy in Zoho Desk's native structure.
eDesk
Template
Zoho Desk
Macro
1:1eDesk canned response templates migrate to Zoho Desk Macros as text content. Template variables such as {{customer_name}} or {{order_number}} are preserved as plain text strings in the macro body. Variable mapping between eDesk and Zoho Desk token syntax is documented in the migration deliverable for the customer's admin to finalise post-migration since token conventions differ between platforms.
eDesk
Tag
Zoho Desk
Tag
1:1eDesk ticket tags migrate as Zoho Desk Tags. Tag taxonomies differ between platforms, so we preserve the raw tag values and flag any tags that may need consolidation or renaming during post-migration tag management. Zoho Desk tags are cross-departmental, so tickets tagged across multiple eDesk channels carry all applicable tags in Zoho Desk.
eDesk
SLA Policy
Zoho Desk
SLA Policy
1:1eDesk SLA configurations (first-response and resolution time thresholds) migrate as Zoho Desk SLA Policy metadata where the destination plan supports SLA definitions. Zoho Desk SLA enforcement is scoped to departments, so we assign the migrated SLA policy to the department corresponding to the eDesk channel context. SLA breach notifications, escalation rules, and holiday calendars require separate configuration in Zoho Desk post-migration.
eDesk
Reporting Snapshot
Zoho Desk
Report (read-only archive)
1:1Historical reporting data from eDesk's Automated Report Extracts API (Agents, Tickets, Channels, Chats, AI metrics) is exported as a snapshot at migration cutover. We deliver these as CSV files archived in the customer's system as a read-only reference. Zoho Desk reporting rebuild is outside migration scope; we provide the historical data in portable format for the customer to import into a BI tool or Zoho Analytics if needed.
eDesk
Order Context
Zoho Desk
Custom Field
1:1eDesk's live order context (Amazon order ID, eBay transaction ID, Shopify order number) attached to each marketplace ticket has no native Zoho Desk equivalent. We preserve the most recent order reference as a custom field edesk_order_id__c on the Ticket record, and the order platform as edesk_order_channel__c. Order detail history (product, quantity, value) is not transferred as a linked object; we document this as a gap for customers who rely on in-ticket order context during agent responses.
| eDesk | Zoho Desk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Agent | Agent1:1 | Fully supported | |
| Channel | Department + Custom Fieldlossy | Fully supported | |
| Knowledge Base Article | Help Center Article1:1 | Fully supported | |
| Smart Rules | Workflow (configuration documentation)lossy | Fully supported | |
| AI Classification | Custom Picklist Field1:1 | Fully supported | |
| Template | Macro1:1 | Fully supported | |
| Tag | Tag1:1 | Fully supported | |
| SLA Policy | SLA Policy1:1 | Fully supported | |
| Reporting Snapshot | Report (read-only archive)1:1 | Fully supported | |
| Order Context | Custom Field1: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.
eDesk gotchas
Per-agent pricing creates billing risk at migration cutover
Smart Rules and Message Rules are tier-gated and not portable
Store and marketplace count limits gate channel connectivity
AI resolution costs accrue per automated ticket handled
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 channel audit
We audit the source eDesk account across plan tier (Essential/Growth/Professional/Enterprise), connected channel count, active Smart Rules and Message Rules, AI Classification taxonomy, Knowledge Base article volume, agent count, and ticket history age and volume. We verify the destination Zoho Desk plan (Standard $14/agent/month, Professional $23/agent/month, or Enterprise $40/agent/month) covers the team size and confirm that Knowledge Base and SLA capabilities are available on the selected tier. The discovery output is a written migration scope with record counts per object, a list of Smart Rules requiring documentation, and a channel-to-department mapping plan.
Schema design and department structure
We design the Zoho Desk destination schema before any data moves. This includes creating departments corresponding to each eDesk channel grouping (marketplace, D2C, social, email), creating department-specific custom fields for channel attribution (edesk_channel__c, edesk_order_id__c), assigning standard ticket fields (status, priority, requester, assignee) to each department layout, and configuring SLA policies scoped per department. Smart Rules are documented as structured metadata capturing trigger, conditions, and actions. The schema is deployed into the customer's Zoho Desk account for validation before production migration begins.
Export and transform from eDesk
We export data from eDesk using the platform's API, extracting Tickets with full conversation threads and attachments, Contacts with custom field values, Agents by email, Knowledge Base articles with category assignments, and tags. We transform the data to Zoho Desk's expected format: Tickets become Zoho Desk Tickets with thread comments as Comments, contacts map to the Contacts module with Account linkage, agents match by email against Zoho Desk Users, and Knowledge Base articles map to Help Center articles. AI Classification values from eDesk are written to the edesk_ai_classification__c custom field on each ticket. Smart Rules are exported as JSON configuration metadata.
Sandbox migration and reconciliation
We run a full migration into the customer's Zoho Desk account using production-like data volume. The customer's support operations lead reconciles record counts (Tickets in, Contacts in, Agents in, KB articles in), spot-checks ticket thread fidelity and attachment presence against the eDesk source, and verifies the edesk_channel__c field populated correctly on a sample of 25-50 tickets per channel. Any mapping corrections (incorrect field types, missing required fields, department assignment errors) happen in this phase. Sign-off on the sandbox migration is required before production cutover.
Production migration in dependency order
We run production migration in dependency order: Agents (validated against Zoho Desk User provisioning), Accounts (from eDesk contact organisations), Contacts (with AccountId resolved), Knowledge Base articles (with department assignment), Tickets (with edesk_channel__c and department resolved, thread comments as Comments, attachments as ContentDocument records, SLA policy assigned per department), and Tags (applied to tickets after ticket import). Each phase emits a row-count reconciliation report. We use Zoho Desk's API with rate-limit handling and batch chunking rather than CSV import where attachment fidelity and thread direction are required.
Cutover, validation, and Smart Rules handoff
We freeze eDesk write access during cutover, run a final delta migration of any tickets created or modified during the migration window, then designate Zoho Desk as the system of record. We deliver the Smart Rules and Message Rules configuration metadata as a JSON document with field-by-field rebuild instructions for Zoho Desk Workflows and Blueprints. We provide a one-week hypercare window where we resolve any reconciliation issues raised by the support team. Post-cutover Zoho Desk administration — including Workflow rebuild, SLA escalation configuration, and channel integration setup — is outside standard migration scope and is handled as a separate engagement or by the customer's internal admin.
Platform deep dives
eDesk
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 eDesk 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
eDesk: Not publicly documented.
Data volume sensitivity
eDesk 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 eDesk to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your eDesk 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 eDesk
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.