Migrate from Alloy Navigator to Gorgias

Alloy Navigator Service Requests map directly to Gorgias Tickets. The source ticket ID is preserved as a custom field an_src_id__c for audit traceability. Ticket status values require explicit mapping per classification because Alloy Navigator allows status labels to differ across ticket classes (Open may be New in one classification and Active in another); we detect all distinct status value sets during discovery and produce a consolidated mapping table before ingestion.

Alloy Navigator Incidents linked to a parent Service Request migrate as additional message threads on the corresponding Gorgias Ticket. We extract the Incident description, resolution notes, and timestamps, and append them as internal notes or public replies on the ticket based on the customer's visibility preference selected during scoping.

Alloy Navigator Organizations map to Gorgias Customers. The organization name becomes Customer.name, the primary email becomes Customer.email, and any organizational phone or address fields migrate to Customer.phone and Customer.address. Organizations with multiple linked Contacts produce multiple Gorgias Customer records with shared metadata.

Alloy Navigator Contacts map to Gorgias Customer records. Email is the primary dedupe key. We preserve the Contact's full name, phone, role, and the parent Organization reference as a Gorgias Customer tag for segmentation. Contacts without email addresses are flagged during discovery and assigned a placeholder email or mapped to a customer note field depending on the customer's preference.

Alloy Navigator KB articles migrate to Gorgias Knowledge Base articles with article body, metadata, and attachments preserved. Category hierarchies in Alloy Navigator do not map 1:1 to Gorgias flat category structure; we flag category depth during scoping and propose flattening (root category as the Gorgias category, subcategories as tags) before migration begins.

Alloy Navigator Users and Technicians map to Gorgias Agents. We resolve by email match. Active status, role, and team assignment migrate as Agent role and group membership. Inactive Alloy Navigator users migrate as inactive Gorgias agents to preserve assignment history on migrated tickets. Agents with no email are flagged for manual provisioning before production migration.

Alloy Navigator Locations form a hierarchical tree (Site > Building > Floor > Room). Gorgias Customer address fields are flat (street, city, state, zip, country). We detect location tree depth during scoping and propose one of two strategies: root-path as string (Site/Building/Floor) stored in a custom Customer field, or parent-child flattening with the deepest-level address used as the primary Customer address. Deep trees with more than four levels require explicit customer approval of the chosen strategy.

Alloy Navigator Work Orders migrate as Gorgias Tickets with a wo_type tag to distinguish them from standard support tickets. Work order schedules, assignments, and completion tracking migrate as ticket custom fields and internal notes. Work-order-specific custom fields are mapped to Gorgias custom ticket fields. Work orders that depend on Gorgias workflow features (not available in this migration scope) are documented in the handoff inventory.

Configuration Items (hardware, software, virtual components, and their relationships) have no direct Gorgias equivalent because Gorgias is a customer support platform, not a CMDB. We extract the full CI inventory and relationship graph as a structured JSON export and CSV report, which the customer's IT team uses to populate a dedicated ITSM or ITAM tool post-migration. This export is part of the standard scope.

Alloy Navigator Assets (hardware devices, software licenses, consumables) do not map to Gorgias. We extract the full asset inventory including purchase info, assignment records, and lifecycle status as a structured export. For ecommerce teams, this data is not relevant to customer support; for IT teams repurposing Gorgias, the asset export serves as the baseline for rebuilding asset tracking in a dedicated ITAM tool.

Contracts linked to Assets and Contacts migrate as a Contract inventory export with renewal dates, terms, and costs. Gorgias does not have a contract management module; the export is a structured CSV and JSON deliverable for the customer's admin to file in their contract lifecycle management tool.

Software License records (seat counts, compliance metrics, purchase history attached to Assets) export as a structured license inventory. This does not map to Gorgias; it is a deliverable for the customer to manage in a dedicated SAM tool. License entitlement calculations are Alloy Navigator-specific and cannot be translated without the destination SAM context.

Alloy Navigator Workflows (approval chains, escalations, Create Actions, and conditional branching) do not migrate as code because Gorgias uses a different automation model (macros, rules, and SLA policies). We deliver a written workflow inventory listing every active Alloy Navigator Workflow with its trigger, conditions, actions, and a recommended Gorgias macro or automation rule equivalent. The customer's admin rebuilds these in Gorgias post-migration.

Alloy Navigator Change records migrate as Gorgias Tickets tagged with change_request to preserve audit history. Change type (Standard, Normal, Emergency), risk assessment, approval status, and implementation plan migrate as custom ticket fields. Gorgias SLA policies can be configured to match Change Management urgency tiers, but the change workflow itself (approvals, rollbacks) is documented for admin rebuild.