Migrate from OneDesk to Zendesk

OneDesk Tickets map directly to Zendesk Tickets. Subject, description, status, priority, and assignee fields map 1:1. The OneDesk Item ID is preserved in a custom field onedesk_item_id__c for cross-reference during validation. Conversation messages migrate as Ticket Comments in chronological order. Internal/external flag on OneDesk messages maps to Zendesk public/private comment distinction.

OneDesk Tasks are internal work items sharing the Item schema with Tickets. We map internal Tasks to Zendesk Tickets with a custom field task_type__c set to 'internal' if the customer wants visibility in Zendesk. Alternatively, Tasks map to a custom Zendesk object (Task__c) with a lookup to the parent Project simulated via Tag. The customer chooses during scoping.

OneDesk Customer records (external contacts, non-billable) map to Zendesk End Users. Name, email, phone, company, and custom contact properties migrate directly. We query the complete active custom field schema during scoping because OneDesk custom fields are shared across all Item types, so Customer custom properties must be extracted separately from Ticket custom fields.

OneDesk Users (billable agents) map to Zendesk Agents. Name, email, role, and permission flags migrate. OneDesk role assignments map to Zendesk Agent permission groups (Light Agent, Agent, Admin) based on the customer's role matrix. User provisioning in Zendesk must be validated against the per-agent license count before migration begins.

OneDesk Projects are container objects grouping related Tickets and Tasks. Zendesk has no native project object. We simulate the project grouping by assigning a project_name__c custom field on Tickets and by creating Zendesk Tags matching the project name. If the customer has fewer than 20 projects, Tags are manageable; for larger project counts, a custom Project__c object with a Ticket__c lookup is recommended.

OneDesk custom fields are shared across all Item types and stored at the Item level. We extract the complete active custom field schema during scoping (field name, type, options for dropdowns) and map each to an equivalent Zendesk Ticket custom field. Multi-select dropdowns map to Zendesk tagger fields. Date fields map to Zendesk date fields with YYYY-MM-DD format preservation. Required field validation in Zendesk is temporarily relaxed during import to avoid rejection on optional OneDesk fields.

OneDesk KB Articles migrate to Zendesk Guide Articles. Article title, body content (with HTML preservation), publish status, and author migrate directly. OneDesk category assignments map to Zendesk Section or Category depending on the destination Guide hierarchy depth. Enterprise Guide supports 5-level section nesting; lower tiers support 2-level. We configure the Help Center structure in Zendesk before migration and map articles accordingly.

Conversation messages on OneDesk Tickets and Tasks migrate to Zendesk Ticket Comments. Author reference resolves to the migrated Agent or End User. Message body, timestamp, and internal/external flag preserve. Attachments on individual comments migrate as Zendesk Ticket Attachments linked to the comment record. Thread ordering is preserved by setting the comment creation date to the original OneDesk timestamp.

File attachments on OneDesk Items are downloaded from OneDesk storage, uploaded to Zendesk as Ticket Attachments, and linked to the corresponding Ticket. Original filenames and MIME types preserve. For large attachment sets (over 10 GB total), we chunk the upload queue to stay within Zendesk's attachment API rate limits and retry failed uploads with exponential backoff.

Time tracked against OneDesk Tickets and Tasks migrates to Zendesk time tracking if the destination is Zendesk Suite Enterprise or Enterprise Plus. Hours, agent, date, and description map to Zendesk's time entry fields. For lower Zendesk tiers without native time tracking, time entries migrate as a custom ticket field (time_spent__c) in HH:MM format for reference. We flag this distinction during scoping so the customer can decide whether to upgrade tiers or accept the field-level approximation.