Migrate from Atomicwork to Gorgias

Atomicwork Request maps to Gorgias Ticket as the primary record. We preserve Request ID as an external_id field on the Gorgias Ticket for cross-reference. The Request status lifecycle (Open, Pending, Resolved, Closed) maps to Gorgias Ticket status with a custom field aw_original_status__c retaining the source status value. Priority (Low, Medium, High, Critical) maps directly to Gorgias priority. We carry the AI-resolved versus human-resolved flag from Atomicwork into a custom Ticket field aw_resolved_by__c. Request categories (IT, HR, Finance) map to Gorgias Tags for filtering; a separate category taxonomy is created in Gorgias during schema setup.

Atomicwork employee requesters map to Gorgias Customer records. The critical difference is the data model: Atomicwork requesters are internal employees with department, role, and manager fields; Gorgias Customers are external shoppers with email, name, phone, and order history. We migrate the email and name for each Atomicwork requester but flag that department, role, and manager fields have no Gorgias equivalent. If the customer uses Gorgias's Shopify integration, the migrated Customer email is matched against Shopify buyer profiles during cutover to restore order linkage. Inactive or deactivated Atomicwork users are held in a reconciliation queue.

Atomicwork agents (IT staff, HR staff, Finance staff who resolve Requests) map to Gorgias Agent records. We resolve agents by email match. Agent permissions in Atomicwork (Admin, Agent, Requester) map to Gorgias Agent roles with corresponding inbox and channel access. Atomicwork workspace membership requires a Gorgias team structure to be defined before migration: each Atomicwork workspace with active agents becomes a Gorgias Team with its own inbox assignment. Any Atomicwork agent without a corresponding Gorgias Agent account goes to a provisioning queue.

Atomicwork conversation threads (agent replies, requester replies, and system notes attached to a Request) map to Gorgias Ticket messages in chronological order. We preserve the full message body, timestamp, sender type (agent vs customer), and any internal note flag. Attachment URLs migrate as references; we note that Gorgias does not host file attachments natively and customers should configure a cloud storage integration before migration. Message threading order is preserved by setting the Gorgias message created_at timestamp to the original Atomicwork timestamp.

Atomicwork Assets (CI items linked to Requests such as laptops, servers, software licenses) have no direct Gorgias equivalent because Gorgias is a customer support tool, not a CMDB. We offer two migration strategies: simple mode maps Assets to a tagged Customer record or a custom Ticket field aw_affected_asset__c containing the asset name; advanced mode (requires a separate CMDB tool) exports Assets separately and documents the linkage to Requests as a cross-reference table. Asset Discovery scan results are not API-exportable from Atomicwork and must be sourced via a manual CSV export from the customer before migration begins.

Atomicwork Knowledge Articles used by the AI agent for deflection map to Gorgias Help Center articles. We export article title, body (rich text), category, and publication status. Atomicwork article-to-category assignments require mapping to Gorgias Help Center categories. Tag relationships migrate as Gorgias article tags. We do not migrate article view counts, deflection metrics, or AI feedback scores as Gorgias Help Center uses a different analytics model. Customers with a large Knowledge Base (100+ articles) should allow additional time for article body formatting review since HTML content from Atomicwork may require cleanup for Gorgias's Help Center renderer.

Atomicwork Changes (Request for Change records with risk level, CAB approvers, and approval chain) have no Gorgias equivalent because Gorgias is a customer support platform, not an ITSM tool. Change records cannot be migrated. We document every active Change record during discovery with its status, linked Requests, and approver list, and deliver this as a written inventory for the customer's ITSM team to handle outside of Gorgias. If the customer continues to need Change Management after migration, a separate ITSM platform (ServiceNow, Jira Service Management, or Atomicwork) is required.

Atomicwork intake Forms with field structure map to Gorgias Macros (canned responses and ticket templates) or Help Center submission forms depending on use case. Form field labels and definitions export from the API, but conditional branching, required field rules, and form logic are not fully exposed via API. We export form definitions as a written spec and the customer's admin rebuilds equivalent forms in Gorgias. This is a manual reconstruction task, not a data migration.

Atomicwork Workflow automations (triggers, conditions, and actions built in the visual builder) are not API-exportable. We run a full workflow audit during discovery, documenting every active automation with its trigger type, condition logic, and downstream actions. This inventory is delivered as a written rebuild checklist for the customer's admin to reconstruct in Gorgias Automate or via Gorgias's macro and rule system. There is no shortcut: every SLA escalation timer, assignment rule, approval routing flow, and notification trigger must be manually rebuilt.

Atomicwork Tags applied to Requests and Knowledge Articles map directly to Gorgias Tags. We export tags as a flat list and import them as Gorgias Tags attached to the corresponding Tickets and Help Center articles. Tag count is preserved. If the customer used tag hierarchies or tag-based routing in Atomicwork, we document this as a routing rule to be rebuilt in Gorgias Automate.

Atomicwork workspaces are top-level organizational containers for Requests, Assets, Users, and workflows. Multi-workspace accounts require us to map each workspace to a Gorgias Team with its own inbox and agent assignment. We validate during scoping which workspaces contain live data versus sandbox/test data, and whether the destination Gorgias account requires a corresponding team structure. Teams with no active Requests are noted as empty and can be archived post-migration.

Atomicwork First Response and Resolution SLA timers attached to Requests map to Gorgias SLA policies. We extract SLA definitions (timer duration, business hours calendar, escalation action) from Atomicwork and configure equivalent Gorgias SLA policies per mailbox or channel. Escalation actions (notify supervisor, escalate to tier-2) require manual reconstruction in Gorgias because Gorgias's escalation model uses different action types.