Migrate from ITarian Helpdesk to Gorgias

ITarian Tickets map directly to Gorgias Tickets. We preserve the full field set: ticket ID, subject, description, status (New, Open, Pending, Resolved, Closed), priority (Low, Normal, High, Critical), assignee (mapped via agent email match), requester (mapped via customer email), created date, updated date, and SLA breach flags. Custom ticket fields discovered during schema discovery map to Gorgias custom ticket fields of equivalent data type. ITarian ticket threads (customer replies, agent responses, internal notes) migrate as ticket messages ordered by timestamp. ITarian status transitions migrate as Gorgias ticket events with timestamps preserved.

ITarian Customer records map to Gorgias Customer objects. We preserve email address (primary dedupe key), name, phone number, language, timezone, and any associated company affiliation. ITarian stores contact details and company association on the Customer record; Gorgias has a separate Customer object with email as the primary identifier. If the ITarian customer has a Shopify order history, we note this in the migration scope because Gorgias will populate order data via its native Shopify integration post-migration rather than storing historical order records from ITarian.

ITarian Agent profiles (name, email, role, team assignment) map to Gorgias Agent records by email match. ITarian role names (Admin, Technician, Viewer) map to Gorgias permission tiers (Full, Restricted, None) with a manual review step because role structures differ between platforms. Agents without a matching Gorgias account are held in a reconciliation queue for the customer to provision before the production migration runs.

ITarian Teams group agents for ticket routing and assignment. We map team names directly to Gorgias Teams and preserve the team-to-agent membership. ITarian team-based auto-assignment on ticket categories migrates as Gorgias Rules with team-based routing conditions. If ITarian uses Department-level routing (a hierarchical team structure), we flag it for manual configuration in Gorgias because Gorgias Teams are flat rather than hierarchical.

ITarian SLA Policies define response time and resolution time targets by priority level and ticket category. Gorgias does not have a native SLA object but supports SLA breach detection through Rules and business hours configuration. We document each ITarian SLA Policy with its priority thresholds, response time targets, and business hours definition, then map to a Gorgias Rule that sets a due date field based on priority at ticket creation. SLA breach flags migrate as a custom due date field rather than a native SLA tracker.

ITarian Workflows are automated triggers on ticket conditions such as status change, priority escalation, or category assignment. Gorgias uses Macros (canned response templates with variable insertion) and Rules (conditional ticket actions like assignment, tagging, or status change). We do not migrate ITarian Workflows as executable code because the automation models differ structurally. Instead, we export each active ITarian Workflow definition as a configuration record documenting its trigger conditions, conditions, actions, and order of execution, then deliver a written inventory recommending equivalent Gorgias Macros and Rules for the customer's admin to rebuild.

ITarian KB articles (title, body content, category association) map to Gorgias Help Center articles. We export article content preserving HTML formatting and map ITarian categories to Gorgias article categories. Formatting differences (ITarian uses HTML body content, Gorgias uses a structured article editor with Markdown support) require a content transformation step. We flag articles with complex HTML (tables, embedded images, code blocks) for manual review before import. Article publication status migrates as draft or published in Gorgias.

ITarian Assets tracked in the endpoint management module can be linked to tickets to provide context (device ID, endpoint name, last remote session). Gorgias does not have a native Asset or Device object. We export the asset-to-ticket linkage and store it as a customer note or a tagged reference on the ticket, flagging that standalone asset records (without a ticket association) cannot be migrated as native objects. Remote session session IDs and remote control history do not migrate; these are documented in the migration scope as a gap.

ITarian allows per-account custom fields on tickets with no metadata endpoint to enumerate them. We discover the full custom field schema by sampling 50-100 ticket records and inferring field names, data types, and value patterns from the response payload. Each discovered field maps to a Gorgias custom ticket field of equivalent type (text, number, date, boolean, dropdown). Unsupported data types (e.g., complex nested JSON stored as text) are flagged for the customer to decide whether to store as plain text or drop. This discovery phase adds 1-3 days to the migration plan before field mapping can be finalized.

File attachments on ITarian tickets (images, documents, screenshots) migrate to Gorgias attachments stored on the corresponding ticket. We export binary blobs to cloud storage, then re-attach them at the target ticket record. Attachment file names and MIME types are preserved. Inline images embedded in ticket descriptions or comments migrate as separate attachment records linked to the ticket message. Maximum file size limits in Gorgias are validated before migration; files exceeding Gorgias limits are flagged for manual delivery.

ITarian Ticket Categories define the type of request (Incident, Service Request, Problem, Change) and drive workflow routing and SLA assignment. Gorgias does not have a native category object; ticket types are handled through Tags and Rules. We map each ITarian Ticket Category to one or more Gorgias Tags, and create a Gorgias Rule that applies tag-based routing conditions to replicate ITarian category routing logic. The customer validates the tag-to-category mapping during the sandbox migration phase.

ITarian records status transitions, priority changes, assignee changes, SLA breach events, and category changes as events on the ticket timeline. We extract these events and insert them as Gorgias Ticket Events in chronological order, preserving the event type, actor (agent or system), timestamp, and any associated note. This preserves the operational audit trail that ITarian agents use for SLA reporting and escalation review.