Helpdesk migration
Field-level mapping, validation, and rollback between Odoo Help Desk and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
Odoo Help Desk
Source
Gorgias
Destination
Compatibility
8 of 12
objects map 1:1 between Odoo Help Desk and Gorgias.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Odoo Help Desk to Gorgias is a structural migration across two fundamentally different helpdesk architectures. Odoo Help Desk stores customer records as res.partner entries shared across the entire ERP, while Gorgias maintains its own customer store with typed custom fields per ecommerce context. We resolve the partner lookup at migration time to avoid duplicate customer records, batch message thread exports in 500-record chunks to stay within Odoo's database timeout threshold, and surface every Studio-created x_studio_ field for explicit customer confirmation before mapping. SLA policies, Helpdesk Teams, and pipeline stages from Odoo have no direct Gorgias equivalent; we deliver a written inventory of these objects for the customer's admin to rebuild post-migration using Gorgias Flows and Tags. Workflows, automations, and Odoo Studio ir.actions are not migrated as code.
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 Odoo Help Desk object lands in Gorgias, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Odoo Help Desk
Ticket (helpdesk.ticket)
Gorgias
Ticket
1:1Odoo Tickets map to Gorgias Tickets. We map subject, description, stage, priority, assignee (res.users), partner (res.partner customer), team, tags, and creation dates. The Odoo ticket id is preserved as an external_id field for reconciliation. Stage names migrate as Gorgias Tags or Status values depending on the customer's configuration preference. Priority (low, normal, high, urgent) maps to Gorgias priority levels.
Odoo Help Desk
Customer (res.partner)
Gorgias
Customer
1:1res.partner records linked to helpdesk.ticket map to Gorgias Customers. The primary lookup key is email address. We deduplicate by email before insert and preserve the full Odoo partner name, phone, email, and address fields. res.partner is a shared Odoo model; we scope the migration export to partners with at least one helpdesk.ticket reference to avoid pulling the entire Odoo partner database into Gorgias.
Odoo Help Desk
Conversation (mail.message)
Gorgias
Ticket Messages
1:1Ticket conversations in Odoo's mail.message model migrate as Gorgias ticket messages. Each message author is resolved via res.partner email match to the migrated Gorgias Customer or Agent. We batch message fetches per ticket in chunks of 50 to isolate the blast radius of an Odoo database timeout. Large threads exceeding 200 messages per ticket are flagged during scoping for manual customer confirmation of migration scope.
Odoo Help Desk
Team Member (res.users)
Gorgias
Agent
1:1Odoo res.users records referenced as ticket assignees map to Gorgias Agents. We resolve by email match. Any Odoo user without a matching Gorgias agent email goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Odoo users are included with their active status preserved so historical assignment records remain intact.
Odoo Help Desk
Tag (ir.model.data)
Gorgias
Tag
1:1Odoo helpdesk.ticket tags are string labels stored in a shared tag pool linked via many2many. Tag names migrate to Gorgias Tags attached to the corresponding tickets. Tags used for priority classification or team routing are identified during scoping and mapped to Gorgias Tag groups or Status values per customer preference.
Odoo Help Desk
Helpdesk Team (helpdesk.team)
Gorgias
Inbox / Tag routing
lossyOdoo Helpdesk Teams define pipeline settings, email aliases, and member assignments. Gorgias uses Inbox Views with filter rules rather than a team hierarchy. We map team email aliases to Gorgias channel integrations (email channel per alias) and team member assignments to Gorgias agent profiles. The Odoo team pipeline configuration is documented in a separate rebuild guide for Gorgias Flows.
Odoo Help Desk
SLA Policy (helpdesk.sla)
Gorgias
SLA (Gorgias higher tiers)
lossyOdoo SLA policies define response and resolution deadlines by ticket priority or team. Gorgias includes SLA management on higher tiers. We export SLA definitions as a written inventory with trigger conditions, deadline intervals, and escalation actions. The customer's admin rebuilds these in Gorgias SLA settings post-migration.
Odoo Help Desk
Rating (helpdesk.rating)
Gorgias
CSAT / Satisfaction data
lossyOdoo Help Desk ratings reference res.partner as the rater and res.users as the rated agent, with a rating value (1-5 stars) and optional comment. Gorgias captures satisfaction at ticket close via a CSAT widget. We export ratings as a custom field mapping on the ticket or as a linked satisfaction record, noting that the display format differs between platforms.
Odoo Help Desk
Pipeline Stage (helpdesk.stage)
Gorgias
Status / Tag
lossyOdoo stages are records in helpdesk.stage scoped to a team_id, with name, sequence order, is_close flag, and fold status. Gorgias uses ticket Status (new, open, pending, resolved, closed) with Tags for extended categorization. We map Odoo stage names to Gorgias Status values and preserve the full stage list as Tags for cases where the customer needs more granular categorization.
Odoo Help Desk
Attachment (ir.attachment)
Gorgias
Attachment
1:1Ticket attachments stored in ir.attachment linked by res_model and res_id are exported via /web/binary/base64 and mapped to Gorgias ticket attachments. Large binary blobs (over 25 MB per file) are flagged during scoping because Gorgias has attachment size limits per plan tier. We recommend using an external storage reference or a separate blob migration for large media files.
Odoo Help Desk
Custom Field (ir.model.fields, state=manual)
Gorgias
Custom Field
1:1Odoo Studio custom fields on helpdesk.ticket use the x_studio_ prefix in the technical field name. Fields created via ir.model.fields use x_. Both live in ir.model.fields with state='manual'. We detect all x_* fields during schema discovery, present their human-readable labels to the customer, and map each to a typed Gorgias custom field (string, number, date, boolean, or dropdown) before migration begins.
Odoo Help Desk
Users (res.users)
Gorgias
User
1:1Agent assignment on helpdesk.ticket references res.users. We export user login, name, active status, and email. Active status determines whether the agent is provisioned as active or inactive in Gorgias. The Odoo user timezone migrates to the Gorgias agent profile for SLA calculation accuracy.
| Odoo Help Desk | Gorgias | Compatibility | |
|---|---|---|---|
| Ticket (helpdesk.ticket) | Ticket1:1 | Fully supported | |
| Customer (res.partner) | Customer1:1 | Fully supported | |
| Conversation (mail.message) | Ticket Messages1:1 | Fully supported | |
| Team Member (res.users) | Agent1:1 | Fully supported | |
| Tag (ir.model.data) | Tag1:1 | Fully supported | |
| Helpdesk Team (helpdesk.team) | Inbox / Tag routinglossy | Fully supported | |
| SLA Policy (helpdesk.sla) | SLA (Gorgias higher tiers)lossy | Fully supported | |
| Rating (helpdesk.rating) | CSAT / Satisfaction datalossy | Fully supported | |
| Pipeline Stage (helpdesk.stage) | Status / Taglossy | Fully supported | |
| Attachment (ir.attachment) | Attachment1:1 | Fully supported | |
| Custom Field (ir.model.fields, state=manual) | Custom Field1:1 | Fully supported | |
| Users (res.users) | User1:1 | Mapping required |
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.
Odoo Help Desk gotchas
Help Desk module is Enterprise-only
External API requires Custom plan
Large exports hit database timeout
Studio custom fields use x_studio_ prefix
Odoo.sh database migration differs from standard API export
Gorgias gotchas
AI Agent adds outcome-based fees on top of billable ticket costs
Overage billing for tickets scales nonlinearly
API rate limits restrict bulk export throughput
Agent data visibility cannot be restricted by role for GDPR use cases
Knowledge Base translations require separate API calls per locale
Pair-specific challenges
Migration approach
Discovery and plan confirmation
We audit the source Odoo instance across plan tier (Standard or Custom for API access), helpdesk module version, helpdesk.team count, helpdesk.ticket volume, mail.message thread depth per ticket, ir.attachment blob sizes, and any active Studio custom fields on helpdesk.ticket. We verify API access by testing a read call on the helpdesk.ticket model. The discovery output is a written migration scope including record counts per object, a list of x_studio_ custom fields for customer confirmation, and the Odoo plan upgrade recommendation if API access is not available.
Schema discovery and custom field handoff
We enumerate all custom fields on helpdesk.ticket by querying ir.model.fields where model='helpdesk.ticket' and state='manual'. We separate x_studio_ fields (Studio-created) from x_ fields (ir.model.fields-created) and present each with its human-readable string label, field type, and current values from a sample of 50 tickets. The customer confirms which fields migrate and assigns each to a typed Gorgias custom field (string, number, date, boolean, dropdown). Schema is deployed into the Gorgias sandbox for validation before production migration.
res.partner deduplication and customer pre-import
We extract every distinct res.partner record referenced by helpdesk.ticket and deduplicate by email address. Records with duplicate emails are presented in a deduplication report showing name variants, partner IDs, and last activity dates. The customer manually resolves each collision by selecting the canonical record. We then import the canonical customer list into Gorgias, preserving the original Odoo partner IDs as an external_id field for reconciliation.
Sandbox migration and reconciliation
We run a full migration into a Gorgias sandbox using production-like data volume. The customer reconciles record counts (customers in, tickets in, agents in, message counts, attachment counts), spot-checks 25-50 random tickets against the Odoo source for field accuracy, and reviews the custom field display format. Any mapping corrections or customer deduplication revisions happen here. The customer signs off the sandbox results before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: Agents (validated against the pre-provisioned Gorgias agent list), Customers (with external_id from res.partner), Tags (created before tickets so they are available for linking), Tickets (with res.partner customer_id resolved, stage mapped to Status or Tag, and priority mapped), Message threads (batched per ticket with author resolved to Gorgias customer or agent), Attachments (fetched via /web/binary/base64 per ticket), Custom Fields (mapped per the confirmed schema). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta sync, and rebuild handoff
We freeze Odoo helpdesk writes during cutover, run a final delta migration of any tickets or messages modified during the migration window, then enable Gorgias as the system of record. We deliver the SLA policy and Helpdesk Team inventory document to the customer's admin team for rebuild using Gorgias Flows. We support a one-week hypercare window where we resolve reconciliation issues. We do not rebuild Odoo automations or workflows as Gorgias Flows inside migration scope; that is a separate engagement.
Platform deep dives
Odoo Help Desk
Source
Strengths
Weaknesses
Gorgias
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 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 Odoo Help Desk and Gorgias.
Object compatibility
3 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
Odoo Help Desk: Not publicly documented.
Data volume sensitivity
Odoo Help Desk 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 Odoo Help Desk to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your Odoo Help Desk to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Odoo Help Desk
Other ways to arrive at Gorgias
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.