Migrate from Mint Service Desk to Zendesk

Mint SD Tickets map 1:1 to Zendesk Tickets. We map Subject, Description, Type (Incident, Request, Problem), Status, Priority, Assignee, and timestamps directly. Mint SD custom fields on tickets migrate to Zendesk's custom_fields array using the field ID from the source schema introspection. Any Mint SD ticket number is preserved in a custom field mintsd_ticket_number__c for cross-reference. If the source tenant uses a custom ticket number format, we document it for the customer's admin to configure as a Zendesk display ID if required.

Mint SD Companies map to Zendesk Organizations. We use the Company name as the Organization name and preserve all linked relationships to Tickets. Mint SD custom properties on Companies migrate to Zendesk Organization custom fields. If the source Mint SD tenant stores a contract type, SLA tier, or account manager on the Company, these become custom fields on the Zendesk Organization.

Mint SD Agents map to Zendesk Users by email address match. We preserve group membership and role information from Mint SD and map them to Zendesk Groups and Agent Roles. Active Mint SD agents become active Zendesk agents; inactive or archived agents become Zendesk end-users (requesters) unless the customer specifies a different handling. Queue permission sets from Mint SD require explicit mapping to Zendesk Group membership because the permission model differs structurally.

Mint SD Queues bundle ticket routing, access permissions, and SLA rules. Zendesk separates these concerns: Groups handle agent permission scoping, and Views handle routing and filtering. We map each Mint SD Queue to a Zendesk Group by the closest matching name, and we replicate the queue's routing filter logic as a Zendesk View. The SLA linkage that was bundled in the Mint SD Queue is separately mapped to a Zendesk SLA Policy (see SLA Rules mapping). Queue permission sets that restrict which agents can access which tickets map to Zendesk Group membership and are validated post-import.

Custom fields in Mint SD are defined per-installation with no standard baseline. We introspect the source tenant's custom field definitions (field name, data type, applicable entity) before migration begins. Each Mint SD custom field maps to a Zendesk custom field of the equivalent type: drop-down to single-select, multi-select to multi-select, checkbox to checkbox, numeric to integer, text to text. If a source custom field has no destination equivalent, we create it in Zendesk Admin Center before the import phase. Any Mint SD custom field that cannot be mapped (due to data type incompatibility) is flagged in the scoping report with the customer's preferred handling: drop, map to text, or create a Zendesk equivalent.

Mint SD SLA rules attach to Queues or individual Ticket Types. We map each SLA rule to a Zendesk SLA Policy by the closest matching name and breach target. In Zendesk, SLA Policies are applied via triggers or automatically based on Views; we configure the trigger or view association during migration so that SLA breach tracking resumes immediately on imported tickets. We document all SLA-to-Queue linkages in the migration manifest and flag any Queue name changes as a post-migration risk item that requires SLA re-attachment.

Mint SD Assets (hardware, software, configuration items) migrate to Zendesk Assets if the destination Zendesk Suite plan includes Asset Management. Assets carry custom fields, link to Companies (Organizations), and may link to Tickets. We migrate asset records with their linked relationships preserved. If the destination Zendesk plan does not include Asset Management, we flag this during scoping and offer a custom field-based asset record alternative that stores the same data without requiring the add-on.

Mint SD stores attachment references as URLs or file paths on Tickets and Assets. These references will not resolve in Zendesk after migration because the source storage URLs are inaccessible. We re-upload attachments to Zendesk's native storage during migration and update all attachment references to point to the new Zendesk-hosted location. For large attachment volumes (over 5,000 files), we chunk the re-upload into batches and validate a statistically significant sample post-import to confirm all links resolve correctly. If Mint SD attachments are stored on-premise in a file share, we work with the customer to establish secure read access for re-upload.

Mint SD Ticket Types (Incident, Request, Problem, Change) map to Zendesk's Ticket Type field. Incident and Request map directly. Problem maps to a custom Ticket Type value in Zendesk. Change Management Records (see separate mapping) carry their own approval chain and are migrated with their linked tickets. Custom Type values from Mint SD are treated as enumerated field mappings with the same custom field resolution process.

Mint SD agents can log time entries against Tickets for billing, SLA tracking, or internal accounting. Zendesk does not have a native time-entry object; time logs migrate as internal comments on the Ticket with the time value and agent attribution preserved in the comment body. If the customer requires time tracking in Zendesk for billing or reporting purposes, we document this as a post-migration configuration item requiring a Zendesk time-tracking app from the Marketplace.

Mint SD Change Management Records are part of its ITIL 4 alignment and carry custom approval chains, risk ratings, and linkages to related Tickets. Zendesk does not have a native change management object. We map Change Records to Zendesk Tickets with a custom field for change_type, approval_status, and risk_level, and link them to related Tickets via a custom ticket field. Approval chains are documented in the migration handoff as items requiring rebuild in Zendesk's native approval workflow or a third-party workflow app.