Migrate from Jelly to HubSpot Service Hub

Jelly Conversation threads map to HubSpot Tickets. Each thread of inbound and outbound messages on a shared address becomes a single Ticket with the thread history preserved in the Ticket's conversation feed. The HubSpot Ticket subject, status, priority, and pipeline assignment are derived from Jelly's conversation metadata. If Jelly's IMAP export exposes timestamps and participant email addresses, these map to HubSpot's hs_ticket_create_date and the contact's email for association.

Jelly's shared email addresses are the top-level container for all conversations. We map each Jelly address to a HubSpot Shared Inbox of the same address. The Jelly $29/month plan caps at 3 addresses; Royal Jelly removes the cap. If the customer's Jelly plan limits address count, we confirm the target HubSpot Service Hub tier supports the required number of shared inboxes (Starter supports 5, Professional 50, Enterprise 200).

Jelly has no formal user directory API. Team members are identified by their email and conversation assignments. We extract every distinct agent email from Jelly conversations and resolve against HubSpot Users by email match. Any Jelly assignee without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision before production migration. Assignees that cannot be resolved are stored as a custom Ticket property original_assignee for manual distribution post-migration.

Jelly conversations support single-agent assignment. We map the assignee to HubSpot Ticket OwnerId where a resolved User exists. If the assignee is unresolvable, we store the original Jelly assignee email as a custom Ticket property jelly_original_assignee__c and flag it in the migration report for manual reassignment.

Jelly supports conversation tagging but exposes no tags API. We extract tags from IMAP headers when available or from any customer-supplied CSV export. Tags that cannot be retrieved are documented as a data gap in the migration report. Recoverable tags migrate to a HubSpot multi-select picklist on Ticket.

Jelly renders email attachments inline within conversations but exposes no attachment storage endpoint. If IMAP access is configured on the Jelly side, we attempt to pull attachments from the IMAP server and re-upload them as HubSpot File records linked to the parent Ticket via ContentDocumentLink. If IMAP access is unavailable, attachments are documented as a data gap and the customer's admin decides whether manual re-upload post-migration is acceptable.

Jelly does not maintain a contact database; contacts are derived from the sender and recipient email addresses in conversations. We extract distinct customer email addresses from Jelly conversation threads and map them to HubSpot Contacts. Each Contact is created or matched by email address, preserving the most recent message timestamp as the contact's last_contact property. Jelly has no contact custom fields, so the mapping is straightforward email-to-contact with no field transformation required.

Jelly does not store company records. If the customer can supply a company-domain mapping (which contacts belong to which accounts), we merge those into HubSpot Companies and link contacts via the domain match or a customer-supplied mapping file. If no mapping exists, contacts migrate without a Company association and the customer's admin adds these post-migration or through HubSpot's company-domain detection.

Royal Jelly's Slack integration is a live notification bridge that posts new conversation alerts to a Slack channel. This is an active webhook configuration, not stored data. We do not migrate webhook endpoints. The customer's admin recreates Slack notifications in HubSpot using HubSpot's native Slack integration or a custom workflow webhook. We document the original Slack channel and alert trigger conditions in the migration report for reference.

Enhanced Contacts is listed as forthcoming in Royal Jelly and has no stable schema at this time. We do not migrate it. Any contact data the customer intended to manage in Jelly Enhanced Contacts should be evaluated for migration directly into HubSpot Contacts with custom properties. This is scoped separately during pre-flight.

Aggregated analytics are not migratable data objects. Jelly's historical reporting data (if any exists in the platform) has no structured export path. We recommend rebuilding support reporting in HubSpot Service Hub using Ticket data that migrates from conversations. We document the key metrics Jelly may have tracked (reply time, resolution rate, conversation count by address) as a reference for the customer's HubSpot reporting setup.

Jelly does not expose automation or routing rules as structured data. Any rules or conventions the team uses for conversation assignment, tagging, or escalation are documented in the migration report as a manual handoff for the customer to rebuild in HubSpot Service Automation or Playbooks. We do not migrate automations as code.