Helpdesk migration
Field-level mapping, validation, and rollback between osTicket and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.
osTicket
Source
Zoho Desk
Destination
Compatibility
9 of 12
objects map 1:1 between osTicket and Zoho Desk.
Complexity
CModerate
Timeline
2-4 weeks
Overview
osTicket stores its entire data model in MySQL — including thread history, attachment references, and agent assignments — while Zoho Desk is a cloud-native, multi-department helpdesk that organizes tickets around Teams, Departments, and a configurable service level hierarchy. The migration is a database extraction problem first and a data modelling problem second. osTicket has no bulk export API; we connect directly to its MySQL schema using a read-only database user, read the documented ERD, and resolve osTicket's loosely-enforced Organization-to-User linkage before inserting into Zoho Desk. Thread history — stored as one merged rich-text blob per ticket — is split into discrete message entries at migration time with author, timestamp, and internal vs public flags preserved. We do not migrate osTicket's SLA configurations or Help Topics as native Zoho Desk equivalents; we map them to custom fields and Tags respectively and document the rebuild steps. Zoho Desk's own assisted import tool (Zwitch) cannot transfer inline images, CC users, Groups, or Knowledge Base article attachments, and it overwrites created_at timestamps with the migration date — we handle these gaps through API-led import.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a osTicket object lands in Zoho Desk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
osTicket
Ticket
Zoho Desk
Ticket
1:1osTicket Tickets migrate to Zoho Desk Tickets 1:1. Ticket number becomes Ticket # in Zoho Desk; subject maps to Subject; status (Open, Closed, etc.) maps to Status; priority maps to Priority; and created timestamp is preserved as the Zoho Desk createdAt value via API import. Custom Fields on osTicket tickets are mapped to Zoho Desk custom fields (customField cf_<name>) based on field type (text, boolean, date, picklist). SLA plan assignments from osTicket are stored as a custom field value in Zoho Desk since Zoho Desk's SLA is scoped to the Department, not the ticket directly.
osTicket
Thread (Conversation)
Zoho Desk
Ticket Comment
lossyosTicket stores the entire ticket conversation history — user replies, agent responses, and internal notes — as one merged Thread record per ticket, not as normalised message rows. We split this thread blob at migration time into discrete Comment records in Zoho Desk's Conversation tab. The splitting logic parses osTicket's rendered-thread HTML structure and is version-sensitive to osTicket release. We preserve author email, timestamp, and the internal vs public flag for each segment. Internal notes from osTicket become private Comments in Zoho Desk; public replies become public Comments. This transform is the most technically involved part of the migration and is validated during the test migration phase.
osTicket
User (End User / Customer)
Zoho Desk
Contact
1:1osTicket Users migrate to Zoho Desk Contacts. Name, email, phone, and mobile fields map directly. The challenge is that osTicket allows Users to exist without an Organisation — these orphaned records cannot be linked to a Zoho Desk Account during migration without a manual decision. We flag all orphaned Users during scoping and offer three paths: create synthetic Accounts for them, link them to a catch-all Account, or exclude them from the migration with a written inventory for manual review. Email address is the dedupe key for Contact import.
osTicket
Organisation
Zoho Desk
Account
1:1osTicket Organisations map to Zoho Desk Accounts. Organisation name becomes Account Name; phone, website, and address fields map directly. We create the Account in Zoho Desk before any Contact import so that the Account lookup relationship is satisfied at the moment of Contact insert. osTicket's loose Organisation-to-User linkage means we must resolve this relationship at migration time: Users with a linked Organisation get AccountId populated; Users without a linked Organisation follow the orphan resolution path agreed upon during scoping.
osTicket
Agent (Staff / Operator)
Zoho Desk
Agent
1:1osTicket Agents migrate to Zoho Desk Agents. We map email address as the dedupe key, first and last name fields, and the agent's primary department assignment. osTicket's per-department permission model (agents with granular permissions per department) must be translated to Zoho Desk's role-based access control scoped to Departments. We create the Zoho Desk Agents in the agent import phase and assign them to Departments matching the osTicket department structure before ticket import begins so that OwnerId references are satisfied.
osTicket
Department
Zoho Desk
Department
1:1osTicket Departments map to Zoho Desk Departments. Department name, email routing address, and SLA plan association migrate directly. osTicket allows one SLA plan per Department; Zoho Desk allows SLAs to be assigned at the Department level and optionally overridden at the ticket level. We configure Zoho Desk Departments before agent and ticket import so that ticket routing by department is preserved. If osTicket has departments that Zoho Desk does not need (e.g., archive-only departments), we document the exclusion.
osTicket
SLA Plan
Zoho Desk
Service Level (custom field)
lossyosTicket SLA Plans (response time, resolution time, and business-hour calendar) do not have a native equivalent in Zoho Desk at the Free or Standard tiers; SLA configuration is available from Professional tier onward. We map osTicket SLA plan names and time windows to a custom field in Zoho Desk (e.g., cf_sla_plan__c) for audit purposes, and we document which Zoho Desk SLA policies the customer's admin should create to match the original osTicket SLA behaviour. This is a configuration rebuild, not a data migration.
osTicket
Help Topic
Zoho Desk
Tag
lossyosTicket Help Topics are first-class ticket categories that drive routing and SLA assignment. Zoho Desk does not have a native Help Topic object — tickets are categorised by Department, Subcategory, and Tags. We map osTicket Help Topic names to Zoho Desk Tags at the ticket level and document the routing logic that Help Topics provided in osTicket so that the customer's admin can rebuild equivalent routing via Zoho Desk's Blueprint and workflow rules post-migration.
osTicket
Attachment
Zoho Desk
Ticket Attachment
1:1osTicket stores attachments separately from the ticket thread record and links them by attachment ID. We extract attachment records alongside the ticket thread, download files to a staging area preserving filename and MIME type, and re-attach them to the corresponding Zoho Desk ticket comment via the Zoho Desk API. Files are associated with the correct Comment record by matching the thread position they occupied in osTicket. Zoho Desk's 10GB file upload limit via Zwitch applies to native import; our API-led approach handles larger volumes in chunks with retry logic.
osTicket
Custom Field (ticket-level)
Zoho Desk
Custom Field
1:1osTicket custom fields on ticket forms (text, boolean, date, list, and URL field types) map to Zoho Desk custom fields on the Ticket object. We create the destination custom fields via Zoho Desk's Layouts and Fields module before migration, matching field type to Zoho Desk's equivalent (osTicket list fields map to Zoho Desk Picklist, boolean maps to Checkbox, date maps to Date/Time). Fields marked as required in osTicket that are also required in Zoho Desk must be temporarily made optional during migration to avoid blocking ticket creation on sparse data; we restore required enforcement post-migration.
osTicket
Custom Field (user-level)
Zoho Desk
Custom Field on Contact
1:1osTicket custom fields on user forms (e.g., client type, account tier, billing ID) migrate to Zoho Desk custom fields on the Contact object. We map field types analogously and create the destination fields before Contact import. Note that Zoho Desk's contact custom fields are scoped to the Contacts module and may have different visibility rules from osTicket's agent vs user visibility model; we document any visibility gaps for the admin to resolve post-migration.
osTicket
Team (osTicket)
Zoho Desk
Team (Zoho Desk)
1:1osTicket Teams (groups of agents assigned to tickets) map to Zoho Desk Teams. We preserve team name and membership during migration. Team assignment on tickets in osTicket is converted to Zoho Desk's ticket assignment model, where a ticket can be assigned to an individual Agent or a Team. If osTicket ticket assignments are to Teams rather than individual agents, we replicate this by assigning the Zoho Desk Team during ticket import.
| osTicket | Zoho Desk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Thread (Conversation) | Ticket Commentlossy | Fully supported | |
| User (End User / Customer) | Contact1:1 | Fully supported | |
| Organisation | Account1:1 | Fully supported | |
| Agent (Staff / Operator) | Agent1:1 | Fully supported | |
| Department | Department1:1 | Fully supported | |
| SLA Plan | Service Level (custom field)lossy | Fully supported | |
| Help Topic | Taglossy | Fully supported | |
| Attachment | Ticket Attachment1:1 | Fully supported | |
| Custom Field (ticket-level) | Custom Field1:1 | Fully supported | |
| Custom Field (user-level) | Custom Field on Contact1:1 | Fully supported | |
| Team (osTicket) | Team (Zoho Desk)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
osTicket gotchas
API supports ticket creation only
Ticket threads are a single rich-text blob
Custom fields require optional setting for API
IP-restricted API keys block automated migration tooling
Zoho Desk gotchas
Agent email identity determines comment ownership after migration
Blueprints and SLA policies do not export via API
File upload capped at 10GB per migration batch
Tier-gated export and migration capabilities
Inbound migration is two-phase with a hard Phase 2 cutoff
Pair-specific challenges
Migration approach
Scoping and MySQL access verification
We audit the source osTicket instance: MySQL version and host configuration, osTicket version (for thread-splitting parser selection), table and column inventory against the documented ERD, ticket volume, attachment file count and total size, custom field inventory on ticket and user forms, active department count, SLA plan list, Help Topic list, and agent and user record counts. We verify direct DB access is available or coordinate with the customer's sysadmin to provision a read-only MySQL user and whitelist the FlitStack AI migration egress IP. The scoping output is a written migration scope document with object counts, field mapping draft, and a thread-splitting validation plan against a 50-ticket sample.
Zoho Desk schema preparation
We set up the Zoho Desk destination structure before any data import. This includes creating Zoho Desk Departments matching the osTicket department hierarchy, provisioning Agents with role-based access control scoped to the correct Departments, creating custom fields on Tickets and Contacts for osTicket custom fields and SLA plan values, and setting up Teams to match osTicket Teams. We also configure any required Zoho Desk SLA policies if the Professional tier is in scope. Schema is validated in a Zoho Desk trial or sandbox org before production migration begins. If Zoho Desk is on the Free or Standard tier, we note the SLA limitation explicitly in the scoping document and proceed with the custom field approach.
Test migration and thread-splitting validation
We run a test migration of a representative sample (typically 200-500 records including tickets with complex thread histories, internal notes, and attachments) into a Zoho Desk trial or sandbox org. The customer reconciles record counts, spot-checks 25-50 random tickets for thread-splitting accuracy (correct number of Comments, correct author attribution, correct internal vs public flag), attachment linkage, and custom field values. We apply any parser corrections to the thread-splitting logic during this phase. This validation step prevents corrections from happening in production, where they are more disruptive.
Data cleanup and orphan resolution
We resolve data quality issues identified during scoping before production migration. Orphaned osTicket Users (records with no Organisation link) are reconciled against the strategy agreed upon during scoping: synthetic Account creation, catch-all Account assignment, or exclusion with a written inventory. We remove duplicate user records identified during the scoping audit, validate email address format on all User records, and flag any osTicket agents who have left the organisation and should be set to inactive in Zoho Desk rather than active.
Production migration in dependency order
We run production migration in record-dependency order. Accounts (from osTicket Organisations) are created first so that Account lookups are available for Contact import. Agents are created next so that OwnerId references on tickets are satisfied. Contacts are imported with AccountId resolved for linked users and the orphan strategy applied for unlinked users. Tickets are imported with Subject, Status, Priority, createdTime (via API), and custom field values mapped. Thread entries are split from the osTicket blob and inserted as discrete Comment records with author, timestamp, and public/internal flag. Attachments are extracted from osTicket's upload directory and inserted into Zoho Desk comments via API. A row-count reconciliation report is generated after each phase before the next begins.
Delta migration, validation, and handoff
We freeze osTicket writes during cutover, run a final delta migration of any tickets, users, and agents created or modified during the migration window, then enable Zoho Desk as the system of record. We deliver a written inventory of SLA plan names and Help Topics with recommended rebuild steps in Zoho Desk's Blueprint and workflow rules. We provide a Knowledge Base article mapping document noting that KB attachments require a separate rebuild in Zoho Desk's KB module. We support a one-week post-migration window where we resolve reconciliation issues raised by the customer's support team.
Platform deep dives
osTicket
Source
Strengths
Weaknesses
Zoho Desk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 4 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across osTicket and Zoho Desk.
Object compatibility
4 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
osTicket: Not publicly documented.
Data volume sensitivity
osTicket doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during osTicket to Zoho Desk migration scoping. Not seeing yours? Book a call.
Walk through your osTicket to Zoho Desk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave osTicket
Other ways to arrive at Zoho Desk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.