Migrate from DeskDay to Zendesk

DeskDay tickets map to Zendesk tickets with the subject, description, status, priority, and requester preserved. DeskDay's conversational thread model translates to Zendesk's comments structure: the initial ticket description becomes the first public comment, and subsequent thread messages become additional comments in chronological order. Custom ticket fields migrate as Zendesk custom fields with type mapping (text to text, dropdown to dropdown, checkbox to boolean). We set the migrated flag on imported tickets so Zendesk triggers and automations do not fire unexpectedly during the migration window.

DeskDay end-user contact records migrate to Zendesk end users with full name, email, phone, and any associated organization link preserved. We resolve the organization reference before inserting end users so that the requester-to-organization relationship is intact when tickets are imported. End users without an email address are flagged for admin review because Zendesk requires an email or external_id for user identification.

DeskDay client organizations representing each MSP customer map to Zendesk Organizations. The organization name, domain (if present), and any SLA tier or service-level mapping associated with the organization migrate as Organization fields. We create Organizations before End Users so that the organization lookup is satisfied at the time of End User import. MSPs with multiple sub-clients under one organization should confirm their grouping strategy during scoping because Zendesk Organizations are flat unless augmented with Tags or custom fields for sub-organization logic.

DeskDay agent records migrate to Zendesk agents with name, email, role, and team assignment preserved. Agent role mapping follows DeskDay's role definitions: admins map to Zendesk admins, technicians map to agents. Team assignments map to Zendesk Groups, which are used for ticket routing. We match agents by email address against the destination Zendesk account and flag any agents without a corresponding Zendesk user for admin provisioning before the production migration phase begins.

DeskDay teams used for ticket routing and assignment map to Zendesk Groups. We preserve team names and ensure that tickets referencing a DeskDay team are associated with the equivalent Zendesk Group after migration. Group membership is resolved by cross-referencing the agent mapping so that each agent lands in the correct group based on their DeskDay team assignment.

DeskDay custom ticket fields require field-level mapping because DeskDay's custom field schema is still evolving. We extract all custom field definitions from DeskDay during discovery, map each field type to the equivalent Zendesk custom field type (text, dropdown, checkbox, numeric, date), and pre-create the destination fields in Zendesk before ticket migration. Field IDs are used rather than display names to avoid conflicts when multiple fields share similar labels. Any custom fields on the 2026 roadmap that do not yet exist in DeskDay are flagged as missing source data.

IT-Connect portal articles and category structures map to Zendesk Guide sections and articles. Article content, publication status, and category assignments migrate, but portal theming and white-label settings are plan-dependent in DeskDay and do not have a direct Zendesk equivalent. We migrate the article body and section hierarchy; the Help Center branding is reconfigured post-migration as part of Zendesk Guide setup. Article view counts and feedback ratings may not transfer depending on whether DeskDay exposes these as API-available fields.

DeskDay knowledge base articles and their category assignments migrate to Zendesk Guide articles within the appropriate sections. We preserve article titles, body content, author information, and internal publication status. Article view counts and user feedback ratings migrate as metadata fields where available from the DeskDay API, but these should be verified post-import because the DeskDay KB schema may not expose all metadata as exportable fields. Zendesk Guide must be active on the target Zendesk plan before KB migration begins.

Tags applied to DeskDay tickets migrate as Zendesk tags. Tag names are preserved exactly as stored in DeskDay. In Zendesk, tags migrate as flat label arrays applied to the corresponding ticket records. Tags used for reporting or filtering in DeskDay will function equivalently in Zendesk's tag-based views and triggers after migration. Zendesk copies data from custom dropdown fields to tags automatically during import; we account for this behavior when designing the tag strategy to avoid duplicate tagging.

File attachments on DeskDay tickets require special handling because DeskDay stores them in its own cloud and references them by internal URLs. We download all ticket attachments, re-upload them to the Zendesk instance's file storage, and update ticket comment records with the new Zendesk attachment URLs. This adds processing time proportional to total attachment volume and must be planned into the migration timeline. Attachments exceeding Zendesk's size limits are flagged for the admin to handle manually or via alternative file storage integration.

DeskDay SLA configurations referencing business-hours definitions and escalation rules migrate as Zendesk SLA Policy records. SLA targets such as first response time and next update time map to Zendesk's SLA policy metrics. Business-hours definitions require translation because DeskDay and Zendesk define business hours differently. We extract the DeskDay SLA schedule configuration, map it to Zendesk's business-hours calendar, and recreate the SLA policy in the target Zendesk instance. SLA targets tied to custom date fields in DeskDay may require field remapping in the destination.