Migrate from Jelly to Gorgias

Jelly Conversations map to Gorgias Tickets. Each thread of inbound and outbound messages becomes a single Ticket with the original subject preserved. We pull conversation history via IMAP (thread reconstruction from email headers) or Jelly-assisted export where available. Assignee state from Jelly migrates as the initial ticket assignee in Gorgias. Conversation open/resolved status maps to Gorgias Ticket state (open, pending, resolved, closed). Message timestamps are preserved as ticket created_at and updated_at, and individual message timestamps are stored in ticket events.

Jelly shared email addresses (the top-level container for conversations) map to Gorgias Email Channels under Settings > Channels. The Jelly address becomes the sending and receiving address in Gorgias. If Jelly has a per-address cap (3 addresses on Jelly tier, unlimited on Royal Jelly), we confirm the destination Gorgias plan accommodates the address count during scoping.

Jelly has no formal user directory API. Team members are identified by their email and conversation assignments. We extract unique agent emails from conversation assignee data and map them to Gorgias Agents by email match. The customer's admin provisions matching Agent accounts in Gorgias before migration. Any Jelly assignee without a corresponding Gorgias Agent account is held in a reconciliation queue for manual provisioning.

Jelly assigns each conversation to a single team member at a time. We preserve the assignee field as the initial Agent assignment on the migrated Gorgias Ticket. Gorgias supports reassignment post-migration without data impact. If a conversation was unassigned in Jelly, it imports as unassigned in Gorgias.

Jelly supports conversation tagging but exposes no API for tag retrieval. We extract tags from IMAP headers where the customer has used email-client-based tagging (Thunderbird, Apple Mail labels) that surface in IMAP flags. Tags stored purely in Jelly's internal UI and not reflected in IMAP headers are noted as a gap in the migration scope. All extracted tags migrate as Gorgias Ticket Tags; tags that cannot be extracted are listed as excluded in the migration report.

Jelly does not maintain a structured contact database separate from conversation threads. Customer data (name, email, phone if present in message headers) is extracted from the sender and recipient fields of migrated messages and mapped to Gorgias Customer objects. We use email address as the dedupe key. Any additional customer properties (language, timezone) are preserved as custom fields if present in Jelly's export, otherwise they are noted as a gap requiring enrichment post-migration.

Jelly renders email attachments inline within conversations but exposes no attachment storage API. We assess IMAP access during scoping: if the customer has an IMAP connection to the underlying mailbox, we attempt to pull attachments from the IMAP server alongside the message text. However, Jelly-specific attachment references (stored in Jelly's own blob storage, not the IMAP server) cannot be recovered without direct Jelly cooperation. We include an explicit attachment recovery assessment in every outbound Jelly migration estimate, noting whether full recovery is confirmed, partial, or not possible.

Enhanced Contacts is listed as a forthcoming Royal Jelly feature and has not shipped as of the migration date. It has no stable schema, no API endpoint, and no data to extract. We exclude it from migration scope and flag it in the pre-migration report. If it lands before migration, we will reassess at scoping.

Stats and reporting are listed as forthcoming in Royal Jelly. Aggregated analytics are not migratable data objects; there is no underlying record to extract. We do not include this in scope. Post-migration, Gorgias provides native reporting that replaces any reporting Jelly may eventually ship.

Sent-mail sync is listed as forthcoming in Royal Jelly and has no stable schema. Outbound messages sent from Jelly (stored in Jelly's own sent-mail view) have no exportable API path. We flag this as a limitation and note that Gorgias's own email channel logs will capture outgoing messages from the point of cutover onward.

Royal Jelly's Slack integration is a live notification bridge that alerts a Slack channel when a new Jelly conversation opens. It does not store notification history as a migratable object. We do not migrate Slack integration configuration. Post-migration, Gorgias has its own Slack integration that the customer's admin configures separately in Gorgias Settings > Integrations.

Jelly does not support custom fields on conversations or customers. Any structured data the customer has manually added to Jelly (for example, order IDs pasted in conversation notes, or team-specific statuses tracked in external spreadsheets) does not have a native Jelly field to migrate. We document these data elements during scoping and advise the customer to create equivalent custom fields in Gorgias (Settings > Custom Fields) before migration, then we map the data into those fields during the import phase.