Migrate from Polar Help Desk to Gorgias

Polar Incidents are the core ticket object and map directly to Gorgias Tickets. The Incident status (Open, Pending, Resolved, Closed), priority (Low, Medium, High, Critical), created_at, updated_at, and assigned agent resolve to Gorgias ticket status, priority, timestamps, and assignee_user_id. Polar's incident_number becomes the Gorgias ticket external_id for dedupe and reconciliation. Polar's description and initial message content migrate as the first Ticket Message.

Polar Work Orders are sub-records attached to Incidents with their own status, technician assignment, and description. We have two migration paths: (a) flatten Work Orders into separate Gorgias Tickets linked by a shared tag (e.g., wo-parent-{incident_id}) or custom field parent_incident__c, or (b) map Work Orders to Gorgias Issues if the destination account has the Issues module enabled. We recommend option (a) for most accounts and flag option (b) during scoping if the customer has more than 3 Work Order types. The Work Order status maps to a parallel Gorgias ticket status column.

Polar Contacts (name, email, phone, organization linkage) map to Gorgias Customers. The Contact email is the primary key and dedupe field. Phone migrates to Customer phone. Any Polar Contact without an email address is flagged and mapped with a generated placeholder address for the customer's admin to correct post-migration.

Polar Accounts represent organizations linked to Contacts and Incidents. In Gorgias, organization data lives on the Customer record's company_name and address fields. We migrate Account.name to Customer company_name, Account.domain to Customer website, and link all associated Contacts to the Customer by email match. If the Polar deployment uses separate Account and Contact objects extensively, we map Account custom fields to Customer custom fields and flag any Account-level reporting requirements for Gorgias dashboard configuration.

Polar Teams define agent groupings with roles and permissions. We migrate team structures to Gorgias Agent Groups. Role mappings require manual translation: Polar role permissions (Admin, Agent, Manager) do not have direct Gorgias equivalents—Gorgias uses Admin, Agent, and Supervisor roles. We document the source role-to-permission matrix and provide a role mapping recommendation for the customer's admin to configure in Gorgias Settings > Team.

Polar Knowledge Base Articles with Category and Section hierarchy migrate to Gorgias articles. Polar's 3-level hierarchy (Category > Section > Article) flattens to Gorgias's 1-level folder hierarchy: we map Polar Categories to Gorgias folders and Polar Sections to article categorization tags or folder sub-tags. Article content (HTML), title, author, created_at, and updated_at migrate directly. We flag all affected articles post-migration because internal publication-state flags may require manual activation in Gorgias.

Polar SLA definitions (response and resolution windows per priority tier with optional business-hours calendars) migrate as metadata documentation. We extract the SLA table (priority tier, first response time, resolution time, business hours calendar) and deliver it as a written handoff document. The actual SLA Policy in Gorgias (trigger, conditions, actions) must be recreated manually in Settings > SLA Policies because SLA breach escalation triggers are destination-specific and not migratable as code.

Polar manages multiple inbound email accounts that route to Incidents. We migrate email-account configuration metadata (display name, routing rules, forwarded address) to Gorgias Channel settings. However, IMAP/SMTP credentials cannot be migrated due to plaintext or hashed credential storage that is not exportable in a migration-safe manner. The actual mailbox credentials must be re-entered manually in Gorgias Settings > Channels > Email post-migration to restore email-to-ticket routing.

Documents attached to Incidents and Work Orders migrate as Ticket Attachments in Gorgias. We re-attach files to their parent Ticket records using the Gorgias API attachment endpoint. Large binary attachments exceeding 25 MB are flagged for chunked upload handling. We preserve the original filename, MIME type, and uploaded_at timestamp on each attachment.

Polar custom fields on Incidents (dropdown, text, date, numeric types) migrate to Gorgias Ticket Custom Fields. We require a schema diff against the stock Polar v5 database before committing to field-level mapping because on-premise deployments with modified source code may have non-standard field schemas. Custom field types map to equivalent Gorgias field types (text, number, date, select, multiselect) with validation rules preserved as field constraints.

Polar custom fields on Contacts migrate to Gorgias Customer Custom Fields using the same type-mapping logic as Incident custom fields. We extract custom field definitions and values during the Contact migration phase and flag any required custom properties that need to be pre-created in Gorgias Settings > Customer Fields before Contact import begins.

Polar Tags label Incidents for categorization and reporting. We migrate tag values as plain-text labels to Gorgias Tags, preserving the full tag vocabulary from the source. Tag inheritance rules (if a Work Order inherits tags from its parent Incident) require manual review post-migration because Gorgias tagging does not support hierarchical inheritance by default.

Polar Active Directory integration is a destination-side SSO and user provisioning configuration that cannot be migrated as data. We flag this as a manual re-implementation step. The customer's admin must configure SAML SSO or Google OAuth in Gorgias Settings > Security > SSO post-migration and re-link Active Directory group memberships to Gorgias Agent Groups.