Migrate from iService to Freshdesk

iService Tickets map to Freshdesk Tickets with status, priority, and source fields translated to Freshdesk equivalents (Open, Pending, Resolved, Closed for status; Low, Medium, High, Urgent for priority; Email, Portal, Chat, Phone for source). The iService ticket ID is preserved in a custom field src_ticket_id__c for reconciliation. Custom ticket fields from iService are mapped to Freshdesk custom fields on the Ticket object; field names and data types (string, number, dropdown, checkbox) are reconciled during the data audit phase before any import begins.

Each iService Ticket contains a threaded Conversation history. Messages map to Freshdesk Ticket Conversations with the original timestamp, author (agent or customer), and message body preserved. Public agent replies map to the Freshdesk inbound note structure; customer messages map as requester replies. Private internal notes from iService are flagged for explicit mapping to Freshdesk's internal note visibility because the two platforms handle internal versus public visibility differently.

iService Customer records (contact-level data: name, email, phone, custom properties) map to Freshdesk Contacts. Email serves as the dedupe key during import. Custom contact properties migrate to Freshdesk custom fields on Contact. Phone numbers, time zone, and language preference transfer where present in the source record. Any customer without an email address is flagged in the reconciliation report for manual review because Freshdesk requires an email for Contact creation.

iService Company records map to Freshdesk Organizations. The organization name and domain become the Freshdesk Organization name and domain fields. Company-level custom properties migrate to Freshdesk Organization custom fields. Contact-to-Organization links are resolved after both objects are imported so that the Freshdesk Contact lookup relationship is satisfied at insert time.

iService live chat transcripts are stored as conversation records tied to a customer, but the transcript format varies by whether the chat originated from the embedded portal widget or a third-party integrated channel. We flag chat sources during the data audit phase and map transcripts to Freshdesk Ticket Conversations. Where transcript structure is incomplete in the export (missing timestamps or attribution), we create Freshdesk note entries with the available content and flag the gap in the reconciliation report for the customer's admin to review.

iService KB Articles (content, categories, and attachments) export as HTML or markdown. We map articles to Freshdesk Solutions, and KB Categories map to Freshdesk Categories within Solutions. Article section headings map to Freshdesk article sections. Attachments within articles migrate as Freshdesk-compatible file blobs linked to the article. Internal links within article content are flagged for the customer's admin to update post-migration because domain references will change after cutover.

iService custom fields on tickets are tenant-configured and vary in name and data type. We treat each custom field as requiring explicit mapping during scoping. String, number, date, checkbox, and dropdown field types map to Freshdesk equivalent custom field types. Any iService custom field with a type that has no Freshdesk equivalent (such as a structured JSON field) is flagged and either stored as a string or held for manual resolution in the reconciliation report.

Tags on iService tickets migrate to Freshdesk Tags. Tag naming conventions are preserved verbatim. Tags on KB articles map to Freshdesk Tags linked to the corresponding Solutions article. Tag association to the parent ticket or article is reconstructed during import by referencing the migrated record IDs.

iService agent accounts (email, name, role, team assignment) map to Freshdesk Agents. We resolve agents by email match against the Freshdesk destination account's agent list. Any iService agent without a matching Freshdesk agent account is held in a reconciliation queue for the customer's admin to provision before record import begins. Role and team structures differ between platforms; we default to a standard agent role and assign to a Freshdesk Group mapped from the iService team.

File attachments on iService tickets and KB articles migrate as binary blobs referenced by the parent record. We preserve attachment filenames and link them to the correct ticket or article in Freshdesk using the Freshdesk attachment API. Attachment migration is batched separately from record migration because file size affects transfer time and Freshdesk has per-request attachment size limits that we account for during chunking.