Migrate from Odoo Help Desk to Zendesk

Odoo helpdesk.ticket maps to Zendesk Ticket as the primary migration object. We map subject to Ticket.subject, description to Ticket.comment.body, stage to Ticket.status, priority to Ticket.priority, assignee (user_id) to Ticket.assignee_id, partner_id to Ticket.requester_id (resolving res.partner email to a Zendesk User), team_id to Ticket.group_id, tags to Ticket.tags, and creation dates to Ticket.created_at. Odoo ticket closed dates map to Ticket.updated_at for closed tickets. Tickets are imported first so that child records (comments, attachments) can reference valid ticket IDs.

Odoo's res.partner is a shared model used across CRM, Sales, and Helpdesk. Tickets reference partner_id as the customer. We export partner records with their email, name, phone, and company_name. At migration time, partners with unique emails map to individual Zendesk User records. Partners with the same company_name are optionally merged into a Zendesk Organization, with the User added as a member. Customers who appear only as ticket requesters (no CRM activity) migrate as Users; those with company linkage migrate as Users plus Organization membership.

Odoo helpdesk.team records (team name, member assignments, alias email, and SLA policy reference) map to Zendesk Groups. We create a Zendesk Group for each Odoo team and populate it with the corresponding team members resolved as Zendesk agents. Team-level SLA policy references are exported as metadata and mapped separately to Zendesk SLA Policies during the SLA configuration step.

Odoo team membership links res.users to helpdesk.team via a many2many. We resolve each user record (login, name, active status) and map them to a Zendesk agent. Inactive Odoo users are mapped to a default Zendesk agent or held in a reconciliation queue so historical assignment records remain intact without orphaning tickets. Name collisions across Odoo and Zendesk are resolved by email match during the owner reconciliation step.

Odoo SLA policies define response and resolution deadlines tied to ticket priority or team. They are configuration records without a direct Zendesk equivalent object in the same data model. We export SLA policy definitions (name, policy type, target hours) and present them as an inventory document. If the Zendesk destination is Suite Professional or above, we configure Zendesk SLA Policies with matching conditions and policies manually in the Zendesk admin panel post-migration. We flag any SLA policies that cannot be replicated in Zendesk's SLA model during scoping.

Odoo helpdesk.stage records are scoped per team via team_id and define stage name, sequence, is_close, and fold status. We collect all distinct stage names across Odoo teams and map them to a unified Zendesk ticket status set (New, Open, Pending, Hold, Solved, Closed). The sequence order from Odoo becomes a reference document for the customer's admin to reorder Zendesk ticket statuses post-migration. For teams that require isolated stage sets, we document the team-to-stage mapping for the admin to implement via Zendesk ticket forms if needed.

Odoo tags are plain string labels stored in a shared ir.model.fields many2many pool and linked to tickets via helpdesk.ticket.tag_ids. We export all distinct tag names and link them back to migrated tickets as Zendesk tags. Tag cardinality is preserved. Tags that represent business-critical classifications are flagged during scoping so they can be mapped to Zendesk custom ticket fields instead of plain tags if the customer prefers.

Ticket conversation threads live in Odoo's mail.message model linked by res_model='helpdesk.ticket' and res_id=ticket_id. We batch-fetch messages per ticket in chunks of 500 to avoid the Odoo database timeout that affects large thread exports. Each message maps to a Zendesk Ticket Comment with author (partner_id mapped to Zendesk User), body (plain text or HTML), internal flag (message.subtype='comment' vs 'notification'), and created_at timestamp. Message ordering is preserved via created_at. We flag internal notes separately so they can be mapped to Zendesk's internal comment capability if the customer admin enables it.

Attachments on Odoo tickets are stored in ir.attachment linked by res_model='helpdesk.ticket' and res_id=ticket_id. We export file binaries via Odoo's /web/binary/base64 endpoint per attachment. Each attachment is uploaded to Zendesk via POST /api/v2/tickets/{id}/attachments and linked to the corresponding ticket comment. Large binary blobs (over 20 MB) are flagged during scoping because Zendesk enforces a 20 MB per-attachment limit and may require the customer's admin to provision cloud storage for overflow files.

Odoo custom fields on helpdesk.ticket are registered in ir.model.fields with state='manual'. Studio-created fields use the x_studio_ prefix; fields created via ir.model.fields use x_. Both are detected during schema discovery and presented to the customer with their human-readable labels. We create corresponding Zendesk custom ticket fields of matching types (text, dropdown, checkbox, date, integer) before ticket import begins. Fields without a Zendesk type equivalent are documented for manual field creation post-migration.

Odoo agent assignment on tickets (user_id) links to res.users. We export user login, name, and active status. Inactive users are included in the export so historical assignment records remain intact. We resolve Odoo users by email match against the Zendesk agent table during migration. Users without a matching Zendesk agent are held in a reconciliation queue for the customer's admin to provision before record import resumes.