Migrate from Plumsail HelpDesk to Freshdesk

Plumsail Ticket records are SharePoint list items with standard properties (Status, Priority, Assignee, Created date, Requester). We map these 1:1 to Freshdesk Ticket records using the Freshdesk Tickets API v2. The SharePoint item ID becomes a custom field plumsail_ticket_id__c for audit. Priority values (Low, Normal, High, Urgent) map to Freshdesk priority integers (1-4). SharePoint list pagination (100 items per page) requires multi-page extraction loops that we throttle against SharePoint's per-tenant throttling budget to avoid blocking live agents.

Plumsail Contacts live in a dedicated SharePoint contacts list linked to tickets by email. We map contact records to Freshdesk Contact with name, email, phone, and organization linkage preserved. The contact email address is the dedupe key during Freshdesk import. Custom Contact fields defined in SharePoint columns migrate to Freshdesk custom contact fields, which must be pre-created in the Freshdesk admin panel before migration begins.

Plumsail Organizations (companies) are a distinct SharePoint list linked to both Contacts and Tickets. We map them to Freshdesk Company records. The Organization name becomes the Company name; any domain field in SharePoint becomes the Freshdesk Company domain. Company records are imported before Contact records so that the Contact-to-Company lookup is satisfied at the moment of Contact insert.

Plumsail Agents are SharePoint users assigned the HelpDesk Agent role. We map agent identities by email match to Freshdesk Agent accounts. The Plumsail role hierarchy (Admin, Agent) maps to Freshdesk Agent Groups and Role permissions. Any Plumsail Agent without a matching Freshdesk account goes to a reconciliation queue for the customer to provision before record import resumes. Agent groups in Freshdesk (Team, Senior, Manager) are configured during schema setup.

This is the highest-risk object in the migration pair. Plumsail stores all ticket messages as comments with no separate visibility concept at the API level. Freshdesk separates Replies (customer-visible conversation entries) from Notes (internal agent notes). We read the Plumsail comment is_private flag if configured, otherwise treat all comments as Replies. Private agent notes that should not be customer-visible require an explicit API call to create Freshdesk Notes (agent-only) rather than Replies. A visibility misclassification on a large comment history creates a data exposure risk that we validate during the sample migration phase.

Plumsail Tags are SharePoint taxonomy or choice-field keywords applied to tickets. We preserve tag strings exactly and reapply them to Freshdesk Tickets via the Freshdesk Tags API. Tag count and naming are preserved; duplicate tag strings are deduplicated during the tag index build phase before bulk apply.

Plumsail Categories are structured classification labels stored as a SharePoint choice or lookup field. We map category values 1:1 to a Freshdesk custom dropdown field on Ticket. Any category value not already present in the Freshdesk field definition is flagged during scoping for pre-creation before migration, or mapped to the closest available value.

Plumsail SLA rules define First Response and Resolution time targets by priority or ticket type. We map SLA configurations as rule definitions in a JSON inventory document. Freshdesk SLA Policies are re-created manually in the Freshdesk admin panel (Admin > SLA Policies) using the same time targets and ticket filters. SLA policy content migrates as a structured reference document, not as executable configuration.

Plumsail Knowledge Base articles are SharePoint pages or list items inside the HelpDesk site. We map article titles, content (HTML), and category associations. Formatting and embedded media (inline images, screenshots) require post-migration validation because image URLs pointing to the Plumsail SharePoint domain will break after subscription expiration. We flag these broken-link candidates for the customer's admin to update post-migration.

File attachments on Plumsail tickets are stored in SharePoint document libraries linked to ticket items. We extract attachment binary data, upload to Freshdesk's attachment endpoint, and link to the corresponding ticket. Large attachment volumes (over 1 GB total) require chunked extraction from SharePoint and paced upload to Freshdesk to avoid both source throttling and destination rate-limit errors.