Migrate from DeskDirector to Zendesk

Tickets migrate 1:1 to Zendesk Tickets with status, priority, subject, description, requester, assignee, and timestamps preserved. DeskDirector Board assignments map to Zendesk Group or View membership depending on routing logic; we infer this from the board-to-ticket relationships in the export. The six-month stale-ticket culling rule means tickets with no activity in the past six months are not surfaced by DeskDirector's API and must be flagged explicitly. We detect records beyond this window and ask the customer to manually patch the last-update timestamp in DeskDirector before export if historical preservation is required.

DeskDirector Contacts migrate to Zendesk End Users. Email, name, phone, and role migrate directly. The VIP flag, Approval flag, and Invoice access permission are DeskDirector-specific and have no native Zendesk equivalent; we map these to a custom field dd_permission_flags__c (multi-select picklist) and/or tags (dd_vip, dd_approval_required) so the customer can rebuild equivalent logic in Zendesk using macros or business rules post-migration.

DeskDirector Companies migrate to Zendesk Organizations with name, domain, address, and primary contact preserved. Domain SIDs used for Active Directory auto-login in DeskDirector do not apply to Zendesk and are excluded. Any Email Domains used for ticket routing in DeskDirector are preserved in a custom field for reference but do not automatically configure routing in Zendesk, which uses different routing logic based on requester email domain or organization assignment.

DeskDirector Boards have no direct Zendesk equivalent. We treat each Board as a routing context: the ticket's board assignment becomes a Group membership in Zendesk, and a corresponding View is created to surface tickets from that Board context. Board-level contact permission gates require re-implementation in Zendesk as Organization restrictions or Group membership-based access. Multi-company contacts with board-switching complexity in DeskDirector resolve to a single primary Organization in Zendesk unless the customer explicitly requests multi-org structure.

DeskDirector Agents migrate to Zendesk Agents with name, email, role, and profile data preserved. Agent-to-board assignments in DeskDirector map to Group membership in Zendesk. Chat presence settings do not carry over since Zendesk Chat (formerly Zopim) is a separate product with its own agent configuration. We resolve each Agent by email match against the Zendesk destination account before import.

DeskDirector SLA configurations tied to ticket boards (response time, resolution time, priority mappings) migrate as configuration records that the customer manually rebuilds in Zendesk Admin. We export the SLA metric definitions, business hours, and priority-to-SLA mappings as a structured JSON document and provide step-by-step field mapping instructions for Zendesk SLA Policy creation. Actual SLA breach timestamps are not retroactively calculated from imported tickets; new Zendesk tickets created post-migration start fresh SLA clocks.

Tags on tickets and Companies are a flat string-keyed label system in DeskDirector. Tags migrate 1:1 as string arrays on the corresponding Ticket or Organization record in Zendesk. No transformation is required; Zendesk's tagging model accepts the same string identifiers. Tags used for board routing or contact classification in DeskDirector are preserved as-is and should be reviewed in Zendesk to confirm they do not trigger unintended automation rules.

Knowledge Base articles and category hierarchies export as article content and section structures. We migrate title, body (HTML), status, author, and position. AI Assistant rule configurations attached to knowledge bases reference DeskDirector-specific endpoints and are not covered by the API; these are flagged as non-migratable. Article translations, user segments, and permission groups require manual setup in Zendesk Guide Admin post-import. We deliver a category mapping document that aligns DeskDirector KB sections to Zendesk Help Center sections and categories.

DeskDirector Dynamic Forms use conditional logic and custom field configurations stored as DeskDirector-specific JSON. We export the form configuration as a reference document. Zendesk Forms support conditional fields natively but require manual re-implementation. The field types, conditional rules, and pre-triage logic are documented in our output for the customer's Zendesk admin to rebuild using Zendesk Form Builder. Automated form routing rules that fire on form submission also require rebuild as Zendesk triggers or macros.

Ticket attachments are stored as URLs in DeskDirector. If attachments are hosted in DeskDirector's blob storage, the destination URL breaks after cutover because DeskDirector revokes access post-migration. We flag this risk during scoping and recommend the customer download required attachments from DeskDirector before the cutover window. Attachments from external blob storage (referenced by URL) migrate as long as the source URL remains accessible during the migration window. We test a sample of attachment URLs during the sandbox phase to confirm integrity.

Chat sessions in DeskDirector are ephemeral session records tied to the live Chat Session Manager with no documented export or API endpoint for historical chat transcripts. We flag chat history as non-migratable and recommend customers export any required conversation logs manually via DeskDirector's UI before the cutover window if regulatory or audit requirements demand preservation. Zendesk Chat (the separate real-time chat product) does not offer a bulk import pathway for external chat transcripts either, so chat history does not port to any destination.

Custom Tools are bespoke integrations defined per-tenant for DeskDirector's AI Assistant feature. They reference internal endpoints not covered by the public API and are tenant-specific. We flag their existence and the endpoint references in the migration inventory document. Zendesk AI features (Agent Copilot, Intelligent Triage, macro suggestions) are platform-native and configured from scratch. No Custom Tool data migrates; the customer's admin rebuilds equivalent integrations using Zendesk's AI APIs or Marketplace apps post-migration.