Migrate from Rhino Support to HubSpot Service Hub

Rhino Support tickets map directly to HubSpot Service Hub tickets. Standard fields including subject, description, status, priority, and assignee transfer as HubSpot ticket properties. Ticket ID from Rhino is preserved in a custom property hs_rhino_ticket_id__c for reconciliation and cross-reference during the audit window. Closed tickets migrate with their resolved_at timestamp intact so that the ticket lifecycle history is accurate in HubSpot.

Rhino Support customer records map to HubSpot Contact. Customer email address serves as the unique identifier and dedupe key during import. Name, phone, and company association migrate to the corresponding HubSpot Contact properties. Where a Rhino Support customer record has no email, we create the Contact with available fields and flag the record for manual email enrichment post-migration.

Rhino Support company records map to HubSpot Company. Not all Rhino Support plans expose a distinct Company object, so we evaluate the live schema during discovery. Where company data exists, it migrates as HubSpot Company with domain and description preserved. Company is created before Contact import so that the Contact-to-Company association is resolved at insert time rather than patched afterward.

Rhino Support agent records map to HubSpot User. We resolve agents by email match against the destination HubSpot portal. Any Rhino Support agent without a matching HubSpot User is held in a reconciliation queue; the customer's HubSpot admin provisions the missing User before record migration resumes. Agent display name and role membership migrate as user properties for permission reconstruction post-migration.

Rhino Support team structures map to HubSpot Teams. Team membership is preserved as a property on the migrated User records so that the customer's admin can assign HubSpot role-based access and ticket routing rules post-migration. HubSpot Teams do not have a standalone API object in the same way Rhino does, so team structures are mapped as a naming convention and user-group association.

Rhino Support ticket conversation messages migrate to HubSpot ticket conversation threads. Each message record includes author information, timestamp, and a visibility flag indicating whether the message is internal-only or customer-facing. We preserve that flag in HubSpot so internal notes remain internal to agents and do not appear in customer-facing ticket views. Message body migrates as rich text with any inline images preserved as attachments.

Rhino Support custom fields on tickets vary by plan and configuration. We catalog all active custom field names and data types during discovery. Where HubSpot Service Hub supports an equivalent custom ticket property type, we map field values directly. Where no equivalent exists, we write values to a catch-all text property rhino_custom_fields__c and flag the customer to create the proper custom property in HubSpot post-migration.

File attachments on Rhino Support tickets and conversations migrate as HubSpot Files attached via ContentDocumentLink to the parent ticket record. Large attachments or file formats not accessible via Rhino Support API may require manual re-upload after migration. We flag any inaccessible attachments during the discovery phase and note them in the migration inventory for customer review.

Rhino Support tags applied to tickets for categorization migrate as HubSpot Ticket Labels. We map tag names exactly and note any tag-length or character restrictions in the destination system. If the customer uses tags as a primary routing mechanism in Rhino Support, we recommend converting tags to HubSpot custom properties or workflow enrollment criteria during the post-migration configuration phase.

Rhino Support inbox configurations map to HubSpot Inboxes within Service Hub. Email addresses, shared inbox routing, and channel connections (email, chat, Facebook, WhatsApp) require manual reconfiguration in HubSpot post-migration since channel integration credentials cannot be migrated. We document the source inbox settings during discovery so the customer's admin has a configuration reference.

Rhino Support does not expose a documented Knowledge Base API, so help-center articles, canned responses, and public-facing FAQ content cannot be retrieved programmatically. We flag this as a migration gap during scoping and advise the customer to export articles manually via the Rhino Support admin panel or rebuild them post-migration using HubSpot's Knowledge Base API. This is a content gap that requires manual intervention and is documented in the migration inventory as an out-of-scope item.

Rhino Support does not expose workflow automations via documented endpoints, and HubSpot Service Hub workflows use a trigger-action model with no migration path from Rhino. We deliver a written inventory of any observable routing rules, assignment logic, or notification configurations identified during discovery. The customer's admin rebuilds these as HubSpot Workflows post-migration using HubSpot's visual workflow builder.