Migrate from Jitbit Helpdesk to Zendesk

Jitbit Tickets migrate to Zendesk Tickets with the full activity log including public replies, internal notes, and status transitions preserved as Ticket Comments. Attachments extract from Jitbit's file storage and re-attach to the corresponding Zendesk Ticket Comment via the Zendesk Attachments API. The original Jitbit Ticket ID is stored in a custom field zendesk_ticket_jitbit_id__c for cross-reference. Custom field values migrate to Zendesk ticket fields of equivalent type. We map Jitbit's Priority field to Zendesk Priority (low, normal, high, urgent). On Zendesk Growth and above, we also create corresponding Comment records for each Jitbit public or private note to preserve the internal discussion thread. Jitbit's date-created and date-modified timestamps are preserved on the Zendesk Ticket via the created_at and updated_at fields. Zendesk SaaS API rate limits (30/min on Growth, 180/min on Enterprise) govern our chunking strategy; we use the Bulk API for large ticket batches (over 5,000 records) with batch monitoring and retry on partial failures.

Jitbit Users split into Zendesk Agents (agent flag = true) and End Users (agent flag = false). Agents receive role assignments (admin, agent, light agent) based on Jitbit role mapping collected during discovery. Group memberships from Jitbit map to Zendesk Groups, and agents are assigned to Groups via the Zendesk Members API. End Users become Zendesk End Users and serve as Ticket Requesters. Email address is the dedupe key for both agent and end user records. Deactivated Jitbit users are imported as inactive Zendesk users with the any? active flag set to false, preventing orphaned ticket assignments. We flag any Jitbit user without an email address for manual resolution before migration, as Zendesk requires an email for End Users.

Jitbit Categories migrate to Zendesk Views as filtered ticket queues. Each Jitbit Category name maps to a Zendesk View with a condition set matching the Jitbit category assignment. In Jitbit, categories also define default agent assignment and email routing — we capture these as View conditions and note the agent assignment for Zendesk Trigger recreation. Note that Zendesk Views are read-only filter objects and do not have a default agent action; agent assignment is handled by Zendesk Triggers post-migration. Multiple Jitbit categories with overlapping names are disambiguated during scoping to prevent View name collisions at the destination.

Tags migrate directly from Jitbit to Zendesk as plain-text labels on Tickets. The tag-to-ticket associations are preserved during import via the Zendesk Tags API. We flag any tag containing characters that Zendesk does not support (e.g., unicode emoji outside the BMP) for manual normalization before import. Jitbit's tag limit per ticket is unlimited; Zendesk has a practical limit of approximately 200 tags per ticket which covers virtually all production cases.

Jitbit custom field types (text, date, dropdown, checkbox, number, address, multiselect) map to Zendesk Ticket Field types of equivalent semantics. Text maps to text, date maps to date, dropdown maps to tagger (a dropdown referencing a Zendesk field option), checkbox maps to checkbox (boolean), number maps to integer, and address maps to text with a note that geolocation autocomplete does not transfer. Multiselect dropdown migrates as a tagger field with multiple option selections. Jitbit's per-category field assignments require manual configuration in Zendesk because Zendesk ticket field visibility is controlled by the ticket form, not by category. We document all custom field names, types, and the categories they apply to so the Zendesk admin can configure field visibility on the appropriate ticket forms post-migration.

Jitbit custom ticket statuses migrate to Zendesk Custom Ticket Statuses (available on Suite Growth and above). Each custom status's open/closed semantics map to the Zendesk status category (open, pending, solved, closed). The Jitbit status color and display name transfer where Zendesk's custom status API allows. On Zendesk Suite Team (the entry tier), custom statuses are not available — in that case, we map Jitbit custom statuses to the nearest standard Zendesk status (e.g., 'Waiting for Vendor' maps to 'Pending') and document the discrepancy for the admin. This tier constraint is surfaced during scoping so the customer can confirm their Zendesk plan supports custom statuses before migration.

Jitbit Knowledge Base articles migrate to Zendesk Guide articles. The full HTML content (including embedded images, tables, and formatting) transfers and is rendered in Zendesk Guide's article editor. Jitbit KB categories map to Zendesk Guide Sections; we create the target Section hierarchy in Zendesk Guide before article import so that section assignments are valid at insert time. Article metadata (author, creation date, last modified date) is preserved. Attachments within KB articles extract from Jitbit storage and re-upload to Zendesk Guide via the article attachments endpoint. Draft vs published status maps from Jitbit's article visibility setting. Jitbit article views, votes, and feedback scores are not natively supported in Zendesk Guide and are stored in custom article fields for optional reporting.

Asset migration requires a pre-migration decision on the target schema. If the destination Zendesk account is on Support Plus or Enterprise Suite, or has a Sunshine Assets add-on, assets migrate to the native Zendesk Assets object with full record type support, serial number, assignment, and ticket links preserved. If native Assets are not available on the plan, we import Jitbit Assets as Organizations with custom fields for serial number, asset type, purchase date, and assigned user — this preserves the asset record and user association but requires admin acknowledgment of the non-native schema. The customer's Zendesk plan tier is confirmed during scoping before the asset migration path is locked.

Jitbit Company records migrate to Zendesk Organizations. The Company name becomes the Organization name, the domain field maps to Organization domain, and any contact associations become Organization Membership records via the Zendesk Organization Membership API. Companies without any associated users are imported as standalone Organizations with a note for the admin to link relevant End Users manually. The existing Jitbit user-to-company linking relationships are resolved during the User import phase, ensuring that Organization Membership records are created after both Users and Organizations exist in Zendesk.

Jitbit Canned Responses per category migrate to Zendesk Macros as personal or shared templates. The response text transfers, and the target macro category maps to the Zendesk macro folder structure. Variable syntax differs significantly: Jitbit uses [[ticket.field_name]] notation while Zendesk uses {{ticket.field_name}} and {{ticket.requester.name}} notation. We perform a syntax conversion during migration and flag any non-convertible variables (e.g., Jitbit-only system fields) in the macro handoff document. Formatting (HTML in Jitbit) converts to Zendesk's editor format on macro import.

Jitbit Subtickets represent parent-child ticket hierarchies that have no direct Zendesk equivalent. We flatten subticket hierarchies by creating separate Ticket records in Zendesk for each subticket and preserving the parent relationship via a custom field jitbit_parent_id__c on each child ticket. The parent ticket ID from Jitbit is stored in this custom field so that the relationship is queryable. If the team requires a visual parent-child view, we recommend a Zendesk Views filter using the jitbit_parent_id__c field to surface linked tickets together. This approach avoids creating orphan tickets while maintaining the relationship data for reporting and audit purposes.