Migrate from Yuma AI to HubSpot Service Hub

HubSpot Service Hub Tickets are the destination record type for every migrated support ticket. We pull the full ticket body, metadata (created date, updated date, status, priority, source channel), and all custom field values from the host helpdesk via its API. Resolution status flags that Yuma wrote into the ticket thread are preserved as Yuma-resolution tags on the Ticket record. Custom ticket fields (order ID, return reason, subscription tier) are mapped to HubSpot's custom ticket properties or, if no equivalent exists, added as custom ticket properties before migration.

Yuma reads customer profiles from the host helpdesk: name, email, phone, order history, and contact records. We migrate all Customer fields to HubSpot Contact and, where company-level data exists (e.g., Zendesk Organizations), to HubSpot Company. The Contact receives the full customer field map; the Company receives organizational data if present. If the host helpdesk had separate Contact and Company objects, we preserve both and create the HubSpot link between them.

Every message in a Yuma-ticket thread migrates as a HubSpot Conversation entry on the associated Ticket. We tag each message with a source flag indicating whether it was authored by a Yuma Auto-Pilot or a human agent. This author attribution is preserved as a private internal note on each conversation entry so HubSpot's Breeze AI can use it as a training signal for agent assist and future auto-reply capability. Plain-text messages, rich-text bodies, and quoted parent messages migrate directly. Inline images that are stored as URLs are preserved as links; actual image blob storage follows the HubSpot inline-image limitation (see Gotchas).

Inline attachments on tickets (images, PDFs, order screenshots, shipping documents) are transferred via the host helpdesk API attachment endpoint. Yuma does not maintain its own attachment blob — we pull directly from the host platform. HubSpot Service Hub supports ticket attachments; we map each attachment to the corresponding migrated Ticket. Large attachment batches are chunked to stay within HubSpot API rate limits during import.

Yuma applies internal tags during processing (e.g., resolution type, automation status, channel, language). We export all Yuma-applied tags alongside each Ticket and map them to HubSpot ticket tags. Tags used for classification (WISMO, refund, return, subscription) are also written to a custom ticket property yuma_resolution_type__c so that reporting in HubSpot can replicate any segmentation logic Yuma used.

Human agents who responded to tickets in the host helpdesk are mapped to HubSpot User records by email address. We extract the agent's name, email, and role. If a HubSpot User with the matching email does not yet exist, we flag it for the customer's admin to provision before the migration runs; FlitStack AI does not create User records without admin authorization.

Yuma's Auto-Pilot agents are a logical configuration layer that routes ticket types to specific AI behaviours and escalation rules. These have no direct HubSpot equivalent in their current form. We export Auto-Pilot agent configs as structured JSON including channel assignments, escalation triggers, and routing conditions. The customer uses this JSON as the specification for rebuilding equivalent Breeze AI agent behaviour in HubSpot Service Hub post-migration.

Yuma routes edge-case tickets to human teams based on rules configured in Flows. We map team assignments to HubSpot's Team structure and, where applicable, to ticket assignment rules or pipeline queues. Any Yuma teams that exist only within a Flow (without a corresponding host-helpdesk team definition) are flagged as orphaned and documented for the customer to recreate in HubSpot manually.

Yuma respects and populates custom fields defined in the host helpdesk (order ID, return reason, subscription tier, discount code, etc.). We preserve all custom field values at migration time and create equivalent custom ticket properties in HubSpot Service Hub before import. Field types are mapped: text fields to single-line text, dropdowns to single-select picklist, multi-select to multi-select picklist, dates to date picker.

Yuma reads from the host helpdesk's knowledge base at inference time but does not own KB articles. We migrate the knowledge base from the host platform directly to HubSpot Knowledge Base using HubSpot's built-in importer. Article categories map to HubSpot Knowledge Base sections and categories. Yuma's knowledge constraints are not transferred as they are Yuma-specific; the customer reviews which articles are published in HubSpot after import.

Guidelines are Yuma's brand policy rules that constrain AI behaviour. They export as structured JSON with condition-action pairs, channel constraints, tone rules, and allowed deflection actions. HubSpot Breeze AI agents support instruction-based configuration but do not accept a Yuma Guidelines import. We deliver the Guidelines JSON with a written map to HubSpot Breeze Agent builder fields so the customer's admin can re-enter them as agent instructions manually. This is scoped as a separate workstream outside the data migration.

Flows are Yuma's visual workflow builder for ticket routing, triggers, and escalation sequences. We export Flow definitions as JSON including trigger conditions, branch logic, delay timers, and escalation actions. HubSpot Workflows use a different trigger model (record-triggered, form-based, contact-property-based) and do not accept a Yuma Flow import. We deliver a written inventory of every active Yuma Flow with its trigger, conditions, actions, and a recommended HubSpot Workflow equivalent. The customer's admin or a HubSpot partner rebuilds them post-migration.