Migrate from Jelly to Intercom

Jelly conversations map directly to Intercom conversations. The mapping preserves the full message thread with author, body, timestamp, and direction (inbound/outbound). The conversation subject is extracted from the first inbound message subject line in Jelly; if absent, a default subject is assigned at migration time. Conversation_created_at and conversation_updated_at carry the original Jelly timestamps to preserve the activity timeline in Intercom.

Individual messages within Jelly conversations map to Intercom conversation Parts. Author identity (agent or customer) and message body transfer cleanly. Internal notes in Jelly — messages visible only to teammates — map to Intercom's internal Part type so that the private context within threads is preserved. Author email resolves to an Intercom admin or contact record by email match.

A Jelly conversation is assigned to a single team member. We preserve the assignee as an Intercom conversation attribute. If the assignee email resolves to an existing Intercom teammate, the conversation is assigned directly; if not, the original assignee email is stored as a custom conversation attribute for the customer admin to resolve post-migration. Jelly has no formal user directory API, so the assignment resolution relies entirely on email matching against Intercom's teammate list.

Jelly has no formal user directory API — team members are identified by their email address and their assignment on conversations. We extract every distinct email address referenced in conversation assignments and look up matching Intercom admins by email. Any email address without a matching Intercom teammate is flagged in a reconciliation queue at scoping so the customer admin can provision accounts before the migration run. If a Jelly team member has no conversations or assignments, they will not appear in the migration data.

Jelly shared email addresses are the top-level container for conversations. Each Jelly address maps to a dedicated Intercom Inbox, which is the Intercom equivalent for routing and team assignment. If the customer has multiple Jelly addresses mapped to a single team in Jelly, we consolidate them into one Intercom Inbox with a routing rule at migration time. Jelly's $29/mo tier limits teams to 3 shared addresses; Royal Jelly removes the cap. We confirm address count against the Jelly plan during scoping.

Jelly supports conversation tagging but exposes no documented API for tags. We extract tags from IMAP message headers when IMAP credentials are provided at scoping, or from a customer-supplied manual export if available. Tags are mapped to Intercom Conversation Tags by exact name match. If IMAP access is not available, tags are documented as a gap and noted in the scope — the customer admin recreates the tag set in Intercom manually post-migration.

Jelly renders email attachments inline within conversations but exposes no attachment storage API. We attempt attachment recovery through the configured IMAP connection when credentials are available, as IMAP exposes attachments as separate MIME parts. Attachment recovery is explicitly scoped: if IMAP access is absent or does not expose the full attachment set, we document the gap and note that customer-supplied manual uploads are required for any missing files. Intercom's attachment API accepts files up to 10 MB per part.

Jelly does not maintain a standalone contact or user directory — contacts exist only as email senders within conversations. We create Intercom Contacts from every distinct customer email address found in Jelly conversation threads. The Contact email, name (from message headers), and any metadata present in Jelly message data transfer to Intercom. If Jelly customer data requires company-level grouping, we create Intercom Company records and associate Contacts during migration based on domain matching or a customer-supplied mapping.

Royal Jelly's Slack integration is a live notification bridge — it sends alerts to Slack channels when new Jelly conversations arrive. This is a streaming notification, not stored data with an exportable schema. We do not migrate Slack integration configuration. The customer admin rebuilds the notification routing in Intercom using Intercom's native Slack integration or a workflow Rule, which we document in the post-migration handoff inventory.

Enhanced Contacts, Stats and reporting, and Sent-mail sync are listed as forthcoming in Royal Jelly with no stable schema or delivery date. As unbuilt features, they have no migratable data. We explicitly exclude any field or object associated with these roadmap items from scope. If these features ship before a migration engagement, we re-evaluate at scoping.