Migrate from Jitbit Helpdesk to Salesforce Service Cloud

Jitbit Tickets map directly to Salesforce Cases. The ticket subject becomes Case Subject, the ticket body becomes Description, and the ticket status (New, Open, Pending, Resolved, Closed) maps to Salesforce Case Status values that we configure during schema setup. Custom statuses from Jitbit become Status or Reason picklist values on the Case object. Internal notes from Jitbit migrate to CaseComments or EmailMessages with IsPublished=false depending on the destination org's comment model.

Jitbit agents with login credentials map to Salesforce User records. We resolve by email match against the destination org's User table. Any Jitbit agent without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import. Customers (end users who submit tickets) map to Contact records attached to Account, not to Salesforce Users.

Jitbit end customers (users who create or are linked to tickets) migrate to Salesforce Contact records. We map the customer name, email, phone, and company association. If the Jitbit user has no company link, we create a default Account or place them under an existing matched Account by domain.

Jitbit Companies map to Salesforce Account. The company domain becomes the Account Website field and serves as the dedupe key during import. Account is created before any Contact import so that the AccountId Lookup relationship is satisfied at the moment of Contact insert. Parent-company hierarchies in Jitbit map to Account hierarchy in Salesforce where the destination org uses that feature.

Jitbit Categories define ticket routing and default assignment. We map category names to Salesforce Case Record Types (for business-line segmentation) or to a custom Category picklist field on Case (for lighter-weight mapping). The choice depends on how many distinct categories exist and whether the destination org needs separate page layouts per category. We flag this during scoping and implement per the customer's decision.

Jitbit tags are plain-text labels on tickets. Tags migrate to a Salesforce custom text field (Jitbit_Tags__c) on Case. If the destination org uses Salesforce Knowledge Data Categories, we evaluate mapping Jitbit tags to data categories for article routing consistency, though this requires manual category assignment post-migration.

Jitbit custom ticket fields (text, number, date, dropdown, checkbox, user reference) map to Salesforce custom fields on Case. Field types are matched to Salesforce equivalents: Jitbit dropdowns become picklists, checkboxes become checkboxes, user references become Contact or User lookups where applicable. Complex or conditional custom fields may require value normalization or a custom LWC component post-migration.

Jitbit Knowledge Base articles migrate to Salesforce Knowledge as KnowledgeArticleVersion records. Article title, body (HTML), category, and attachments transfer. We create the corresponding Salesforce Knowledge article type during schema setup and configure Data Category assignments to match Jitbit's category structure. Draft and published states migrate with their Jitbit status preserved.

Jitbit Assets (hardware and software inventory) map to Salesforce Asset records. Serial number, asset tag, assignment status, assigned user (mapped to Contact), and linked product all transfer. Asset-to-ticket associations from Jitbit migrate as CaseAssetRelation records or as a custom Asset_Linked__c lookup field on Case.

Jitbit canned responses migrate to Salesforce Quick Text records. Category association maps to QuickText Category. Note that Salesforce Quick Text is a standard Productivity feature available from Professional tier. Variable syntax differs between platforms and may require adjustment in the destination.

Jitbit subtickets are flattened into linked Case records. We create a parent Case record for the top-level ticket and child Case records for each subticket, linking them via a custom Parent_Case__c lookup field. The original subticket relationship is preserved as a tag on each child record.