Migrate from Mint Service Desk to Freshdesk

Instance introspection and scoping probe

We connect to the source Mint SD instance via its REST API and extract the full schema: ticket fields, company fields, asset fields, queue definitions, SLA rule configurations, agent and group memberships, custom field definitions, and attachment references. Simultaneously, we run a low-volume scoping probe (50-100 requests) to establish the tenant's safe API throughput baseline. This probe resolves the no-published-rate-limit constraint and feeds the batch sizing for the migration run. We deliver a written scoping report covering record counts per object, custom field inventory, queue-to-group candidates, and any per-installation schema anomalies.

Freshdesk pre-provisioning and custom field creation

We provision the Freshdesk destination account with the required structural objects before any record data moves. This includes creating Freshdesk Groups to match the mapped Mint SD Queues, provisioning Agent accounts and assigning them to Groups, creating SLA Policies with the same time parameters as the source SLA rules, and creating all custom fields via the Freshdesk Custom Fields API using the type-mapped definitions extracted from Mint SD. Freshdesk custom fields must exist before record import; we complete this step entirely before proceeding.

Agent and Group reconciliation

We extract every distinct Mint SD agent (by email) and group from Tickets, Companies, and Assets and match them against the Freshdesk destination. Agents without Freshdesk accounts go to a reconciliation queue for the customer to provision. Groups are mapped 1:1 by closest name match and validated against the source queue permission set. Any SLA rules attached to a source Queue are documented and linked to the corresponding destination Group. This step gates ticket import because ticket assignee and group fields require valid references.

Record migration in dependency order

We migrate records in strict dependency order: Organizations (from Mint SD Companies) first, because ticket records require a valid organization reference; Agents and Groups second (already provisioned but validated); Tickets third, with Queue assignments resolved to Freshdesk Groups and SLA policies attached; Assets fourth, with their linked relationships preserved; Attachments fifth, re-uploaded or reference-updated. Each phase emits a row-count reconciliation report before the next phase begins. Mint SD on-premise deployments may require additional file extraction steps for attachments stored on local paths.

Post-import validation and SLA linkage verification

We validate migrated data against the source record counts for every object, spot-check a statistical sample of tickets for field completeness, and verify that attachment links resolve correctly in Freshdesk. We specifically confirm that SLA policies are attached to the correct Groups and that no Group was renamed after provisioning (which would break SLA linkages). Any unmapped custom fields or orphaned values are documented in the remediation checklist. We deliver the migration manifest, reconciliation reports, and SLA linkage map to the customer's admin team.

Cutover and automation rebuild handoff

We freeze Mint SD writes during the cutover window, run a final delta migration of any records modified during the migration run, then mark Freshdesk as the system of record. We do not migrate Mint SD workflows, change enablement records, or ITSM-specific process chains; these are structurally different from Freshdesk automations and require rebuild. We deliver a written inventory of every active Mint SD automation with a recommended Freshdesk equivalent for the customer's admin team to implement post-migration. We do not provide post-migration admin support or workflow rebuild as standard scope.