Migrate from Mava to Gorgias

Mava Conversations map directly to Gorgias Tickets. The conversation ID becomes the ticket's external_id field for reconciliation. Channel source (Discord, Telegram, web) maps to Gorgias's channel field, and message history migrates as ticket comments. Mava's conversation status (open, pending, resolved, closed) maps to Gorgias Ticket status with the caveat that Gorgias does not auto-sync status changes post-import; any Mava status updates after import require manual updates in Gorgias.

Mava community members linked to verified email addresses map to Gorgias Customer by email. Mava members identified only by Discord user ID or Telegram user ID require enrichment before migration: we flag these records during scoping, and the customer can either enrich them with email addresses pre-migration or accept that they will create Gorgias Customer records without email (stored as a note or external_id). The external_id field on Gorgias Customer preserves the original platform identifier (discord:123456789 or telegram:987654321) for reconciliation.

Mava Agent records (name, email, role) map directly to Gorgias Agent. Agent email is used as the dedupe and matching key. If a Mava Agent email does not have a corresponding Gorgias Agent account, we create a placeholder during migration and assign tickets to it with a flag; the customer's admin provisions the live Agent account and remaps tickets post-migration.

Mava team structures (name, member list, assignment rules) map to Gorgias Groups. Team-based routing in Mava becomes Group assignment in Gorgias. If Mava teams have channel-specific routing logic (a team handling only Discord tickets, for example), we document that as a Gorgias Rule condition rather than migrating it as automated logic.

Mava conversation tags map directly to Gorgias Ticket Tags. Tags are simple key-value strings in both platforms with no transformation required. We preserve tag count and usage statistics in the migration manifest for the customer to reference when rebuilding reporting in Gorgias.

Mava's per-channel AI bot intents and automated responses do not migrate as executable automation. We extract the full intent catalog across all channels (Discord, Telegram, web) and map each intent's trigger phrase and response text to a Gorgias Macro. The customer reviews the intent catalog during scoping and rebuilds the routing logic in Gorgias Rules. Channel-specific conditions that apply only to Discord or Telegram do not have a direct Gorgias equivalent since Gorgias does not natively route by Discord role or Telegram group.

Mava's webhook configurations (endpoint URLs, trigger conditions) are extracted and documented in the migration manifest. Webhook payloads are custom per customer and do not follow a standardized Mava schema, so payload transformation requires manual mapping in Gorgias. We provide the endpoint URLs and trigger logic, but the customer or a developer configures the Gorgias HTTP Integration and maps the payload fields.

Mava's first-response and resolution time SLA rules are channel or team-scoped. Gorgias SLA policies are scoped to ticket priority and channel. We extract the Mava SLA configuration (targets in minutes, applicable channels, escalation rules) and map it to Gorgias SLA policies with the understanding that team-based SLA scoping in Mava becomes priority-based scoping in Gorgias. Any Mava SLA rules that cannot map to Gorgias's model are flagged in the manifest for manual configuration.

If Mava conversation tags carry structured metadata (for example, tag values that indicate ticket category, severity, or source system), we map these to Gorgias Ticket custom fields of the appropriate type (text, boolean, or number). The customer defines the custom field schema during scoping, and we create the fields in Gorgias via the API before migration begins.

Mava's channel source (Discord, Telegram, web) is preserved as a text custom field on the Gorgias Ticket. This is useful for teams that want to preserve reporting on channel distribution post-migration, since Gorgias's native channel field does not include Discord or Telegram as native options.

Mava SLA metadata that does not map to Gorgias native SLA policies (for example, SLA breach timestamps, escalation level, or SLA tier name) is preserved as custom fields on the Gorgias Ticket. This preserves historical SLA data for reporting even if the active SLA enforcement is rebuilt from scratch in Gorgias.

If Mava tracks community member type (for example, admin, moderator, verified user, or general member), we map this to a Gorgias Customer custom field. This is particularly relevant for web3 and gaming companies where community role affects support priority or SLA tier. The customer defines the picklist values during scoping.