Migrate from Polar Help Desk to Zendesk

Polar Incidents map directly to Zendesk Tickets. We extract IncidentId, Subject, Description, Status, Priority, Assignee (agent email resolved to Zendesk User), CreatedAt, UpdatedAt, and any linked Work Order references. Closed tickets from the last 12-24 months migrate; very old resolved tickets are archived as a compliance export rather than loaded into Zendesk to keep the starting data set clean. Polar priority levels (Low, Medium, High, Critical) map to Zendesk Priority (low, normal, high, urgent).

Polar Work Orders attach to Incidents as sub-records. Zendesk has no native Work Order object, so we flatten the hierarchy by creating child Tickets in Zendesk linked to the parent Incident Ticket via the zendesk_ticket_id custom field or the Linked Tickets feature on Enterprise plans. Work Order Status and technician assignment migrate as ticket metadata. Each Incident with multiple Work Orders generates a corresponding number of child Zendesk Tickets.

Polar Contact records (name, email, phone, organization linkage) map to Zendesk end-users. The Contact email is the primary dedupe key. If a Zendesk end-user already exists with the same email, we update rather than create. Contact organization linkage is preserved by resolving the parent Account before Contact import so that the OrganizationId lookup is satisfied at insert time. Agent-type Contacts are held for separate agent-user provisioning during the Users phase.

Polar Account records (organization name, domain, address) map to Zendesk Organizations. The Account name becomes the Organization name. Domain-based organization rules in Zendesk can be configured post-migration to auto-link new end-users to their Organization based on email domain. Custom Account properties migrate as Organization custom fields, but field types must be confirmed during scoping against the Zendesk schema.

Polar Teams (agent groupings with roles and permissions) map to Zendesk Groups. Role-based access control differs between platforms: Polar uses a role-permission model while Zendesk uses agent roles (Admin, Agent, Light Agent) plus custom role configurations on Enterprise. We preserve the team membership (which agents belong to which team) as Zendesk Group membership. Role translation is documented for the admin to reconfigure post-migration.

Polar agent accounts (technicians assigned to Incidents and Work Orders) map to Zendesk agent users. Resolution is by email match. Agents without a matching Zendesk user account are held in a reconciliation queue for the customer's admin to provision before the Incidents phase. Agent status (active/inactive) migrates, but Active Directory group membership does not transfer and must be re-linked in Zendesk Admin post-migration.

Polar knowledge base Articles, Sections, and Categories map to Zendesk Guide Articles, Sections, and Categories. We extract article title, body content, author, creation date, last-modified date, and section placement. Polar's undocumented publication-state flags mean articles may migrate as draft status in Zendesk Guide; we flag all affected articles post-migration and provide a bulk re-publish checklist. Article attachments migrate as Zendesk article attachments. Internal links within article bodies are scanned and updated to reflect Zendesk Guide URLs post-migration.

Polar SLA definitions (response and resolution windows per priority tier with business-hours calendars) map to Zendesk SLA Policies. We export the SLA metadata table including window durations, priority mapping, and calendar references. Zendesk SLA breach-action rules (notifications, status changes) are destination-specific and require manual configuration in Zendesk Admin post-migration. We provide a written SLA matrix documenting every source SLA so the admin can recreate the logic in Zendesk's SLA Engine.

Polar manages multiple inbound email accounts that auto-route to Incidents for email-to-ticket. We migrate email-account configuration metadata (account display name, routing address, forwarding rules) but IMAP/SMTP credentials cannot be exported in a migration-safe manner due to plaintext or hashed storage. The customer must manually configure the email accounts in Zendesk Admin post-migration. We provide a checklist of every source email account with its routing configuration for the admin to re-enter.

Documents attached to Polar Incidents and Work Orders migrate as Zendesk Ticket Attachments. Files under 25 MB migrate directly via the Zendesk API. Files exceeding 25 MB require chunked upload or re-upload by the customer post-migration. We preserve the attachment-to-parent linkage by matching the Polar Incident or Work Order ID to the newly assigned Zendesk Ticket ID before attachment insert.

Polar custom fields on Incidents and Contacts migrate as Zendesk ticket fields and user fields. We extract the field definition (name, type, options) and the field values per record. Dropdown, multi-select, text, date, checkbox, and numeric field types map to equivalent Zendesk field types. Boolean fields from Polar become Zendesk checkbox fields. The customer configures the destination custom fields in Zendesk Admin before migration begins; we provide the field creation specification based on the Polar schema extraction.

Polar tags on Incidents migrate as Zendesk tags. Tags are plain-text labels stored per-ticket. We migrate tag values exactly as they appear in Polar. Tag inheritance rules differ between platforms; Zendesk tags are not hierarchical and do not auto-propagate to child tickets. If the customer's reporting relies on tag inheritance, we document this behavior difference for the admin to address via Zendesk business rules post-migration.