Migrate from Mint Service Desk to Zoho Desk

Mint SD Tickets migrate to Zoho Desk Tickets 1:1. Subject, Description, Type, Status, Priority, Assignee, and timestamps transfer directly. Mint SD custom fields on tickets require pre-introspection of the source schema and pre-creation of matching custom fields in Zoho Desk before import; we flag any source custom field with no Zoho Desk equivalent during scoping and either create the field or ask the customer how to handle orphaned data. Attachment references on tickets are re-uploaded or re-linked during migration to ensure they resolve in Zoho Desk's storage.

Mint SD Companies map directly to Zoho Desk Accounts. Account Name becomes the Account Name field, and the source domain maps to the Website field as a dedupe reference. If the customer uses the Mint SD Companies module, we validate that every ticket in the source has a linked Company and generate a mapping table so that migrated tickets in Zoho Desk are linked to the correct Account at import time rather than after the fact.

Mint SD Agents map to Zoho Desk Agents by email address match. We extract every distinct agent email from Tickets, Queues, and SLA assignments and reconcile against the destination Zoho Desk user list. Any agent without a matching Zoho Desk account is held in a provisioning queue for the customer's admin to create before record import resumes. Role and group membership from Mint SD does not migrate automatically; we document the original permission set in the migration manifest for manual recreation in Zoho Desk's Roles and Profiles section.

Mint SD Queues are the primary organizational unit that bundles routing, access permissions, and SLA rules. Zoho Desk uses Departments for organizational routing and assigns Agents to Departments with a specific Role. We map each source Queue to a destination Department by closest-matching name, create the Department in Zoho Desk if it does not exist, and assign the corresponding agents. Permission sets attached to source Queues are documented separately because Zoho Desk permissions are managed through Roles and Profiles rather than Queue-level bundles.

Mint SD SLA rules attach to Queues by name reference. Zoho Desk SLA Policies are independent objects that attach to Departments or ticket field criteria. We extract every source SLA definition including first response and resolution breach times, business hours, and the target Queue name, then recreate each as a Zoho Desk SLA Policy during the schema setup phase. If a destination Department is renamed after import, the SLA linkage does not break in Zoho Desk (because it attaches by policy rather than name), but we document the original linkage in the migration manifest as a reminder to validate SLA behavior post-migration.

Mint SD custom field schema is per-installation with no standard baseline across tenants. We introspect the source custom field definitions for Tickets, Companies, and Assets, extract field names and data types, then pre-create matching custom fields in Zoho Desk before any data import begins. Data type translation is required: Mint SD text fields map to Zoho Desk Single Line, Mint SD multi-select fields map to Multi-Select Picklist, and Mint SD date fields map to Zoho Desk Date fields. Any source custom field that cannot be matched by name or compatible type is flagged as an orphan and included in the scoping report for the customer's decision before migration starts.

Mint SD Assets linked to Tickets and Companies migrate to Zoho Desk Assets. The asset name, type, status, and linked Company record transfer directly. Custom properties on assets follow the same custom field mapping process as ticket custom fields. Asset-to-ticket linkages are preserved through the ticket import by resolving the asset reference at the time of ticket insert.

Mint SD Ticket Types (Incident, Request, Problem, and any custom types) map directly to Zoho Desk Ticket Types. We extract the distinct type values from the source Tickets table and validate that each type value exists in the destination Zoho Desk configuration before import. Custom type values require the same enumerated field mapping approach as Status and Priority values.

Mint SD Status values (Open, In Progress, On Hold, Resolved, Closed, and any custom statuses) map to Zoho Desk Ticket Status fields. We extract the distinct status values from the source and configure matching status options in Zoho Desk before migration. Custom status values are treated as enumerated field mappings, and the status ordering in Zoho Desk is set to match the source workflow sequence so agents see the same pipeline progression after cutover.

Mint SD Priority values (Low, Medium, High, Critical, and any custom priority levels) map directly to Zoho Desk Priority. We extract the distinct priority values from source Tickets and configure matching values in Zoho Desk. Priority-to-SLA policy linkages that exist in Mint SD are documented separately because Zoho Desk SLA Policies attach to Departments rather than Priority levels.

Mint SD Change Management records track change enablement as part of its ITIL 4 alignment. Zoho Desk does not have a native change management module; ITSM-oriented customers use Zoho Desk's Blueprint editor to model change-request workflows manually. We migrate Change Management record metadata (title, type, status, linked tickets) as read-only Ticket records in Zoho Desk and deliver a Blueprint template document describing how to rebuild the change approval chain in Zoho Desk's visual workflow builder.

Mint SD agents can log time against Tickets. We migrate time entries as Zoho Desk Task records linked to the parent Ticket, preserving the original time entry duration, date, and agent attribution. The Zoho Desk Standard plan and above support time tracking on tasks. If the destination plan is Free (limited to three agents), time entry migration is still executed but the customer's admin should validate that the destination plan includes time tracking before relying on the data post-migration.