Migrate from Desk365 to Zendesk

Desk365 Tickets map directly to Zendesk Tickets. We preserve Status (Open, Pending, Resolved, Closed), Priority (Low, Medium, High, Urgent), Created/Updated timestamps, and internal notes. Assignee resolves by email match to the Zendesk User table. Requester maps to the Zendesk End User (Contact) record. Due dates do not exist in Desk365 and cannot be migrated; we flag this gap for the customer's admin to set manually post-migration if needed. Custom field values on Desk365 Tickets map to equivalent Zendesk ticket fields created during schema pre-configuration.

Desk365 Customer records map to Zendesk End Users. We preserve name, email, company association, and portal access status. Zendesk uses a flat contact model; Desk365's company association maps to Zendesk Organization. If the Desk365 Customer is associated with multiple companies, we assign the primary company as the Organization and log the secondary association as a tag for reconciliation. Suspended Desk365 Customers will become unsuspended in Zendesk upon import; the customer should review any intentionally suspended requesters before activating Zendesk as the system of record.

Desk365 Agent records (display name, email, department, role: Admin/Agent, active/inactive) map to Zendesk User accounts. We resolve agents by email match. Department membership in Desk365 maps to Zendesk Groups; each Agent is added to the corresponding Group during migration. Role labels (Admin/Agent) map to Zendesk light_agent, agent, or admin roles depending on the customer's Zendesk plan tier. Inactive Desk365 Agents import as inactive Zendesk Users so historical assignment is preserved without inflating seat counts.

Desk365 Departments with configurable access levels (global, department-only, agent-only) map to Zendesk Groups. Zendesk Groups do not enforce hierarchical access control in the same way; we apply Zendesk's sharing attributes and Views to approximate department-scoped visibility. Large multi-department hierarchies with nested access rules require post-migration configuration to fully replicate the Desk365 access model in Zendesk's permission framework.

Desk365 KB Articles (Draft/Published/Agent-only) map to Zendesk Guide Articles (Draft/Published). The Agent-only visibility flag in Desk365 has no Zendesk Guide equivalent; we export it as a custom property on the article and land all Agent-only articles as Draft in Zendesk, notifying the customer of the count requiring manual review before publishing. Published articles migrate as Published. Folder hierarchy in Desk365 maps to Zendesk Guide Sections and Categories. Only the default language migrates unless Zendesk Guide multilingual settings are configured pre-migration.

Desk365 SLA Policies with First Response and Resolution time targets per Priority level and Business Hours map to Zendesk SLA Policies with First Reply Time and Next SLA Time targets. Business Hours schedules migrate to Zendesk Business Hours configurations. We map policy names and time thresholds; however, Zendesk's SLA Policy attachment is at the View or Global level rather than per-ticket-department, so the customer reviews and reattaches policies to the appropriate Views post-migration to maintain the same escalation behavior.

Desk365 Automation Macros (trigger conditions and action sequences on ticket create/update) do not migrate as active automation code because Zendesk Triggers and Macros use a different event model, condition syntax, and action types. We export macro definitions as structured JSON and deliver a written inventory mapping each Desk365 Macro to its nearest Zendesk Trigger or Macro equivalent with recommended rebuild steps. The customer's admin rebuilds triggers and macros in Zendesk Admin based on this inventory. This is explicitly out-of-scope as a code migration.

Desk365 Conversation entries (public replies, internal notes, system-generated status changes) migrate to Zendesk Comments on the corresponding Ticket. Public vs. internal visibility is preserved: public Desk365 comments map to public Zendesk comments; internal notes map to private Zendesk comments. We maintain chronological ordering by timestamp. Inline images and attachments within conversations download from Desk365 blob storage and re-upload to Zendesk as ticket comments, or to cloud storage with a link preserved in the comment.

Desk365 flat string Tags on Tickets migrate to Zendesk Tags. Zendesk automatically creates tags when they appear in imported records. Note that Zendesk also auto-assigns tags to tickets based on custom field option values during import; we deduplicate any collision between migrated Desk365 tags and Zendesk-auto-generated tags. No hierarchical or color metadata transfers as most source platforms (including Desk365) do not expose this metadata through their APIs.

Desk365 custom fields (text, number, dropdown, date, boolean) map to Zendesk ticket custom fields of equivalent type. Dropdown fields in Desk365 with specific option values map to Zendesk dropdown fields with the same option list. We pre-create the Zendesk custom field schema before any ticket import to ensure field IDs are available for mapping. Any Desk365 custom field that has no Zendesk equivalent type is flagged during discovery and the customer decides whether to create a text field or drop the field.

File attachments on Desk365 Tickets (and inline in conversations) stored at Desk365 blob URLs are downloaded and re-uploaded to the Zendesk ticket. Attachments over Zendesk's 50 MB per-file limit are uploaded to the customer's connected cloud storage and linked via a URL comment in Zendesk. Inline images in rich-text comments migrate as embedded images if under the Zendesk size limit, or as linked references for larger files.

IT Asset Management records from Desk365 Premium ($32/agent/month) link hardware/software assets to Tickets. No standard Zendesk Suite tier includes a native IT asset object. We extract asset records and their linked ticket associations as structured data for the customer to review. If the customer uses Zendesk Service Cloud, assets map to the native Asset object; otherwise, we deliver a custom object schema for the customer to create in Zendesk and a mapping sheet linking assets to the migrated ticket records.