Migrate from Jitbit Helpdesk to Zoho Desk

Jitbit Tickets migrate 1:1 to Zoho Desk Tickets with full activity history, internal notes, public comments, status transitions, and attachments preserved. We resolve the parent-child subticket relationship by flattening to linked tickets with a custom field jitbit_parent_id__c carrying the original Jitbit ticket ID for audit. Ticket priority, category assignment, and due date migrate to Zoho Desk Priority, Department (mapped from Jitbit Category), and Due Date respectively.

Jitbit agent and administrator accounts map to Zoho Desk Agents. We match by email address as the dedupe key. Roles (Admin, Agent) map to Zoho Desk Support Admin and Support Agent profiles. Group memberships from Jitbit map to Zoho Desk Departments and Teams. Deactivated Jitbit agents are held in a reconciliation queue; the customer chooses whether to import as inactive Zoho Desk agents or skip them.

Jitbit end-user accounts that created or received tickets map to Zoho Desk Contacts. The Contact's email, phone, name, and organization (if linked to a Jitbit Company) migrate. If the Jitbit user has no associated ticket history, we flag it for manual review during scoping.

Jitbit Companies (organizational records linked to Users) map to Zoho Desk Accounts. Company name becomes Account Name, domain becomes Website, and contact associations become Account-Contact relationships. Accounts are created before Contacts so that the AccountId Lookup is satisfied at Contact insert time.

Jitbit Categories define ticket routing and default assignment. We map each Jitbit Category to a Zoho Desk Department. Department creation must precede ticket import because Zoho Desk custom fields are department-scoped and the field layout must be assigned before custom field data can write. Category-based routing rules in Jitbit become Department assignment logic that the Zoho Desk admin configures post-migration.

Jitbit plain-text tags on tickets migrate to Zoho Desk Tags. We preserve tag-to-ticket associations during migration. Zoho Desk's Zwitch tool is documented to drop tags in some migration paths; we use Zoho Desk's REST API directly to write tags and maintain tag fidelity.

Jitbit custom fields (string, integer, decimal, checkbox, dropdown) map to Zoho Desk custom fields of equivalent type. Zoho Desk custom fields are department-specific, so we must identify which Zoho Desk Department each Jitbit ticket belongs to before writing custom field data. Conditional or formula-based custom fields in Jitbit require manual value computation and migration as static values; we flag these for the customer's admin to review post-migration.

Jitbit custom ticket statuses map to Zoho Desk status values within each Department's status model. We map open/closed semantics from Jitbit to Zoho Desk's Open, Pending, On-Hold, and Closed statuses. Custom status colors and icons do not transfer; these are set manually in Zoho Desk's layout editor.

Jitbit KB articles (structured HTML organized into categories) migrate to Zoho Desk Articles within the corresponding Department. We preserve article text, attachments, internal notes, and category assignments. Zoho Desk's Zwitch tool does not migrate KB article attachments; we extract attachments from Jitbit's storage and re-attach them via the Zoho Desk API to preserve original filenames. Articles with embedded images require URL rewriting to point to the re-hosted attachment URLs.

Jitbit Assets (hardware/software inventory records linked to Users and Tickets) migrate to Zoho Asset Management if the customer licenses it, or to a Zoho Creator custom Asset object if not. We preserve serial numbers, assignment history, and ticket associations as custom fields. Asset-to-User links map to Zoho Asset Management's Assignee relationship or Zoho Creator lookup fields. Jitbit's built-in asset module is a different data model from Zoho Desk's optional asset integration, so the destination strategy is confirmed during scoping.

Jitbit Canned Responses (per-category templated replies) migrate as Zoho Desk Email Templates and Macros. We transfer text content and category associations. Variable syntax differs between platforms: Jitbit uses {{ticket.property}} tokens while Zoho Desk uses ${ticket.fieldName} in Deluge. We flag variable mapping discrepancies and provide a rewrite reference table for the customer's admin to update templates post-migration.

Jitbit subtickets are a Jitbit-specific construct with no native Zoho Desk equivalent. We flatten subticket hierarchies into separate tickets and preserve the parent-child relationship as a custom field jitbit_parent_id__c on each child ticket. This allows agents to reconstruct the original hierarchy by querying tickets sharing the same jitbit_parent_id__c value. We do not create a native hierarchy in Zoho Desk because no such structure exists.

Ticket and KB article attachments are extracted from Jitbit's storage (SaaS blob storage or on-premise file share/SQL Server FILESTREAM) and re-attached to their target records in Zoho Desk via the API. Original filenames and MIME types are preserved. Attachments larger than 25 MB are chunked for upload per Zoho Desk API limits. Inline images embedded in KB article HTML are re-hosted and URLs rewritten in the article body.

Jitbit Automation Rules (if-this-then-that triggers on ticket events) are configuration artifacts stored in the application database and are not portable across platforms. We do not migrate them. We deliver a written inventory of every active Jitbit Automation Rule with its trigger event, conditions, and actions mapped to Zoho Desk equivalents (Blueprint stages, SLA policies, or Zoho Deluge custom functions). The customer's Zoho Desk admin rebuilds the routing logic post-migration based on this inventory.