Migrate from Jelly to Zendesk

Jelly Conversations map to Zendesk Tickets. Each shared-address thread becomes a single Ticket with the original message as the first Comment and all subsequent replies as chained Comments. The Zendesk Ticket subject uses the Jelly conversation subject; the requester email resolves to a Zendesk End User. Conversation creation timestamp migrates as the Ticket created_at date. We pull via IMAP when Jelly API access is unavailable, extracting message_from, message_to, date, and body fields and reconstructing the thread by sorting on date and message_id references.

Each Jelly shared email address maps to a Zendesk Inbox (an email channel) connected to a Request Form. The Request Form defines which fields appear to the customer on submission; the Inbox defines routing, agent assignment, and channel settings. We preserve the Jelly address as the Zendesk channel address and configure it as the reply-to for that inbox. If Jelly is on the $29/month tier with 3-address cap and the customer uses more addresses, we flag this during scoping and recommend upgrading to Royal Jelly or consolidating addresses before migration.

Jelly has no formal user directory API. Team members are identified by their email address and conversation assignments. We resolve Jelly team members to Zendesk Agent accounts by email match, creating the Zendesk User record if one does not already exist. Any Jelly team member email that cannot be matched to a Zendesk User goes to a reconciliation queue; the customer provisions the missing Agent before record import resumes.

Jelly supports single-agent assignment per conversation. We map the Jelly assignee to Zendesk's native Assignee field on Ticket, resolving by email to the corresponding Zendesk Agent. If the Jelly assignee has not been provisioned in Zendesk, we hold the assignment in a custom field jelly_original_assignee__c and restore it post-provisioning.

Jelly tags are applied to conversations but are not exposed via any documented API. We attempt to extract tags from IMAP headers (X-Label, X-Keywords) if the customer's IMAP connection exposes them, or from any customer-supplied export file. Where tags are recoverable, we create corresponding Zendesk Tags and apply them to the migrated Tickets. Tags that cannot be extracted from IMAP or a customer export are documented as a gap in the migration summary; we do not infer or fabricate tag data.

Jelly surfaces email attachments inline within conversations but exposes no attachment storage API. We assess IMAP access during scoping; if the underlying IMAP connection is configured for the shared mailbox, we retrieve attachments from the IMAP server and attach them to the corresponding Zendesk Ticket. Attachments that cannot be reached via IMAP (no IMAP configured or attachments stored only in Jelly's rendering layer) are documented as a gap. This is a pair-specific high-severity gotcha: without IMAP access, attachment recovery is not possible through any documented path.

Royal Jelly's Slack integration is a live notification bridge that posts to Slack channels when new conversations arrive in Jelly. This is a streaming notification with no stored schema and no export path. We do not migrate Slack integration configuration. We document the existing Slack channels, notification triggers, and message format in the configuration inventory so the customer's admin can recreate equivalent Notification Rules in Zendesk's Slack integration or a third-party tool like Zapier.

Enhanced Contacts is listed as a forthcoming feature in Royal Jelly. As it has not shipped, there is no stable schema, no API endpoint, and no migratable data. We explicitly exclude it from migration scope. If it lands before migration, we assess its schema at that point. The current Jelly contact model is email-address-based with no structured contact card, which maps to Zendesk End Users or Organizations if the customer groups by company.

Stats and reporting are listed as forthcoming in Royal Jelly. Aggregated analytics—response time averages, resolution rates, conversation volumes—are reporting-layer data that does not exist as structured records in Jelly. We do not migrate analytics. Post-migration, the customer builds Zendesk's native reporting from the newly migrated ticket history; historical Jelly reporting (to the extent it exists in Royal Jelly) has no migration path and starts fresh in Zendesk.

Jelly has no native organization or company concept—conversations are grouped by shared address and assignee, not by the requester's company. If the customer wants Zendesk Organizations, we propose a domain-based grouping strategy: all requesters sharing the same email domain become a Zendesk Organization. This is a scoping decision made with the customer; we implement the agreed grouping logic during migration.