Migrate from DeskDay to Gorgias

DeskDay conversational ticket threads map directly to Gorgias Tickets. Subject, body content, status (open/closed/pending), priority, and timestamp migrate 1:1. DeskDay's internal assignee (agent) maps to Gorgias assignee by email lookup. Tags on DeskDay tickets migrate as Gorgias tags. The DeskDay ticket ID is preserved as an external_id on the Gorgias ticket for audit traceability. DeskDay's chat-native message ordering is preserved as ticket comments in chronological sequence.

DeskDay end-user records (name, email, phone, company association) map to Gorgias Customer records. Email is used as the dedupe key. DeskDay's company association on an end-user maps to the Gorgias customer's primary company identifier. If DeskDay stores multiple contacts per MSP client, each end user becomes a separate Gorgias Customer rather than a hierarchical MSP-client-to-customer mapping, since Gorgias does not support the MSP multi-client organizational model natively.

Each DeskDay Client Organization representing an MSP customer maps to a Gorgias Customer record with the company name as the primary identifier. All end users associated with that Client Organization in DeskDay are linked to the corresponding Gorgias Customer. SLA tier or service level stored on the DeskDay organization record is preserved as a custom field (e.g., sla_tier__c) on the Gorgias Customer for reference. This merge is critical because Gorgias has no multi-client hierarchy—the MSP's view of multiple customers must flatten into individual Gorgias customer records.

DeskDay Agent records (name, email, role, team assignment) map to Gorgias Users. We match by email address. Any DeskDay Agent without a matching Gorgias User is placed in a reconciliation queue for the customer's admin to provision the account before ticket reassignment proceeds. Team routing assignments from DeskDay do not automatically map to Gorgias inbox routing; we document the DeskDay team-to-agent mapping so the customer's admin can configure Gorgias inbox rules post-migration.

DeskDay team structures map to Gorgias Inboxes (one per source team) or to Gorgias User Groups depending on the destination configuration. Each Gorgias inbox can have dedicated routing rules and channel associations (email, chat, social). We create the inbox structure in Gorgias during the pre-migration configuration phase and document which DeskDay team maps to which Gorgias inbox so the admin can assign agents and configure routing rules.

DeskDay Knowledge Base articles and their category assignments migrate to Gorgias Articles with the same title, body content, and category structure. Article view counts, feedback ratings, and internal publication status are not migrated as these are metrics generated by reader activity in the destination platform. Published vs draft status is preserved where the source field exists. The article hierarchy (parent-child categories) maps to Gorgias article sections.

Tags applied to DeskDay tickets migrate as flat Gorgias tag labels. Tags are applied to the corresponding ticket records post-import. DeskDay tag categories (if any hierarchical grouping exists) are flattened since Gorgias uses a flat tag model. All tag names are preserved verbatim for reporting continuity.

DeskDay custom ticket fields migrate as Gorgias custom fields on the Ticket object. We extract the DeskDay field definition (name, data type, required flag), create the corresponding Gorgias custom_field via the Gorgias API with the matching type (string, number, boolean, date), and map the values during ticket import. Fields that exist in DeskDay but have no natural Gorgias equivalent are created as text custom fields with the original value preserved as a string. Custom fields on DeskDay's End User object are evaluated for mapping to Gorgias Customer custom fields on the same 1:1 type-matching basis.

DeskDay SLA policies referencing business-hours definitions and escalation timers do not have a direct Gorgias equivalent, because Gorgias does not have a native SLA object. We convert DeskDay SLA policies into Gorgias Rules with condition-based actions (e.g., if priority is High and status is Open after 4 hours, then reassign and send notification). Business-hours definitions from DeskDay are documented as a configuration note for the customer's admin to set in Gorgias if applicable. This is a functional approximation, not a 1:1 migration, and the admin should validate the rule behavior post-migration.

DeskDay stores file attachments on tickets using internal cloud URLs that are not portable. We download all ticket attachments from DeskDay, re-upload them to Gorgias using the Gorgias API attachment endpoint, and update the ticket records with the new Gorgias attachment references. This process adds processing time proportional to total attachment volume and file size, and must be planned into the migration timeline. Inline images embedded in ticket comments are handled as attachments with the comment reference updated accordingly.

DeskDay IT-Connect portal associations (which tickets were submitted through the customer portal) migrate as metadata on the ticket record. The IT-Connect portal's theming, branding, and white-label settings are plan-gated (Standard vs Enterprise in DeskDay) and do not have a functional Gorgias equivalent because Gorgias Help Center uses its own theming system. Portal configuration does not migrate; we document the DeskDay portal settings so the admin can configure the Gorgias Help Center manually post-migration.

DeskDay reporting data is generated at query time from ticket and agent activity logs rather than stored as independent report records. There are no report definitions to migrate. We deliver a written inventory of the DeskDay reports the customer uses most frequently (ticket volume by status, agent response times, SLA compliance rates) as a reference for the customer's admin to recreate in Gorgias's built-in statistics dashboard or via a connected BI tool.