Migrate from Plumsail HelpDesk to Zoho Desk

Plumsail ticket records map 1:1 to Zoho Desk tickets. Standard properties (status, priority, assignee, created date) map directly. Zoho Desk returns up to 100 items per page via its API, so we paginate extraction from SharePoint to match. Plumsail internal agent notes and customer-visible comments are distinguished by the SharePoint comment visibility flag and must map to Zoho Desk's Thread entity with the correct direction (Incoming vs Outgoing). Ticket Categories map to Zoho Desk's ticket fields; any category values not pre-created in Zoho Desk are flagged before import.

Plumsail contacts stored in the SharePoint contacts list map to Zoho Desk contacts. We preserve name, email, phone, and organization linkage. Custom contact fields in SharePoint columns map to Zoho Desk custom contact fields. Zoho Desk requires a ContactExtId external ID column during assisted migration; we generate this from the SharePoint item ID and store it on the contact for later lookup resolution during ticket import. Email is used as the dedupe key.

Plumsail Organizations (companies) map to Zoho Desk Accounts. Organization records and their associations with contacts and tickets transfer with any custom properties configured in SharePoint columns. Zoho Desk requires an AccountExtId external ID column; we populate this from the SharePoint item ID. Organization name maps to Account Name, and any website or industry properties map to the corresponding Zoho Desk fields.

Plumsail agents are SharePoint users with the HelpDesk Agent role. We map agent identities and ticket assignments by resolving SharePoint user emails. Zoho Desk requires agents to exist as Zoho Desk agents before tickets referencing them can be imported; agents without a matching Zoho Desk account must be provisioned during scoping. Role-based access control (admin, agent) from Plumsail translates to Zoho Desk permission profiles (Support Admin, Agent). We flag any agents exceeding the target Zoho Desk plan's agent limit before migration.

Plumsail comments are SharePoint list rows linked to ticket items, distinguishing public (customer-visible) from private (agent-only) notes. We map each comment to a Zoho Desk Thread record preserving the visibility flag, author email, and timestamp. Thread direction (Incoming from customer vs Outgoing from agent) is inferred from the Plumsail comment sender type. Large comment histories (over the Plumsail plan's monthly cap) require staged import to avoid billing overages; we flag estimated comment volume during scoping.

Plumsail tags are SharePoint taxonomy or choice-field keywords applied to tickets. We preserve tag strings exactly and reapply them to destination Zoho Desk tickets. Tag count and naming are preserved without transformation. Zoho Desk's native tag feature is used for the mapping. Tags not found in Zoho Desk are created during the import phase.

Plumsail categories are structured classification labels stored as a choice or lookup field on the ticket list. We map category values to Zoho Desk fields, pre-creating any missing picklist values before migration. Category associations with SLA rules require corresponding Zoho Desk SLA policy configuration to be in place before tickets are imported with SLA assignments.

Knowledge base articles are SharePoint list items or pages managed inside the Plumsail HelpDesk site. We map article titles, content, and category associations to Zoho Desk Solutions. Formatting and embedded media may require post-migration cleanup. Articles are imported before tickets so that any article links embedded in ticket descriptions resolve correctly.

File attachments on Plumsail tickets are stored in SharePoint document libraries linked to ticket items. We extract attachment files and their ticket associations. Large attachment volumes stress both the SharePoint extraction phase (due to throttling) and the Zoho Desk import phase (10GB limit). We estimate total attachment file size during scoping and flag if staging or separate attachment migration is needed.

SLA rules in Plumsail define response and resolution time targets by priority or ticket type. We map SLA configurations as rule definitions to Zoho Desk SLA policies. Destination SLA enforcement depends on the Zoho Desk plan tier supporting SLA features (Standard and above). SLA-to-agent-assignment mappings are preserved as Zoho Desk escalation rules.

Plumsail views are saved SharePoint list views with filters, groupings, and column ordering. We map view configurations as reference data. Views are SharePoint-specific and may need to be rebuilt as saved views or filters in Zoho Desk. We document the current view structure for the customer's admin to reference during Zoho Desk configuration.

Plumsail Triggers are Power Automate flows stored on the SharePoint site and are configuration, not data. They are tied to Plumsail's internal solution actions and cannot be migrated. We inventory all active Triggers during discovery, document their logic and firing conditions, and provide a rebuild guide mapping each trigger to Zoho Desk Blueprint steps or Zoho Flow equivalents.

Plumsail 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 CSV snapshots before migration. Post-migration, reports are rebuilt in Zoho Desk's reporting module or connected to an external BI tool.

The embedded support widget is a portal component configured in Plumsail. We map widget settings (branding, ticket form fields, submission rules) as configuration data for documentation. CSP enforcement changes in 2026 may affect the Plumsail widget; Zoho Desk's customer portal replaces this functionality and requires separate configuration.