Migrate from Infraon Desk to Gorgias

Infraon Desk Incidents map to Gorgias Tickets. We migrate subject, status, priority, assignee, requester, conversation history (comments and internal notes), tags, external ID, and channel metadata. Custom fields on Infraon Incidents require enumeration during scoping; we map them to Gorgias Ticket custom fields via the /api/custom-fields endpoint. Conversation threading preserves chronological order. Attachments migrate as Gorgias attachments linked to the ticket. Note: SLA timer state resets to zero at import time; we flag SLA-breached tickets in a migration manifest so the customer can renegotiate targets post-migration.

Infraon Desk Problems have no direct Gorgias equivalent. Problems are linked root-cause records that associate with one or more Incidents. We decompose Problems into a primary Ticket with a tag (e.g., problem-linked) and linked child Tickets for each associated Incident. The original problem record ID and workaround/resolution text are stored in ticket custom fields. The customer decides during scoping whether to treat Problems as tagged tickets with a parent-child relationship or as flat tagged records without hierarchy.

Infraon Desk Changes include type (Normal, Standard, Emergency), risk level, approvals, scheduled dates, and CAB associations. Gorgias has no native Change Management object. We map Change records to Tickets with a change-type tag, storing type, risk level, and scheduled dates in custom fields. Approval status and CAB role assignments do not map to Gorgias; we flag these as requiring a manual governance process post-migration. If the customer requires full ITSM Change Management workflows, Gorgias is not the appropriate destination.

Infraon Desk CIs live in the CMDB and link to Incidents, Problems, and Changes. Gorgias has no native CMDB or CI object. We enumerate all Infraon Desk CI types and their custom fields during discovery (adding 1-2 days to the scoping phase), then create Gorgias Ticket custom fields to store CI reference data: CI name, CI type, CI serial/asset tag. For customers who need full CMDB functionality post-migration, we recommend a dedicated CMDB integration (ServiceNow, Snipe-it) and flag this as a post-migration architecture decision.

Infraon Desk Assets (hardware and software inventory) link to the CMDB. Custom fields on Assets must be enumerated per asset type during migration scoping, just as with CIs. Gorgias has no Asset object. We create Customer custom fields to store asset reference data (hardware type, serial number, assigned user) where ecommerce relevance exists, or we map to a dedicated asset management system post-migration. Large asset inventories (over 5,000 records) are chunked into batches for reliable API import.

Infraon Desk KB Articles and their category assignments migrate to Gorgias Help Center Articles. Article HTML content transfers directly. Category hierarchies of more than one level must be flattened to Gorgias's single-level folder model; we flag any multi-level hierarchies during scoping and advise the customer on reorganising into single-level categories before migration. Article visibility rules migrate as article-level publication status. Attachments migrate as article attachments.

Infraon Desk SLA policies (response and resolution time targets per priority level) do not migrate as active configuration to Gorgias. Gorgias supports SLA configuration, but the Infraon Desk SLA definitions must be recreated manually in Gorgias Settings. We export the full SLA policy definitions as a JSON manifest during discovery and deliver it as part of the post-migration handoff package. The active SLA timer state cannot be preserved; every ticket with a live SLA is flagged with the original breach deadline in a custom field so the customer can decide whether to honour the original SLA or renegotiate.

Infraon Desk technicians (billable seats) map to Gorgias Agents. We resolve by email match. During discovery, we identify all Infraon Desk user roles; agents with admin or supervisor roles map to Gorgias Admin roles, and standard technicians map to Agent roles. Group assignments on Infraon technicians map to Gorgias Teams. The critical reconciliation: Infraon Desk bills only on technician count; Gorgias bills per ticket. We validate the exported user list against the actual Infraon Desk paid seats before decommissioning the old account.

Infraon Desk end-users (requesters) are free seats and map to Gorgias Customers. Customer fields migrate: name, email, phone, language, timezone, note, and customer type. Custom fields on Customers migrate via the Gorgias /api/custom-fields endpoint with object_type=Customer. If the customer uses Infraon Desk's self-service portal with requester accounts, those accounts become Gorgias Customers with the note field indicating original portal access.

Infraon Desk Service Catalogue items define requestable services with associated forms and workflow triggers. Gorgias has no native service catalogue. We map catalogue items to Gorgias Macros (canned responses with actions), Help Center categories (for self-service requests), or ticket templates depending on the item type. Workflow trigger conditions cannot migrate; we document each trigger as a recommended Gorgias Rule action in the post-migration handoff. Service Catalogue migration requires the customer to decide which items map to which Gorgias construct during scoping.

Infraon Desk Releases track deployment packages and their associated Changes. Gorgias has no native Release Management object. We map Releases to Tickets with a release tag, storing release version, planned rollout date, and linked Change IDs in custom fields. This is a best-effort mapping; the customer should evaluate whether a dedicated release management tool is required post-migration.

Tags applied to Tickets, Assets, and KB Articles in Infraon Desk migrate as Gorgias Tags. Tag co-occurrence patterns and usage counts are preserved for reporting continuity. Tags used for ITSM classification (priority tags, CI-type tags) may require renaming to align with Gorgias tagging conventions during scoping.