Migrate from HelpDeskEddy to Zoho Desk

HelpDeskEddy Tickets map to Zoho Desk Tickets with status, priority, tags, and the ticket body preserved. We resolve the status values (open, in-progress, resolved) to Zoho's equivalent Status field and preserve the original ticket ID as a custom field ext_ticket_id__c for audit trail. Original ticket creation timestamps require embedding in the first ticket comment because Zoho Desk's native KB migration excludes created_at from tickets by default; we handle this with a pre-insert transform that appends the source creation date as a system comment.

HelpDeskEddy customer profiles (name, email, phone, metadata) migrate to Zoho Desk Contact records. We cross-reference against the requester field on each ticket to deduplicate contacts before insert. Contacts without a parent Account in HelpDeskEddy land as standalone Contacts in Zoho Desk; if the customer uses organizational hierarchies, we map to Account records first and link Contact to Account via AccountId.

HelpDeskEddy operators map to Zoho Desk Agent records. We match by email address during migration. If an Agent with the same email already exists in Zoho Desk, the system maps to the existing record per Zoho's Assisted Data Migration documentation. Agents must be provisioned in Zoho before ticket import so that the assignee lookup is satisfied. We flag any operator that does not have a corresponding Zoho user account in the reconciliation queue for the customer's admin to provision.

HelpDeskEddy Departments map to Zoho Desk Departments, which are the primary organizational unit in Zoho's data model. We preserve the department hierarchy and configure access rights at the department level in Zoho. This step must complete before ticket import because Zoho Desk's custom fields are department-scoped: we cannot create or populate custom fields on tickets until the department structure is in place. Departments are created before Agents, before custom fields, and before any ticket records.

HelpDeskEddy's per-ticket individual custom fields require a pre-migration discovery pass to enumerate every distinct field name and type across all tickets in scope. We deduplicate by field name, infer the canonical type (text, number, date, dropdown), and create matching Zoho Desk custom fields scoped to the relevant department. Two tickets in HelpDeskEddy that share a field name but had different types must be reconciled during scoping: Zoho Desk enforces a single field type per custom field, so conflicting types require the customer to choose a target type or drop one variant. Tickets with no value for a mapped custom field receive an empty field, which is expected behavior.

HelpDeskEddy ticket tags migrate to Zoho Desk Tags as-is. Tags land on the ticket record and are searchable within Zoho's tag-based views. Zoho Desk's tag limit and display behavior matches HelpDeskEddy's, so no transformation is required beyond a direct field copy.

HelpDeskEddy macros are dispatcher rules referencing internal ticket states, field IDs, and UI actions. They have no equivalent in Zoho Desk's rule engine, which uses Blueprint process maps, workflow rules (trigger-condition-action), and time-based rules instead. We do not migrate macro definitions. We deliver a written macro inventory as part of the migration handover: for each HelpDeskEddy macro, we document its trigger condition, actions, and the recommended Zoho Desk equivalent (Blueprint step, workflow rule, or SLA rule). The customer's admin rebuilds these post-migration.

HelpDeskEddy's time-spent tracking attached to tickets migrates as a Zoho Desk Time Entry sub-record linked to the ticket, or as a custom hours field on the ticket if the customer's Zoho plan does not include the Time Tracking module. We preserve hours, billable flag, and agent attribution. Whether time entries land as sub-records or custom fields depends on the customer's Zoho Desk plan tier during scoping.

CSAT ratings from HelpDeskEddy migrate to a Zoho Desk numeric rating field or a custom Satisfaction field on the ticket, depending on whether the customer's plan supports the native rating field type. Zoho Desk does not have a first-class CSAT object, so the rating lands as a custom field. We preserve the original rating value and timestamp for reporting continuity.

HelpDeskEddy KB articles migrate as independent records with their body content, category assignment, publication status (published/draft), and associated tags. We preserve the section hierarchy. Article attachment files do not migrate because Zoho Desk's KB import excludes attachments; we document which articles have attachments and provide a file manifest so the customer's admin can re-upload manually post-migration. Public-facing KB URLs change at the destination, so we flag all articles with inbound links for URL redirect planning.

Chat channel logs from HelpDeskEddy migrate as conversation entries (threads and comments) attached to the originating Zoho Desk ticket. We map chat timestamps, agent name, and message body. Rich media in chats (file attachments, inline images) may require separate handling: inline images embedded in chat HTML are preserved in the comment body if they reference publicly hosted URLs; file attachments in chat require the same manifest treatment as KB attachments. Thread direction (incoming vs outgoing) is inferred from the agent vs customer authorship in the log.

Yandex Datalens dashboards are reporting artifacts built on top of HelpDeskEddy ticket data with platform-specific metric definitions and chart configurations. We do not migrate analytics dashboards because Zoho Desk's reporting schema and metric definitions differ. We deliver a written data dictionary mapping each Yandex Datalens metric to its nearest Zoho Desk Analytics equivalent so the customer's admin can rebuild reports in Zoho's native reporting module post-migration.