Migrate from Siit to Gorgias

Siit Requests map to Gorgias Tickets. The request title becomes the ticket subject, description becomes the first ticket message, and submitted_from channel metadata (slack, ms_teams, mail, employee_portal) is preserved as a custom ticket field. Status (open, pending, resolved, closed) maps to Gorgias Ticket status. Priority maps to a custom priority field. We extract all unique Siit custom_form_inputs per request type during scoping and serialize them as a JSON object attached to the ticket in a custom field siit_custom_form_data__c because Siit custom form inputs have no stable schema across organizations.

Siit People records (employee directory: department, team, office location, legal entity, employment type, lifecycle stage) map to Gorgias Customers. We map name and email directly. Department, team, and employment_type migrate as custom Customer fields. Siit People with a target_uid (submitted on behalf of another person) map to a secondary field rather than the primary customer to preserve the requester's identity. Non-Admin People who only submitted requests do not consume Gorgias agent seats, which avoids a month-one billing surprise.

Siit Communication exports include outbound messages and satisfaction survey responses linked to Requests. We migrate conversation threads as Ticket Messages via the Gorgias API. Siit messages from Admins map to agent messages in Gorgias; messages from the request submitter map to customer messages. If the Communication export includes first_replied_at and first_completed_at SLA timestamps, we preserve them in custom ticket fields. CSV exports from Siit's Reporting section omit message bodies—API access is required to preserve the full thread.

Siit Tags associated with Requests via tag_uids arrays map to Gorgias Tags on Tickets. The tagging taxonomy (how teams categorize requests: issue_type, severity, department, source) migrates as-is. We flag any tags that reference Siit-specific concepts (workflow_id, inbox_id) for the admin to reassign post-migration.

Siit Inboxes route requests to specific teams or queues. Gorgias has its own Inbox concept (per-channel or unified). We map Siit Inbox assignments to Gorgias Inbox or team-based routing Rules. If the destination Gorgias account uses a single unified Inbox, we document the Siit inbox structure for manual routing configuration. Siit inbox-based routing logic (which requires human decision-making) does not automatically transfer to Gorgias Rules.

Request records in Siit include first_replied_at and first_completed_at timestamps. SLA timers and escalation configurations export as part of request metadata. We preserve the SLA timestamps in custom ticket fields (siit_sla_first_replied__c, siit_sla_first_completed__c) for compliance reporting. Gorgias has SLA management on Enterprise plans—if the destination plan does not include SLA management, the original SLA data is preserved as metadata only without automated enforcement.

Siit Services catalog items (IT service offerings with configuration metadata and category assignments) have no direct Gorgias equivalent. Gorgias does not have a services catalog or request catalog. We export the full services catalog as a structured document (service name, description, category, associated workflows) and deliver it to the customer's admin for use in a knowledge base article set or separate service portal if needed. This is not an automated migration; it is a documentation deliverable.

Siit Application inventory tracks software assets with ownership, lifecycle status, and category metadata. Gorgias does not have an asset management or CMDB module. We export application inventory as a CSV (app name, owner, lifecycle_status, assigned employee, category) and deliver it to the customer as a reference document. If the customer needs ongoing asset tracking, a dedicated CMDB tool (ServiceNow CMDB, Snipe-IT, or similar) should replace this function separately from the Gorgias migration.

Siit Equipment records represent physical and virtual devices with lifecycle attributes, ownership, and configuration fields. Gorgias does not support equipment or device records. We export equipment inventory as a CSV (device name, type, owner, location, lifecycle_stage, assignment) and deliver it to the customer as a reference document. Facilities-heavy teams relying on Siit for device lifecycle management should evaluate a dedicated CMMS or asset management tool post-migration.

Siit Admins (the billable resolver seat type) map to Gorgias Agents. We resolve by email match. Siit Admins with billing_settings_access (view-only on subscription) do not get a Gorgias Agent seat—only users who actively resolve tickets are provisioned as agents. Siit non-Admin employees (request submitters) map to Gorgias Customers or remain unmigrated depending on whether the customer wants historical requester records inside Gorgias.

Siit Workflows (trigger conditions, approval chains, automated actions in the low-code builder) do not migrate to Gorgias. Gorgias Macros and Rules are structurally different from Siit Workflows and do not accept direct import. We deliver a written inventory of every active Siit Workflow with its title, trigger, conditions, actions, and state (Live, Paused, Draft) plus a recommended Gorgias equivalent (Macro, Rule, or Rule set) for each. The admin rebuilds these manually post-migration.

Siit custom_form_inputs are arbitrary label/value pairs per request with no fixed schema. We extract all unique labels during the migration scan and map them to a custom Gorgias ticket field siit_custom_form_data__c stored as structured JSON: {label: value, label: value}. If the customer requests per-field mapping instead of JSON serialization, we create individual custom Ticket fields for the top-20 most common labels and serialize the remainder. This requires the customer to have custom field creation permissions in Gorgias.