Migrate from Yuma AI to Zoho Desk

Tickets originate in the host helpdesk (Gorgias, Zendesk, or Kustomer) and are the primary migration record. We preserve the full ticket body, subject, priority, status, channel metadata, and all custom field values. Yuma's resolution status (resolved, escalated, pending_customer, pending_agent) maps to Zoho Desk Ticket status values (Open, Pending, On Hold, Closed). Message threads migrate with sender attribution so that Yuma's auto-replies are identifiable as internal notes in Zoho Desk, allowing Zia to be grounded in the same reply corpus.

Contact profiles live entirely in the host helpdesk. Yuma reads name, email, phone, order history, and contact records to ground AI replies. We carry all standard contact fields through to Zoho Desk Contacts via the helpdesk API export. Email address serves as the dedupe key during Zoho Desk import.

Company-level data from the host helpdesk (e.g., Zendesk Organizations, Gorgias companies, Kustomer conversations) maps to Zoho Desk Accounts. The Account object is created before Contact import so that the account lookup relationship is satisfied at the moment of Contact insert. AccountName maps from the host company name; additional fields (website, phone, industry) transfer directly.

Every message in a ticket thread migrates to Zoho Desk Thread records. We flag which messages were authored by a Yuma Auto-Pilot versus a human agent by prepending an internal note tag (e.g., [Yuma-Auto-Pilot]). This preserves the AI reply corpus for Zia Skills grounding without mixing it into the visible customer thread. Attachments on individual messages transfer via the helpdesk API.

Yuma Auto-Pilot agents are a separate logical layer from human support agents and do not map 1:1 to Zoho Desk agents. We extract human agent identities from the host helpdesk export and match by email address against Zoho Desk agent accounts. Yuma Auto-Pilot escalation routing rules (which team or agent a ticket routes to under specific conditions) map to Zoho Desk team assignments and department-level routing configurations.

Yuma routes edge-case tickets to specific human teams based on rules configured in Flows. We map these team assignments to Zoho Desk Teams, using team name as the dedupe key. Teams that exist only in Yuma (e.g., a Yuma-proprietary escalation queue with no corresponding Zoho Desk team) go to a reconciliation list for the customer's admin to define the destination before import.

Yuma respects and populates custom fields defined in the host helpdesk (e.g., order ID, return reason, subscription tier, product variant). We preserve all custom field values at migration time and map them to Zoho Desk custom fields, creating the destination custom fields in the appropriate modules (Tickets, Contacts, Accounts) before import. Field type mapping: text to single-line, textarea to multiline, dropdown to picklist, multi-checkbox to multi-select picklist.

Inline attachments on tickets — images, PDFs, order screenshots — are carried over via the helpdesk API. Yuma does not store its own attachment blob; we pull directly from the host platform as normal. Zoho Desk's import process supports attachments up to 20 MB per file. We flag any attachment over this limit for manual handling.

Yuma applies internal tags during processing (e.g., resolution_type, automation_status, yuma_auto_response). We export all Yuma-applied tags alongside the ticket and store them in a Zoho Desk custom field (multi-select picklist or tag-style custom field) so that the customer can use them for classification and reporting. Zoho Desk does not have a native tag object equivalent to Zendesk or Gorgias tags, so we recommend the custom field approach during scoping.

Guidelines are Yuma's brand policy rules that constrain AI behavior and prevent hallucinations — they are the most transferable proprietary asset in a Yuma migration. We export Guidelines as structured JSON with full condition logic, allowed channels, and escalation actions. This JSON is delivered as a migration artifact and is used as input for Zia Skills configuration in Zoho Desk, giving the customer's admin a reference document for rebuilding the brand policy logic in Zia rather than authoring it from scratch. No automated migration of Guidelines to native Zoho Desk objects is possible because there is no Guidelines-equivalent standard object.

Flows are Yuma's visual workflow builder for ticket routing, triggers, and escalation sequences. We export Flow definitions as JSON with trigger conditions, condition branches, and action sequences. This JSON is delivered as a migration artifact and is accompanied by a written inventory mapping each Yuma Flow to an equivalent Zoho Desk Blueprint (step-by-step process guides) or workflow rule (event-triggered actions via Deluge scripts). Blueprint and workflow rebuild is out of scope for the data migration; we document the mapping for the customer's admin or a Zoho implementation partner.

Yuma Auto-Pilot configurations (which AI agent handles which ticket types, confidence thresholds, human escalation triggers, and SLA behavior) are Yuma-proprietary and do not map to a native Zoho Desk object. We export Auto-Pilot configurations as structured JSON and deliver them alongside the Guidelines and Flows export. The JSON serves as the input document for Zia Agent skills configuration in Zoho Desk. This is a manual rebuild step scoped as a separate workstream after data migration completes.

Yuma does not own or host a knowledge base — it reads from your helpdesk's KB or Shopify product data at inference time. We migrate KB articles from the host platform directly to Zoho Desk Help Center. ASAP-style custom fields (if present in the host helpdesk) map to Zoho Desk article custom fields. Article category structure migrates as Zoho Desk categories. Note: Zoho Desk's Migration Wizard does not transfer article attachment metadata; we handle attachments separately via API.

Products defined in the host helpdesk (e.g., Gorgias product catalog, Zendesk Knowledge Base products) migrate to Zoho Desk Products module. ProductCode, description, and pricing information transfer directly. Products are created before ticket import so that product lookup fields on tickets resolve at insert time.