Migrate from Mint Service Desk to Intercom

Mint SD Tickets map to Intercom Conversations. The ticket Subject becomes the conversation title, Description becomes the initial message body, and Status (Open, In Progress, On Hold, Resolved, Closed) maps to Intercom's Open, Snoozed, or Closed state. Custom fields on the ticket migrate as Custom Attributes on the conversation. We preserve the original Mint SD ticket number as a custom attribute for audit trail and cross-reference during the transition window.

Mint SD Companies map to Intercom Contacts with the Company relationship preserved via Intercom's Company object. We map company name, domain, and custom properties to the Intercom Company workspace. The Mint SD Company-to-Ticket linking migrates as conversation-to-contact relationships in Intercom.

Mint SD Queues bundle ticket routing, agent permissions, and SLA rules. We map each Mint SD Queue to an Intercom Team, and create an Inbox under that Team for ticket routing. Queue-level permissions (who can see and respond to which tickets) require a written permission-matrix map for your Intercom admin to configure as Team-level access rules post-migration because Intercom's permission model differs structurally from Mint SD's queue-permission bundles.

Mint SD SLA rules attach to Queues or Ticket Types and define first-response and resolution targets. Intercom SLA policies attach to Inboxes and define first-response and next-reply targets. We migrate the SLA rule names, target durations, and Queue attachments as a written SLA inventory document. Your Intercom admin rebuilds these as Inbox-level SLA policies because the rule structures do not map directly. SLA breach tracking resumes in Intercom once the policies are configured.

Mint SD Agents map to Intercom Admins or Teammates by email address match. We preserve agent group memberships as Intercom Team assignments. Note: Intercom's API does not have a create-agent endpoint, so we require that agent profiles are provisioned in Intercom before migration begins. We provide a team-assignment manifest that your admin applies manually or via the Intercom UI before records are imported.

Mint SD Assets are first-class ITSM records linked to Tickets and Companies. Intercom has no native Asset object. We create a Custom Object named Asset in the destination workspace, migrate all asset records with their linked Ticket IDs and Company IDs preserved as external-reference attributes, and document the linking relationships for your team to maintain via a lookup table or external asset management tool. This is a structural gap that teams should evaluate during scoping: some customers choose to archive Assets rather than migrate them.

Mint SD custom fields are defined per-installation with no standard baseline. We introspect the source tenant's custom field definitions during scoping, map each by name and data type to an Intercom Custom Attribute (text, number, date, boolean, or list), and flag any custom fields with no Intercom equivalent. Orphaned custom fields (source fields with no destination) are listed in the scoping report with options: create the attribute, merge into an existing attribute, or archive.

Mint SD Ticket Types (Incident, Request, Problem, Change) are a structured taxonomy. Intercom has no native Type field on Conversations. We map Type values to a combination of Intercom Conversation Tags (for classification) and a custom conversation attribute ticket_type__c so that the original Mint SD type is searchable in Intercom. Your admin decides whether to use tags, the custom attribute, or both based on reporting needs.

Mint SD Priority values (Low, Medium, High, Critical) are standard enumerated fields. Intercom has a Priority flag on Conversations (Starter plan and above) that marks conversations for urgent follow-up. We map Critical and High to Priority = true and Medium and Low to Priority = false. If more granular priority classification is needed, we use a custom conversation attribute mint_priority__c.

Mint SD attachment references (URLs or file paths on Tickets and Assets) cannot resolve in Intercom after migration. We either re-upload attachments to Intercom's file hosting during migration or update attachment references to point to the re-hosted location. We validate a sample of attachment links post-import to confirm they resolve correctly. Large attachment volumes may extend the migration timeline; we flag this during scoping if attachment count exceeds 10,000.

Mint SD agents log time against Tickets for billing or capacity tracking. Intercom has no native time-tracking object. We migrate time entries as internal Notes attached to the Conversation, or as a custom conversation attribute time_spent_minutes__c, depending on the customer's reporting needs. Time-entry billing rules (if used for invoicing) do not migrate and require a separate billing system configuration.

Mint SD Change Management records link to Tickets and carry custom approval chains per ITIL 4 change enablement. Intercom has no Change Management object or approval workflow feature. We deliver a written inventory of all Change records with their linked ticket IDs, approval statuses, and dates as a CSV for your records. Approval chain rebuilds require external tooling (Zapier, Workato, or a custom integration) or manual process if Intercom's workflow builder is insufficient.