Migrate from Mint Service Desk to Gorgias

Mint SD Tickets map to Gorgias Tickets 1:1 using Subject, Description, Type, Status, and Priority. Mint SD's Type taxonomy (Incident, Request, Problem) maps to Gorgias Ticket Type values, and Status (Open, In Progress, On Hold, Resolved, Closed) maps directly to Gorgias status values. Priority maps to a Gorgias ticket field we create during schema setup. Custom fields on Mint SD tickets follow the custom field mapping process: we extract source field definitions, create matching Gorgias ticket fields (Text, Number, Dropdown, or Yes/No), and flag any orphaned source fields with no destination equivalent.

Mint SD Company records map to Gorgias Customer records. The Company Name becomes Customer name, and any Company-level custom fields map to Customer-level fields in Gorgias. We preserve the Company-to-Ticket linkage by attaching the customer to every migrated ticket. If the Mint SD installation uses a separate Organization or Account object alongside Company, we merge them into a single Customer record in Gorgias and note the merge in the migration manifest.

Mint SD Queues bundle ticket routing, access permissions, and SLA rules. Gorgias has no Queue object. We map each Mint SD Queue to a Gorgias Team and create a Routing Rule that reproduces the queue's ticket assignment logic. The rule evaluates ticket properties (Type, Category, Priority) and assigns the ticket to the corresponding Team. Permission sets that were enforced at the Queue level are enforced via Gorgias Team membership post-migration. Any SLA linkage originally attached to the Mint SD Queue is documented separately (see SLA Rules mapping) because Gorgias does not have native SLA breach tracking.

Mint SD SLA rules attach to Queues or Ticket Types and define breach thresholds. Gorgias has no SLA object. We convert SLA breach logic to Gorgias Rule conditions (e.g., First Response Time, Next Reply Time) using Gorgias SLA Rule templates if the destination plan includes them, or document them as an operational playbook the customer's admin follows. The SLA-to-Queue linkage is preserved in the migration manifest so the admin can re-attach SLA expectations to the corresponding Gorgias Rule or team inbox.

Gorgias does not have an Asset management module. We handle Mint SD Asset records by attaching the most relevant asset identifiers (serial number, asset tag, product name) to the linked Customer record in Gorgias as custom fields, or by linking to an external asset reference URL if the customer maintains a separate asset management system. The disposition decision is made during scoping: either migrate asset data into Customer fields or treat Assets as out-of-scope and document the recommended external system replacement.

Mint SD agents map to Gorgias agents by email address. We extract agent profiles including Name, Email, Role, and Group membership, then provision them in Gorgias. Queue permission sets that were Mint SD-specific map to Gorgias Team membership. If an agent in Mint SD has no active destination counterpart, their tickets are reassigned to a default agent designated by the customer during scoping.

Every Mint SD tenant has a unique custom field set. We introspect the source custom field definitions before migration, map them to Gorgias ticket fields or customer fields by name and data type, and create any missing destination fields. Gorgias limits active ticket fields to 25. If the source exceeds this, we archive unused fields in Gorgias post-migration to make room, or we split fields between ticket and customer context. Any source custom field with no Gorgias equivalent is flagged in the scoping report with a disposition recommendation.

Mint SD stores attachment references as URLs or file paths on Tickets and Assets. These references break after migration because they point to Mint SD's storage. We re-upload attachments to Gorgias-hosted storage during migration and update all ticket attachment links to the new hosted location. For large attachment volumes, we chunk uploads and validate a representative sample post-import to confirm links resolve correctly. If attachments exceed Gorgias storage limits, we negotiate an alternative storage disposition during scoping.

Mint SD agents log time against Tickets as Time Entries. Gorgias does not have a native time-tracking object. We migrate time entry data as a Note attached to the parent ticket with a structured format (e.g., 'Time Entry: 2h 15m - Agent Name - Work performed') or as a custom field on the ticket if the customer prefers structured storage. The disposition is confirmed during scoping.

Mint SD Change Management records link to Tickets and carry custom approval chains. Gorgias does not have a Change Management module. We map Change records to Tickets in Gorgias with the change record content preserved in the ticket body, or we recommend the customer maintain change records in a separate system post-migration. Any approval chain data is documented as a written record for the customer's ITSM administrator to re-establish in a dedicated change management tool if required.

Mint SD's standard Type taxonomy (Incident, Request, Problem) and Status values (Open, In Progress, On Hold, Resolved, Closed) map 1:1 to Gorgias equivalents. Custom Type values, Status values, and Priority values migrate as enumerated Dropdown field values in Gorgias. Any custom enumerated value that does not have a matching Gorgias field is added during schema setup before migration.

Mint SD Categories and Services define ticket categorization. We map these to Gorgias Tags or a Category ticket field depending on the customer's preference. Tags are preferred if the categorization is used for reporting and filtering; a dedicated Category field is preferred if the categorization drives routing rules. The choice is made during scoping based on how the customer uses Mint SD Categories today.