Migrate your Jelly data

Conversations are the core object in Jelly — flat threads of inbound and outbound messages on a shared address. We map threads to the destination's equivalent (Tickets, Threads, Messages) and preserve the last-assigned owner state. No custom conversation fields exist, so no field mapping is required.

Shared email addresses are the top-level container for conversations. The Jelly tier limits how many addresses are allowed; Royal Jelly lifts this to unlimited. We migrate the address itself and associate all related conversations to it at the destination.

Jelly has no formal user directory API. Team members are identified by their email and conversation assignments. We map them to Users or Agents at the destination and flag any unresolvable email addresses for manual review.

A Jelly conversation can be assigned to a single team member at a time. We preserve the assignee field as a custom property at the destination when the target does not have native assignment on conversation objects.

Jelly supports tagging conversations but does not expose tags via any documented API. We extract tags from IMAP headers or customer-supplied exports where available, otherwise tags are noted as a gap in the migration scope.

Royal Jelly's Slack integration notifies channels of new conversations. This is a live notification bridge, not stored data, and has no exportable schema. We do not migrate Slack integration configuration.

Enhanced Contacts is listed as a forthcoming feature in Royal Jelly. As it is not yet shipped, we do not support it as a migration target. It may land as a simple contact card with no custom fields.

Stats and reporting are listed as forthcoming in Royal Jelly. Aggregated analytics are not a migratable data object and are excluded from scope.

Jelly surfaces email attachments inline within conversations. The platform does not expose an attachment storage API, and we have not found a documented attachment export path in any published endpoint or customer-accessible feature.