Migrate from HelpDeskEddy to Zendesk

HelpDeskEddy Tickets map to Zendesk Tickets as the primary migration object. Status values (open, in-progress, resolved) map to Zendesk ticket_status equivalents (open, pending, solved). Priority values migrate directly. The ticket body, subject, requester, assignee, department, tags, and all standard metadata transfer. Custom fields on each ticket require an explicit field-type mapping pass because HelpDeskEddy allows different field schemas per ticket, and Zendesk enforces account-wide custom fields on a given ticket form. We deduplicate all observed custom field names across the migration scope, assign each a Zendesk field type (text, dropdown, date, integer, checkbox, or multiselect), create the Zendesk custom fields in the target account before import, and populate them on each ticket. Tickets with no value for a mapped field receive an empty field at the destination, which is expected behavior.

HelpDeskEddy customer profiles (name, email, phone, organization, and contact metadata) map to Zendesk End Users. We cross-reference by email against the HelpDeskEddy ticket requester field to avoid duplicate End User creation during import. If the customer's email domain maps to an existing Zendesk Organization, we attach the End User to that Organization record.

HelpDeskEddy operators referenced on tickets map to Zendesk User accounts. We resolve HelpDeskEddy operator email addresses against the Zendesk destination User table before ticket import. Any HelpDeskEddy operator without a matching Zendesk User goes to a reconciliation queue; the customer's Zendesk admin provisions missing User accounts (with active/inactive status matching the source) before record migration resumes. Department assignments on HelpDeskEddy operators map to Zendesk Group membership.

HelpDeskEddy Departments map to Zendesk Groups. We preserve the department hierarchy and apply it as Zendesk Group membership at the agent level. Groups must exist in Zendesk before agents are assigned to them, so we create Groups during the pre-migration schema setup phase. If HelpDeskEddy departments have associated access rights or SLA policies, we document these for the customer's Zendesk admin to configure as Group-level settings post-migration.

HelpDeskEddy's per-ticket individual custom fields (text, dropdown, date, number, checkbox) are flattened across the migration scope by field name, deduplicated, and mapped to the closest Zendesk custom field type. We create each Zendesk custom field with the corresponding field type and attach it to the appropriate Zendesk ticket form before migration begins. Fields that have no Zendesk equivalent (e.g., a HelpDeskEddy field type not supported by Zendesk's custom field schema) are flagged as unsupported and carried as a custom ticket comment annotation for the admin to address.

Tags migrate as-is. HelpDeskEddy tags land on the destination Zendesk ticket as Tags. Zendesk's tag model supports alphanumeric characters and hyphens; we sanitize any HelpDeskEddy tag values that contain characters Zendesk does not permit. Tag counts and tag taxonomy are preserved. Zendesk Tags are org-wide and can be used in Triggers and Views post-migration.

HelpDeskEddy time-tracking data attached to tickets migrates as a Zendesk custom field of type integer (representing total seconds or minutes logged) or as a structured comment annotation on the ticket, depending on whether the destination Zendesk account has a time-tracking app installed. We preserve the original time-entry duration, agent, and date. If the customer requires billable-hours tracking, we recommend a Zendesk Sunshine time-tracking integration post-migration.

HelpDeskEddy CSAT ratings migrate to Zendesk's native Satisfaction (CSAT) object. Zendesk CSAT stores a rating (offered, bad, good, or none) and an optional comment. We map HelpDeskEddy numeric or boolean CSAT values to Zendesk's rating enumeration. If HelpDeskEddy stores a rating score (e.g., 1-5 scale), we map it to the Zendesk CSAT comment field as a text note for agent review. The customer's Zendesk admin must enable the Satisfaction feature in Admin Center before migration.

HelpDeskEddy knowledge base articles migrate as Zendesk Help Center articles. We preserve article body HTML content, status (published/draft), associated tags, and category assignment. Zendesk Help Center sections are created to mirror HelpDeskEddy's category hierarchy. Published articles retain their published status; draft articles remain drafts. Public-facing KB URLs will differ at the destination because Zendesk Help Center uses a different URL structure (your-subdomain.zendesk.com/hc/). We document the URL mapping for the customer's SEO and bookmark update process.

HelpDeskEddy chat channel logs migrate as public or internal ticket comments attached to the originating Zendesk ticket. We map chat timestamps, agent name (resolved against the User mapping), and message body; rich media in chats (images, attachments) migrate as separate file attachments linked to the comment. Chat metadata (channel type, session ID) is preserved in a custom comment field for traceability. If a HelpDeskEddy ticket has no Zendesk ticket counterpart (e.g., chat-only records without an associated ticket), we create a standalone Zendesk ticket with the chat log as the initial comment.

HelpDeskEddy macros are dispatcher-engine automation rules that reference internal ticket field IDs, UI elements, and conditional states with no direct Zendesk equivalent. We do not migrate macro definitions. We extract and document every HelpDeskEddy macro: its name, trigger conditions, actions, and field references. This macro inventory is delivered as a written document at migration handoff, and the customer's Zendesk admin rebuilds each macro as a Zendesk Macro or Trigger in the Admin Center macro builder. Macros referencing HelpDeskEddy-specific fields are flagged with the recommended Zendesk custom field to create first.

HelpDeskEddy's Yandex Datalens analytics exports and any built-in report configurations are reporting artifacts built on top of ticket data. We do not migrate analytics dashboards because they reference HelpDeskEddy-specific metric definitions and a separate analytics platform. We deliver a written inventory of every HelpDeskEddy report, its dimensions, filters, and the underlying data it references, so the customer's Zendesk admin can recreate equivalent reports in Zendesk Explore. Standard ticket metrics (volume, response time, CSAT, agent workload) are available natively in Zendesk Explore without any migration work.