Migrate from osTicket to Zendesk

osTicket Tickets map directly to Zendesk Tickets with subject, status, priority, and created/updated timestamps preserved. We pull tickets via direct MySQL read using the documented osTicket ERD to avoid the write-only API constraint. Each ticket's thread is split into discrete Zendesk Comments at migration time (see Gotchas). SLA Plan assignment from osTicket becomes a Zendesk SLA Policy linked to the ticket at import.

osTicket Users map to Zendesk End Users. Name, email, phone, and organisation linkage transfer. osTicket allows Users with no Organisation, which Zendesk also supports; we preserve that optional linkage as Zendesk's organisation_id field. Users are imported before Tickets so that the requester_id reference resolves at insert time.

osTicket Agents map to Zendesk Agents. We resolve agents by email against the Zendesk user provisioning list. osTicket's per-department permissions map to Zendesk's Agent Roles and Group assignments. The customer's Zendesk admin provisions agents in advance or during the scoping phase; we flag any osTicket Agent without a matching Zendesk User for manual provisioning before the production migration begins.

osTicket Organisations map directly to Zendesk Organisations. The organisation name becomes the Organisation name field, and any stored website or address fields transfer. osTicket allows Users to exist without an Organisation linkage; we preserve that state. Organisations are imported before Users so that the organisation_id lookup resolves at User insert time.

osTicket Custom Fields require pre-creation in the Zendesk admin panel before migration. We map osTicket field types to Zendesk equivalents: text to text, boolean to checkbox, date to date, list to dropdown or tag. Dropdown fields in osTicket map to Zendesk dropdown options, and the selected value transfers as the option label. We note any osTicket required-flagged Custom Fields and advise setting them to optional in Zendesk during migration to prevent silent import failures (see Gotchas). After migration completes, the customer restores the required flag if desired.

osTicket stores attachments separately from the ticket thread and links them by attachment ID. We extract attachment records alongside the ticket, re-link them to the corresponding Zendesk Ticket at import time using the Zendesk Attachments API, and preserve filename and MIME type metadata. Inline images embedded in ticket threads migrate as separate attachment records.

osTicket Departments control ticket routing and agent permissions. They map to Zendesk Groups, which serve the same routing and access-control function. Each Department name becomes a Group name. We configure Group membership during the agent import phase so that agents are assigned to the correct Groups at creation time.

osTicket SLA Plans define first-response and resolution deadlines tied to ticket priority. We create Zendesk SLA Policies matching the osTicket SLA plan names and time windows (in minutes). Each SLA Policy is linked to the corresponding Zendesk Group derived from the osTicket Department. Priority values (Low, Normal, High, Emergency) map to Zendesk Priority with the same labels.

osTicket Help Topics are ticket categories that drive routing and SLA assignment. They are a first-class object in osTicket but are modelled as Tags in Zendesk for standard ticket categorisation. We map each osTicket Help Topic name to a Zendesk Tag and apply it to the corresponding Tickets. If the customer uses Help Topics for SLA routing, we document the mapping so that Zendesk Triggers can recreate the routing logic post-migration.

osTicket stores the entire ticket conversation history — user replies, agent responses, and internal notes — as one merged Thread record per ticket. We split this into separate Zendesk Comment entries at migration time. The splitting logic parses the rendered-thread HTML structure and is version-sensitive to osTicket release. We preserve author identity (Agent vs End User), timestamp, and the internal versus public visibility flag for each segment so that internal notes remain internal in Zendesk. This is the highest-risk aspect of the migration (see Gotchas).