Migrate from Yuma AI to Gorgias

All tickets in the Gorgias host instance are Yuma's source of truth. We pull the full ticket corpus via the Gorgias REST API — subject, body, status, assignee, channel, timestamps, and custom fields — and reconcile against any Yuma-applied resolution status flags. We flag which tickets were resolved autonomously by Yuma Auto-Pilot (vs. human agent) so Gorgias AI Agent can use this signal for retraining. Historical ticket IDs are preserved in a custom field yuma_original_id__c to maintain traceability.

Every message within a ticket thread migrates, including Yuma's auto-replied messages and human agent replies. We tag each message with a source flag (yuma_autopilot, yuma_agent_assist, or human) so the Gorgias AI Agent can be trained on Yuma-authored responses as positive examples. Inline attachments (images, PDFs, order screenshots) carry over via the Gorgias API URL references. Message timestamps are preserved to maintain conversation ordering.

Customer profiles live in the host Gorgias instance and are read by Yuma to ground AI replies. We migrate all customer fields — name, email, phone, address, Shopify order history — via the Gorgias Customer API. Email address is the dedupe key. Any Yuma-profiled attributes (sentiment scores, LTV estimates) that are not native Gorgias fields are stored as custom fields prefixed yuma_ for later evaluation.

Gorgias Macros (pre-written response templates used by agents) are a standard helpdesk feature, not a Yuma construct. We migrate Gorgias Macros as normal from the source instance if the customer is also moving to a new Gorgias org. Yuma does not own Macros — it reads from the helpdesk's macro library. If the customer is remaining in the same Gorgias instance and only removing the Yuma overlay, macros are unaffected.

Yuma Auto-Pilot agents are a separate logical layer mapped to specific ticket types (WISMO, returns, refunds, subscriptions). Gorgias AI Agent is configured per automation type inside Gorgias Automate. We export Auto-Pilot configurations as structured JSON documenting the ticket type trigger, the SOP steps, the guardrails, and the escalation rules. This JSON is a reference artifact for rebuilding inside Gorgias Automate — it does not import directly because the automation engines are architecturally different.

Yuma Guidelines are brand policy rules that constrain AI behaviour and prevent hallucinations — conditions, actions, allowed channels, and prohibited language. Exported as structured JSON covering every Guideline condition and action. Gorgias AI Agent uses a Brand Voice section and a Knowledge Base for AI grounding. We map each Yuma Guideline to a Gorgias equivalent (Brand Voice instruction or KB article constraint) and document the remainder as a manual configuration guide. This is a manual rebuild workstream outside the automated migration.

Yuma Flows are visual automation workflows for ticket routing, triggers, and escalation sequences — if/then logic trees with ordered API calls and audit trails. Exported as JSON with full condition logic and step definitions. Gorgias Automate uses rules-based triggers (channel, tag, customer attribute, ticket subject pattern) rather than a visual flow builder. We map each Flow trigger condition to the nearest Gorgias Automate rule equivalent and provide a written rebuild guide for complex Flows that require multi-step logic not expressible in Gorgias's rule model.

Yuma applies internal tags during processing (resolution type, automation status, channel source, language). We export all Yuma-applied tags alongside each ticket so they can be reapplied in Gorgias. Tags in Gorgias are used for routing, filtering, and AI Agent trigger conditions. We reconcile tag naming between Yuma and Gorgias namespaces and flag any tags that exist in Yuma but not in the destination Gorgias instance for the admin to create pre-import.

Yuma respects and populates custom fields defined in the host Gorgias instance — order ID, return reason, subscription tier, product SKU. These custom fields are part of the Gorgias schema, not Yuma's own data. We preserve all custom field values during migration and map them to identically named fields in the destination. If the destination is a fresh Gorgias instance, we pre-create the custom field schema before import so no values are silently dropped.

Yuma does not host its own knowledge base — it reads from the host helpdesk's KB or Shopify product data at inference time. If the customer is migrating to a new Gorgias instance, the KB articles migrate from the source Gorgias helpdesk via the standard article export/import. Yuma's knowledge contribution is the set of documents and SOPs uploaded to its Sources tab, which we export separately and deliver as a reference corpus for re-uploading to Gorgias's Help Center.

Yuma's direct integrations with Shopify, Recharge, and Klaviyo are outbound API connections that exist only within the Yuma platform. These must be re-established in Gorgias independently of the migration. Gorgias has native Shopify, Recharge, and Klaviyo integrations. We document every active Yuma integration, the API credentials in use, and the recommended Gorgias native integration to replace it, as a configuration guide for the customer's admin team.

Yuma's analytics dashboard surfaces resolution rates, CSAT scores, automation health, and per-channel performance. These metrics are not a Yuma data store — they are computed from ticket events. We export the resolution metrics as a structured CSV (monthly granularity, by ticket type, by channel) so the customer can set baseline benchmarks in Gorgias Automate's dashboard. The Gorgias AI Agent's own reporting will diverge from Yuma's due to the different confidence thresholds and resolution definitions.