Helpdesk migration
Field-level mapping, validation, and rollback between OneDesk and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
OneDesk
Source
Gorgias
Destination
Compatibility
10 of 12
objects map 1:1 between OneDesk and Gorgias.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from OneDesk to Gorgias is a migration from a dual-mode project-helpdesk hybrid into a dedicated eCommerce helpdesk. OneDesk treats Tickets and Tasks as variants of the same Item schema; Gorgias is strictly ticket-centric with no internal work-item equivalent. We map the shared OneDesk custom field set into Gorgias custom fields scoped to Ticket and Customer separately, preserve conversation threads in chronological order, and export the knowledge base hierarchy for re-creation in Gorgias. OneDesk Projects, Tasks, Time Entries, and Invoices have no Gorgias analog and are flagged for the customer to evaluate as post-migration admin decisions. OneDesk workflow automations reference specific Item IDs that change after migration; we deliver a written automation inventory for the customer's admin to rebuild in Gorgias Rules and Macros. The Gorgias per-ticket pricing model means teams with high ticket volumes should validate their monthly ticket count against the Starter ($50/month for 300 tickets) and growth tier costs before committing.
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 OneDesk 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.
OneDesk
Ticket
Gorgias
Ticket
1:1OneDesk Tickets migrate to Gorgias Tickets with subject, description, status, priority, and assignee preserved. OneDesk's customer (requester) reference maps to the Gorgias customer email lookup, which deduplicates by email address. The OneDesk Item ID is stored in a migration reference field on the Gorgias ticket for audit and automation reconstruction. We map OneDesk ticket status values (New, Open, Pending, Resolved, Closed) to Gorgias ticket status equivalents using the destination platform's status enum.
OneDesk
Conversation (on Ticket)
Gorgias
Ticket Message
1:1OneDesk conversation messages on Tickets export with author, timestamp, message body, and an internal/external flag. We preserve the full thread in chronological order by timestamp and map author references to migrated agent and customer records in Gorgias. Internal notes in OneDesk map to internal messages in Gorgias; public customer replies map to external messages. The chronological sequence is critical for audit continuity.
OneDesk
Customer
Gorgias
Customer
1:1OneDesk Customer records (external contacts, separate from billable Users) migrate to Gorgias Customers with name, email, company, and contact details preserved. OneDesk customers are non-billable and unlimited; Gorgias Customers similarly do not consume agent-seat licenses. Custom properties on Customer records require field-level mapping because OneDesk's shared custom field schema differs from Gorgias's Customer-scoped custom fields. We extract the Customer-specific custom field subset during scoping and map values to matching Gorgias Customer custom fields.
OneDesk
User (Agent)
Gorgias
Agent
1:1OneDesk Users (billable agent accounts) migrate to Gorgias agents with name, email, and role preserved. OneDesk distinguishes Users from Customers for billing purposes; in Gorgias, all agent accounts consume a seat license. We flag every OneDesk User during scoping so the customer can verify seat provisioning against the destination Gorgias plan before migration begins. Inactive OneDesk Users map to inactive Gorgias agents to preserve historical assignment on closed tickets.
OneDesk
Custom Fields (Ticket-scoped)
Gorgias
Custom Field (Ticket)
lossyOneDesk's custom fields are shared across all Item types and extracted at the Item level. We separate the Ticket-scoped subset and map it to Gorgias Custom Fields with object_type=Ticket. Supported field types (text, number, boolean, date, dropdown) migrate directly. Multi-select checkbox fields in OneDesk map to Gorgias multi-select custom fields. Any unsupported field type (conditional fields, formula fields) is flagged for manual evaluation during scoping.
OneDesk
Custom Fields (Customer-scoped)
Gorgias
Custom Field (Customer)
lossyOneDesk Customer records may have custom properties from the shared schema. We extract Customer-specific custom fields separately from Ticket-scoped fields during scoping, as Gorgias enforces object_type scoping on custom fields. Customer custom fields are pre-created in Gorgias with object_type=Customer before any Customer records are imported.
OneDesk
Knowledge Base Article
Gorgias
Knowledge Base Article
1:1OneDesk KB Articles export with title, body content (rich text), category assignments, and publish status. We map articles to Gorgias Help Center articles and preserve article-to-folder relationships. OneDesk's category hierarchy may be flatter than the customer's desired Gorgias structure, so we flag the category mapping during scoping for the customer to confirm the desired folder layout in Gorgias. Published status transfers; draft status is preserved for the customer's admin to finalize post-import.
OneDesk
Project
Gorgias
Tag + View (no direct equivalent)
1:1OneDesk Projects group related Tickets and Tasks into container objects. Gorgias has no project or workspace concept; tickets are flat and grouped by tags and saved Views. We export the Project hierarchy as part of the migration package and map each Project name to a Gorgias tag on the constituent tickets. This preserves the grouping relationship in a searchable, filterable form. If the customer relies heavily on Projects as a work-planning tool (not just ticket grouping), they should evaluate whether tags and Views in Gorgias meet their needs before migration.
OneDesk
Task
Gorgias
No direct equivalent (flagged)
1:1OneDesk Tasks are internal work Items that share the same schema as Tickets with a type discriminator. Gorgias has no internal task object separate from tickets. We do not migrate Tasks as a distinct record type. If the customer uses Tasks for internal work management (not customer-facing support), those records require a separate admin decision: either import as archived tickets, create as tasks in a project management tool, or discard. We document the count and schema of Task records during scoping so the customer can make an informed choice.
OneDesk
Attachment (on Ticket)
Gorgias
Attachment (on Ticket)
1:1File attachments on OneDesk Tickets export from OneDesk storage with original filenames preserved. We download files, upload them to the corresponding Gorgias ticket, and map them to the correct message in the conversation thread. Large attachment sets are chunked to stay within API rate limits. Files over the Gorgias maximum attachment size are flagged for the customer's admin to handle as external links or cloud storage references.
OneDesk
Time Entry (on Ticket)
Gorgias
No direct equivalent (flagged)
1:1OneDesk natively tracks time against Tickets and Tasks with hours, user, date, and optional description. Gorgias does not have a native time-tracking object attached to tickets. We export time entry data as a structured CSV during migration scoping and deliver it alongside the migration package. The customer can import this into a time-tracking integration (native to their eCommerce platform or a third-party tool) or evaluate Gorgias's timer macro feature as an agent-executed workaround. Time entries are not imported as native Gorgias records.
OneDesk
Workflow Automation
Gorgias
Rule / Macro (rebuild required)
1:1OneDesk workflow automations trigger on Item state changes, assignments, or SLA conditions and may reference specific Item or User IDs. After migration, these IDs change, breaking the automation logic. We export every automation definition with its trigger, conditions, actions, and referenced record IDs into a written inventory document. The customer's admin uses this document to rebuild equivalent Rules and Macros in Gorgias. Automations referencing migrated record IDs are explicitly flagged as requiring ID substitution during rebuild. We do not migrate automation logic as executable code because the automation models are structurally incompatible.
| OneDesk | Gorgias | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Conversation (on Ticket) | Ticket Message1:1 | Fully supported | |
| Customer | Customer1:1 | Fully supported | |
| User (Agent) | Agent1:1 | Fully supported | |
| Custom Fields (Ticket-scoped) | Custom Field (Ticket)lossy | Fully supported | |
| Custom Fields (Customer-scoped) | Custom Field (Customer)lossy | Fully supported | |
| Knowledge Base Article | Knowledge Base Article1:1 | Fully supported | |
| Project | Tag + View (no direct equivalent)1:1 | Fully supported | |
| Task | No direct equivalent (flagged)1:1 | Fully supported | |
| Attachment (on Ticket) | Attachment (on Ticket)1:1 | Fully supported | |
| Time Entry (on Ticket) | No direct equivalent (flagged)1:1 | Fully supported | |
| Workflow Automation | Rule / Macro (rebuild required)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.
OneDesk gotchas
User vs Customer billing model is migration-critical
Custom fields shared across all ticket types require schema discovery
Workflow automations reference migrated record IDs
Export via data view CSV may hit pagination limits on large datasets
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 scoping
We audit the source OneDesk tenant across active custom field definitions, ticket volume, customer count, agent (User) count, knowledge base article count and category structure, attachment volume, and time entry count. We extract workflow automation definitions and identify any that reference specific Item or User IDs. We run a record count across Tickets, Tasks, Customers, and KB Articles to size the export strategy and timeline. The discovery output is a written migration scope with object-level record counts, custom field schema inventory, and a flag for every object that has no Gorgias equivalent.
Schema design in Gorgias
We pre-create the destination schema in a Gorgias staging or sandbox environment. This includes provisioning Custom Fields with the correct object_type (Ticket or Customer) matched to the OneDesk custom field schema, confirming tag strategy for Project mapping, and setting up the knowledge base folder hierarchy. We validate that all field types (text, number, boolean, date, dropdown, multi-select) map to Gorgias-supported custom field types. Schema is validated before any production data moves.
User and Customer reconciliation
We extract every distinct OneDesk User (agent) and Customer (contact) referenced on Tickets and export them with full profiles. Agents are mapped by email to Gorgias agents. Customers are mapped by email to Gorgias customers with deduplication on email address. Any Customers without a valid email address are flagged for the customer's admin to resolve before migration. OneDesk Users are counted against the destination Gorgias seat count to confirm provisioning.
Production migration in dependency order
We run production migration in record-dependency order. Agents are migrated first (User accounts must exist before tickets can be assigned). Customers are migrated second (ticket requester references require a customer record to exist). Tickets are migrated third with the OneDesk Item ID preserved in a reference field and the customer lookup resolved. Conversation messages are migrated fourth in chronological order, linked to the parent ticket and author. Attachments are migrated fifth, linked to the correct message in the thread. Knowledge base articles are migrated last, with folder assignments confirmed against the customer's desired hierarchy.
Project hierarchy and tag mapping
We export the OneDesk Project hierarchy and map each Project to a corresponding tag in Gorgias. The tag is applied to all tickets belonging to that Project. This is delivered as a tag-assignment batch that runs after ticket migration completes. If the customer relies on Projects as a work-management tool rather than just a grouping mechanism, we surface this in the scoping document for a conscious decision before migration.
Cutover, validation, and automation handoff
We freeze OneDesk writes during cutover, run a final delta migration of any records modified during the migration window, and enable Gorgias as the system of record. We deliver the automation inventory document listing every OneDesk workflow with its trigger, conditions, actions, and referenced record IDs, with a note on which automations require ID substitution during rebuild. We support a one-week hypercare window for reconciliation issues. We do not rebuild automations as Gorgias Rules or Macros inside the migration scope.
Platform deep dives
OneDesk
Source
Strengths
Weaknesses
Gorgias
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 OneDesk and Gorgias.
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
OneDesk: Not publicly documented.
Data volume sensitivity
OneDesk 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 OneDesk to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your OneDesk 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 OneDesk
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.