Migrate your Plumsail HelpDesk data

Tickets are SharePoint list items with standard properties (status, priority, assignee, created date). The API returns up to 100 items per page. We map ticket records 1:1, preserving status, priority, and timestamps. Comments are stored as a related list and are migrated separately, counting against destination comment quotas.

Contacts are stored in a dedicated SharePoint contacts list, linked to tickets by email or ID. We preserve contact records including name, email, phone, and organization linkage. Custom Contact fields added via SharePoint column configuration are also migrated as standard fields.

Organizations (companies) are a distinct list object linked to Contacts and Tickets. We map organization records and their associations, preserving any custom properties configured in SharePoint columns.

Agents are SharePoint users assigned the HelpDesk Agent role. We map agent identities and ticket assignments. Role-based access control (admin, agent) must be translated to the destination's equivalent permission model, which may differ from SharePoint's role inheritance.

Comments are messages on a ticket — both public (customer-visible) and private (agent-only) notes. Each comment is a row in a related SharePoint list. We migrate comments preserving visibility flags and timestamps. Note that comment volume directly drives Plumsail's billing, so we flag overage risk during scoping.

Tags are SharePoint taxonomy or choice-field keywords applied to tickets for classification. We preserve tag strings and reapply them to destination tickets. Tag count and naming are preserved exactly.

Categories are structured classification labels for tickets, stored as a choice or lookup field. We map category values 1:1. Any categories not present in the destination are flagged for pre-migration creation.

Knowledge base articles are SharePoint list items or pages managed inside the HelpDesk site. We map article titles, content, and associations to relevant ticket categories. Formatting and embedded media require review to ensure fidelity at the destination.

Views are saved SharePoint list views with filters, groupings, and column ordering. We map view configurations as reference data. Since views are SharePoint-specific, they may need to be rebuilt as saved filters or saved searches in the destination system.

SLA rules define response and resolution time targets by priority or ticket type. We map SLA configurations as rule definitions. Destination SLA enforcement depends on whether the target platform supports equivalent SLA constructs, otherwise we document them as reference policies.

Automations (called Triggers in Plumsail) run as Power Automate flows on the SharePoint site. They are not exported as data — they are configuration tied to the SharePoint instance. We document which triggers exist and advise customers to rebuild them in the destination's automation engine post-migration.

File attachments on tickets are stored in SharePoint document libraries linked to ticket items. We map attachment files and preserve their associations to tickets. Large attachment volumes can stress migration throughput and may require chunked transfer handling.

The embedded support widget is a portal component configured in Plumsail. We map widget settings (branding, ticket form fields, submission rules) as configuration data. CSP enforcement changes in 2026 may require reconfiguration of the widget script in the destination.

Reports are generated from SharePoint list data via built-in charting. Report definitions and historical report snapshots are not exportable as a reusable artifact. We advise exporting report data as a one-time CSV read if historical metrics are required.