Migrate from iSupport Software to Freshdesk

iSupport Incidents map directly to Freshdesk Tickets. The source 10-digit alphanumeric ticket ID is stored in a custom field original_ticket_id__c since Freshdesk assigns its own numeric ID at creation. All standard ticket fields (status, priority, category, assignee, requester) map to Freshdesk's equivalent typed fields. If the iSupport Incident has a linked Company, we resolve the requester Contact's company association during import. Incidents with a status of Closed in iSupport map to Freshdesk's resolved Ticket status.

iSupport Customer records map to Freshdesk Contact. Standard contact fields (name, email, phone, language, time zone) migrate directly. Custom fields on the Customer record map to Freshdesk's contact custom fields, which must be pre-created in the destination admin panel before migration. Any picklist values used in custom fields are audited and separated from the field schema during the pre-migration data audit.

iSupport Company records map to Freshdesk Company. The company-to-customer linkage is preserved by resolving each Contact's primary company association during import, using the company_id foreign key present in iSupport's customer export. Freshdesk assigns the first company in the company column as the primary company for each contact, matching the iSupport data model behavior.

iSupport Knowledge Entries migrate to Freshdesk Solutions with category and folder hierarchy preserved. Both title and description (rich text) transfer directly. Attachments linked to knowledge articles are exported as files and re-linked in Freshdesk. If the source knowledge base uses a multi-level category structure, we map each level to Freshdesk's folder/subfolder model. Internal notes from iSupport articles do not migrate as they have no direct Freshdesk equivalent.

Freshdesk has no native CMDB or Configuration Item object, so we create a Custom Object named CI_Record with fields for serial_number, purchase_date, vendor, status, and asset_type. Asset-to-incident linkage requires the incident_asset_link junction table from iSupport, which we explicitly request during scoping. If that junction table is unavailable, we fall back to a text-based asset ID field stored on the incident record. We then create Custom Object Associations linking each CI_Record to the corresponding migrated Ticket via a lookup field.

iSupport post-resolution surveys attach to incidents and capture satisfaction data. The survey questions and answer schema require mapping to Freshdesk's built-in CSAT model, which uses a simple 1-5 or thumbs up/down rating per ticket. If iSupport survey responses contain custom rating scales or multi-question forms, we map the most recent overall satisfaction score to Freshdesk's satisfaction_rating field and flag additional questions for manual review or a Freshdesk app replacement.

iSupport custom fields on Incidents, Customers, and Companies map to Freshdesk custom fields on the corresponding objects. Picklist values require explicit separation from field definitions during the pre-migration audit because iSupport exports do not always cleanly separate schema from data. We create matching picklist options in Freshdesk before migration. Fields without a direct Freshdesk equivalent are stored in a JSON-formatted custom field for manual review post-migration.

Change Records exist only in the iSupport Service Desk Edition and have no direct Freshdesk equivalent. If the customer is also adopting Freshservice for ITSM alongside Freshdesk, we migrate Change Records to Freshservice Change Request. If Freshdesk is the sole destination, we create a Custom Object (Change_Request) with fields for change_type, risk_level, approval_status, and implementation_date. If no historical Change Records were ever created in the source system, we document this as a zero-record result in the migration scope.