Migrate from Plumsail HelpDesk to Zendesk

Plumsail Tickets are SharePoint list items with properties for status, priority, assignee, category, tags, and timestamps. We map these 1:1 to Zendesk Tickets. The Plumsail status values (New, Open, Pending, Resolved, Closed) map to Zendesk Ticket Status (New, Open, Pending, Solved, Closed). Zendesk ticket_id is generated at import time; we preserve the original Plumsail ticket ID in a custom field plumsail_ticket_id__c for cross-referencing.

Plumsail Contacts are stored in a dedicated SharePoint contacts list with fields for name, email, phone, and organization linkage. We map to Zendesk End-User records (user_type = end-user). If the customer uses Plumsail's Contact form custom fields, we map these to Zendesk user fields or custom user fields. Email is the dedupe key for import.

Plumsail Organizations (companies) are a distinct list linked to Contacts and Tickets. These map directly to Zendesk Organization records. We resolve the Organization-to-Contact linkage at migration time by creating Organizations first, then linking Contacts to the Organization by name or domain match. Custom Organization properties in Plumsail's SharePoint columns become Zendesk custom organization fields.

Plumsail Agents are SharePoint users with the HelpDesk Agent role. We map agent identities to Zendesk Agent users by email. The Plumsail role (admin, agent) translates to Zendesk's role model (admin, agent, light agent). We flag any agents on Plumsail plans with seat caps (Jet boat: 5, Yacht: 10) who exceed the target Zendesk plan's agent limits and document a seat assignment plan for the customer's admin.

Comments are SharePoint list rows on a Ticket item, with public (customer-visible) and private (agent-only) visibility flags. We map to Zendesk Ticket Comments preserving the visibility: public comments become public ticket updates; private comments become internal notes. Comment author maps to the Zendesk agent by email match. Comment timestamp preserves the original Plumsail created date. We estimate total comment volume during scoping because every imported comment counts against Plumsail's monthly billing cap; staging imports across months is available to smooth billing impact.

Plumsail Tags are SharePoint taxonomy or choice-field keywords applied to tickets for classification. We preserve tag strings exactly and reapply them to Zendesk Tickets as Zendesk native tags. Tag count and naming are preserved. Any tags that contain characters incompatible with Zendesk's tag format (e.g., spaces, special characters) are sanitized during import with a documented rename mapping.

Plumsail Categories are structured classification labels stored as SharePoint choice or lookup fields. We map category values to a custom Zendesk ticket field (dropdown type) that we create during schema setup. Any categories not present in the destination are flagged during scoping for pre-migration field creation to avoid import errors on unmapped values.

Plumsail Knowledge Base articles are SharePoint list items or pages inside the HelpDesk site. We map article titles, content (with HTML formatting preserved where possible), and category associations. Zendesk Guide must be activated in the destination account before article import (only the account owner can activate it). We flag any embedded media or SharePoint-specific links that require re-hosting before import.

Plumsail SLA rules define response and resolution time targets by priority or ticket type. We map SLA configurations as rule definitions in Zendesk SLA Policies, which require the Zendesk Suite or Enterprise plan. We recreate the SLA conditions, business hours, and breach actions in Zendesk's SLA Policy editor. Note that Zendesk SLA policies apply to tickets at the time of creation; migrated historical tickets can be tagged (e.g., migrated_from_plumsail) to exclude them from SLA enforcement if needed.

File attachments on Plumsail Tickets are stored in SharePoint document libraries linked to ticket items. We download attachments from SharePoint and re-upload them to Zendesk Tickets linked by the original ticket ID. Large attachment volumes (above 20 GB total) require chunked extraction to manage SharePoint API load; we flag this during scoping and adjust the migration schedule accordingly.