Migrate from Rhino Support to Zoho Desk

Rhino Support Tickets map directly to Zoho Desk Tickets. Subject, description, status, priority, and assignee fields migrate 1:1 using the standard field API. We preserve the full conversation thread as Zoho Desk Comments with the isPublic flag set to true for customer-facing messages and false for internal agent notes. Custom fields on tickets require schema discovery before migration because their presence and data types vary by Rhino Support plan tier. We catalog all active custom fields, map field values to typed Zoho Desk custom fields where equivalents exist, and write unmapped values to a catch-all Notes field with a label noting the original field name for post-migration cleanup.

Rhino Support Customer records map to Zoho Desk Contacts. Email address serves as the dedupe key and unique identifier during import. First name, last name, phone, and company association migrate directly. If the customer's Rhino Support plan exposes a distinct Company object, we create the Zoho Desk Account first so the Contact-to-Account lookup is satisfied at insert time. Customers without an associated company in Rhino Support create standalone Contacts without an Account link.

Rhino Support Company records map to Zoho Desk Accounts. Company name becomes the Account Name; website, phone, and address fields migrate directly. Not all Rhino Support plan tiers expose a distinct Company object, so we evaluate the source schema during discovery. Where Company is not available, customer contact records carry organization context in a custom field and the customer decides whether to create Accounts post-migration or merge organizational data into Contacts.

Rhino Support Agent records map to Zoho Desk Agents using email as the matching and dedupe key. Display name, role name, and team membership associations migrate. Role names transfer as a custom field on the Zoho Desk Agent record because Zoho Desk uses department-based access control rather than flat role names. The customer's Zoho Desk admin assigns the migrated agent to the appropriate Department and configures permission profiles manually after migration.

Rhino Support Teams group agents for ticket routing and accountability. Zoho Desk does not use standalone Team objects; instead, it uses a Department structure where agents are assigned to a Department and SLAs, views, and escalation rules are scoped per Department. We map Rhino Support team names to Zoho Desk Department names during migration and note this as a configuration step that may require the customer's admin to set routing rules, escalation paths, and view filters per Department after migration.

Custom fields on Rhino Support tickets vary by plan and configuration. During discovery, we query the live source schema to enumerate all active custom field names, API names, and data types. Custom field values migrate to Zoho Desk custom fields of the matching type where equivalents exist. Where Zoho Desk lacks an equivalent custom field, values write to a catch-all internal Notes field prefixed with the original field name so the admin can identify and create the proper Zoho Desk field post-migration. We flag any date, datetime, or checkbox fields that require special handling due to format differences between platforms.

Rhino Support conversation messages map to Zoho Desk Comments on the parent Ticket. The isPublic flag on each message determines whether it lands as a customer-facing Comment or an internal Note in Zoho Desk. Author information migrates with a reference to the mapped Agent or Contact record. Timestamps on individual messages are preserved as the Comment creation date in Zoho Desk, but the original ticket creation timestamp may reset to the migration completion date depending on the Zoho Desk import path used. We document all original ticket creation timestamps separately for admin reference.

Ticket and conversation attachments migrate as file references where Rhino Support exposes a downloadable URL via API. Large attachments or file formats not accessible via API may require manual re-upload after migration. We flag any attachment exceeding the destination platform file size limits during scoping and note the maximum supported size per Zoho Desk file upload settings. The customer is responsible for re-attaching any files that cannot be retrieved programmatically from the source platform.

Tags applied to Rhino Support tickets for categorization migrate as Labels in Zoho Desk. We map tag names exactly as they appear in the source. Zoho Desk imposes a 50-character limit on label names; any tag exceeding this limit is truncated and flagged in the migration report with the full original tag name preserved in an internal field for post-migration rename.

Rhino Support does not expose a Knowledge Base API in its current documentation, and we cannot retrieve help center articles, canned responses, or public-facing FAQ content programmatically. This is flagged during scoping discovery. We recommend exporting articles manually from the Rhino Support admin panel where possible, or rebuilding content in Zoho Desk's Knowledge Base module post-migration using the ASAP plugin for embedding articles into web properties. KB migration is outside standard automated scope and requires manual intervention.

Rhino Support does not expose SLA configuration via documented endpoints. We cannot retrieve SLA definitions, first response targets, or resolution targets programmatically. We flag this during scoping and document the existence of any SLA policies in a written handoff so the customer's admin can recreate equivalent SLA policies in Zoho Desk under the Standard or Professional tier where SLA management is available.

Rhino Support does not expose workflow automations via documented API. Any routing rules, auto-assignment, trigger-based actions, or escalation logic built in Rhino Support cannot be retrieved programmatically. We shut down automations in the source system before cutover to prevent records from being modified after the migration window. We deliver a written inventory of all active workflows with their trigger conditions, actions, and a recommended Zoho Desk Blueprint or Macro equivalent for the customer's admin to rebuild post-migration.