Migrate from Mava to Zoho Desk

Mava Conversations map directly to Zoho Desk Tickets. Each conversation's message history, participant metadata, and channel source (Discord, Telegram, or web) transfer as Ticket fields and child Thread records. The original channel source is preserved in a custom field mava_channel_source__c because Zoho Desk's standard Ticket object does not have a native channel attribution field for Discord or Telegram tickets. Created timestamp migrates via API; Zoho Desk's default CSV import cannot preserve original created dates, requiring a custom field and comment injection for audit compliance.

Mava's AI bot intent catalog and automated response rules are stored as channel-specific JSON configurations that do not have a direct Zoho Desk equivalent. We extract the full intent catalog across all Discord, Telegram, and web channels, normalize intent names and trigger conditions, and deliver a written inventory document that maps each Mava intent to a Zoho Desk Blueprint or workflow rule. The customer's admin rebuilds automation in Zoho Desk's visual builder. Channel-specific conditions (Discord role gates, Telegram command prefixes) are noted as not natively transferable.

Mava community members linked by Discord ID or Telegram ID require identity resolution before migration. Where a Discord or Telegram user has a verified email associated with their Mava profile, we map directly to Zoho Desk Contact using email as the dedupe key. Where identity is Discord ID or Telegram ID only with no email, we flag those records during scoping and work with the customer to determine handling: either map to anonymous Contacts with a placeholder email, or defer migration pending customer-side identity enrichment. Unresolved identities are documented in the migration manifest with original platform ID preserved in mava_member_id__c.

Mava support agents map 1:1 to Zoho Desk agents by email match. Zoho Desk requires agent profiles to exist in the destination before ticket import can associate tickets with agents, so we provision agent records as the first migration phase. Agent roles (admin, agent) map from Mava's role structure, and team assignments are preserved in the Zoho Desk team membership records. Note: Zoho Desk distinguishes Agent (full reply/comment access) and Light Agent (view-only) roles; we map Mava's agent role accordingly based on the customer's Zoho Desk edition tier.

Mava team structures map to Zoho Desk Teams with member lists preserved. Zoho Desk's native import tools cannot create Teams via API; we create Teams using Zoho Desk's REST API before ticket migration begins, populating team names from Mava and adding members by resolving agent email matches. Teams must be created and Team Assignment must be enabled in Zoho Desk settings before migration for ticket routing to function correctly.

Mava conversation tags migrate as Zoho Desk Ticket tags. Tags are simple string key-value pairs that map directly between platforms. If the destination Zoho Desk account already contains tags with the same names, Zoho Desk associates them; otherwise, tags are created during migration. Tags used for reporting segmentation are preserved without transformation.

Mava SLA rules (first-response time and resolution time targets per channel or team) map to Zoho Desk SLA policies with configuration notes. Zoho Desk SLA policies are built within specific Departments; we identify the target Department for each SLA rule during scoping, map the time thresholds to Zoho Desk's SLA policy format, and deliver a written configuration guide for the customer's admin to apply in Zoho Desk's SLA setup. Note: SLA metrics that are purely informational in Mava without strict enforcement may not require active SLA policy migration.

Mava webhook integrations store endpoint URLs and trigger conditions that cannot be automatically transferred to Zoho Desk because Mava webhook payloads are customer-defined with no documented standard schema. We extract all webhook endpoint URLs, trigger event types (conversation created, resolved, escalated), and payload structures from Mava, then deliver a written inventory document that maps each webhook to a Zoho Desk workflow webhook action or an equivalent integration endpoint. Payload transformation logic requires manual mapping in Zoho Desk's workflow builder.

Mava records the originating channel (Discord, Telegram, web) on each conversation. Zoho Desk's standard Ticket object does not have a native channel attribution field for chat-channel tickets, so we create a custom picklist field mava_channel_source__c on Ticket to preserve this metadata. The field is populated during migration and included in all ticket exports for reporting.

Mava conversation assignment (agent or team) maps to Zoho Desk Ticket assignment. We resolve Mava agent email references to Zoho Desk Agent IDs via the agent mapping, and Mava team references to Zoho Desk Team IDs via the team mapping. If a Mava conversation is assigned to a team with no corresponding Zoho Desk Team, the ticket is assigned to the team lead agent and flagged for reconciliation.

Mava conversation statuses (open, pending, resolved, archived) map to Zoho Desk Ticket statuses. The status vocabulary varies by Mava configuration; we extract the full status list during scoping and map each to an equivalent Zoho Desk status (Open, Pending, On Hold, Closed) based on the customer's Zoho Desk department and workflow setup.

Mava conversation file attachments migrate to Zoho Desk Ticket attachments via API. We download attachment files from Mava and upload them to Zoho Desk tickets during migration. Note: Zoho Desk's native ZSwitch migration tool drops attachments, which is one reason we use API-led migration for full-fidelity transfer. Inline images embedded in message content migrate as attachments and as inline references in thread messages.