Migrate from Plumsail HelpDesk to Gorgias

Plumsail Tickets are SharePoint list items with standard properties (subject, status, priority, assignee, created, dueDate). We map Ticket records 1:1 to Gorgias Tickets, preserving priority (High/Medium/Low mapping), status (Open/In Progress/Waiting/Closed to Gorgias Open/Pending/Solved), and the original Plumsail ticket ID in a custom field plumsail_ticket_id__c for audit. SharePoint $filter parameters map to Gorgias filter queries during scoped reads. Custom fields stored in the SharePoint customFields object migrate to Gorgias Ticket attributes.

Plumsail Contacts live in a dedicated SharePoint contacts list linked to tickets by email or ID. We map Contact records to Gorgias Customer (the requester), preserving name, email, phone, and organization linkage. Email address is the primary dedupe key; if a duplicate Customer already exists in Gorgias, we update rather than create. Plumsail's Contact custom fields migrate to Gorgias Customer attributes.

Organizations (companies) are a distinct SharePoint list object linked to Contacts and Tickets. We map Organization records to Gorgias Organization, preserving the company name, domain, and any custom columns configured in SharePoint. Organization must be created before Contact in migration sequence so the Gorgias customer.organization_id reference resolves at insert time.

Comments are ticket messages stored as rows in a related SharePoint list. We map each comment to a Gorgias Message on the corresponding Ticket, preserving author (mapped via email to Gorgias User or Customer), body content, and the public/private visibility flag. Private comments from Plumsail agents map to Gorgias internal notes. Historical comment ordering is preserved by timestamp. High comment volumes are staged across months to avoid silent Plumsail comment-cap overages during the migration window.

Tags are SharePoint taxonomy or choice-field keywords applied to tickets. We preserve tag strings exactly and reapply them to Gorgias Tickets as tag labels. Tag count and naming are preserved 1:1. Any tag values that do not exist in Gorgias are created during import. Tags used for internal classification in Plumsail map directly to Gorgias tag equivalents without transformation.

Categories are structured classification labels stored as a SharePoint choice or lookup field. We map category values 1:1 to Gorgias Ticket categories. Any Plumsail category values not present in Gorgias are flagged during pre-migration setup for the customer to create before the category migration phase begins, avoiding import errors on unrecognised values.

File attachments on tickets are stored in SharePoint document libraries linked to ticket items. We map attachment files by downloading from SharePoint using the file URL returned in the ticket.expand response, then uploading to Gorgias via the attachment API linked to the corresponding ticket. Large files are chunked to stay within Gorgias's 25MB per-attachment limit. Attachment count and original filenames are preserved; any missing files trigger a reconciliation alert during migration.

Agents are SharePoint users assigned the HelpDesk Agent role. We map agent identities and ticket assignments to Gorgias Users by email match. Role-based access control (admin, agent) in Plumsail translates to Gorgias super_admin and agent role equivalents. Owner references on Tickets resolve to the User mapping established during scoping. Agents without a matching Gorgias User are held in a reconciliation queue for the customer's admin to provision before record import resumes.

Knowledge base articles are SharePoint list items or pages managed inside the Plumsail HelpDesk site. We map article titles, category associations, and full body text as Gorgias knowledge base articles. Formatting, embedded media, and interactive elements may require reformatting at the destination. Complex HTML content is preserved as rich-text content; images are extracted and re-uploaded to Gorgias media. Knowledge base articles are migrated after tickets so that category associations resolve correctly.

Views are saved SharePoint list views with filters, groupings, and column ordering. We document view configurations as reference data during discovery. Views are SharePoint-specific and have no Gorgias direct equivalent; they must be rebuilt as saved filters or views in Gorgias by the customer's admin. The documentation we deliver includes each view's filter criteria, grouping, sort order, and visible columns for manual recreation.

SLA rules define response and resolution time targets by priority or ticket type in Plumsail. We extract SLA configurations as rule definitions (priority level, first-response target, resolution target) and document them for manual rebuild in Gorgias. Gorgias SLA configuration uses a rules-based model with different mechanics from Plumsail's SLA setup; the customer rebuilds SLA policies in Gorgias Settings using the exported definitions as a checklist.

Automations (called Triggers in Plumsail) run as Power Automate flows on the SharePoint site. They are configuration, not data, and are tied to Plumsail's internal trigger-action schema. We do not migrate them as executable artifacts. We inventory every active trigger during discovery with its name, firing conditions, and action logic, and deliver a written rulebook mapping each Power Automate flow to a Gorgias Rule equivalent or a new Power Automate flow pointing to Gorgias.

Reports are generated from SharePoint list data via built-in charting and are not exportable as reusable definitions. We advise exporting report data as a CSV or Excel file from Plumsail's Export to Excel ribbon function before the migration window closes. Report definitions are rebuilt manually in Gorgias using the exported data as a reference for the metrics and dimensions that matter to the support team.

The embedded support widget is configured in Plumsail. We document widget settings including branding, ticket form fields, and submission rules as configuration data. After migration to Gorgias, the customer replaces the Plumsail widget script with the Gorgias chat widget script. CSP enforcement changes in March 2026 are a migration trigger for teams using the Plumsail widget; the replacement Gorgias widget is not subject to SharePoint CSP restrictions.