Migrate from JazzHR to Bullhorn ATS & CRM

JazzHR Jobs map directly to Bullhorn JobOrder. We preserve title, location, description, salary range (mapped to payRate or salary fields), status (published/draft/closed mapped to Bullhorn status constants), and the job's department assignment. The Bullhorn JobOrder is created before any Candidate or JobSubmission records to satisfy the JobOrderID lookup dependency. Job board codes identifying where postings were syndicated (Indeed, LinkedIn, ZipRecruiter) are stored as a Bullhorn custom text field for admin reference.

JazzHR Candidate profiles (name, email, phone, address, work history, education with codified educationLevelCodes) map directly to Bullhorn Candidate. Education records from JazzHR map to Bullhorn Candidate.education and Candidate.certifications. The startDate custom field on JazzHR maps to a Bullhorn custom date field. Bullhorn Candidate is the parent entity for all JobSubmission records, so it must be imported before Prospects resolution.

JazzHR Prospects are the join table between Candidates and Jobs, carrying status, source, referral, and apply date. This is the most critical mapping in the migration because Bullhorn models the same association as JobSubmission with CandidateID and JobOrderID lookups. We resolve prospect status to Bullhorn JobSubmission status constants (New, Interview, Offer, etc.) and preserve the original applyDate. If a JazzHR candidate has applied to multiple jobs, each application produces a separate Bullhorn JobSubmission record.

JazzHR Departments migrate to Bullhorn Department. The department taxonomy is a dependency for JobOrder assignment, so we migrate departments first and validate department counts in Bullhorn before creating JobOrder records. Any JobOrder in JazzHR assigned to a department without a Bullhorn equivalent is held in a reconciliation queue.

Every JazzHR job carries a hiring_lead_id referencing a user. We extract all hiring leads, match them by email to Bullhorn User records, and remap the reference. Bullhorn User must be provisioned before JobOrder creation so that the owning user is assigned at migration time. Any hiring lead without a Bullhorn User match goes to a reconciliation queue for the customer to provision the account.

JazzHR document attachments are delivered as base64-encoded blobs with MIME type via the Candidate Export Webhook. We stream these immediately upon receipt—Bullhorn does not receive document URLs that expire before we can act on them. The 2.5-hour window from JazzHR means we begin document extraction concurrently with candidate record extraction rather than in a separate phase. Documents attach to the Bullhorn Candidate record as Attachments with the original filename and MIME type preserved.

JazzHR custom fields on candidate profiles map to Bullhorn custom fields on the Candidate entity. We evaluate field type compatibility during scoping: Bullhorn picklist fields require value mapping from JazzHR free-text or enumerated values, date fields preserve YYYY-MM-DD formatting, and number fields migrate directly. The JazzHR startDate custom field uses a camelCase key and specific date format that we validate before creating the Bullhorn equivalent.

JazzHR workflow stages map to Bullhorn Record Types and Sales Process stage values. We create a Bullhorn Record Type per JazzHR workflow, with the Sales Process defining the stage whitelist for that job category. JazzHR's custom workflow IDs (workflow_id) are preserved as a reference field in Bullhorn. Stage probability percentages from JazzHR do not map to Bullhorn directly—Bullhorn stage weights are managed differently—but we document them for the admin to configure post-migration.

JazzHR stores source and referral as free-text or codified strings on the Prospect record. Bullhorn does not have a native equivalent for candidate sourcing attribution. We preserve both fields as Bullhorn custom text fields on Candidate (candidateSource and candidateReferral) so that source attribution data is available for reporting without re-keying.

Each JazzHR job carries board codes identifying syndication targets (Indeed, LinkedIn, ZipRecruiter, Glassdoor, etc.). Bullhorn does not natively recreate job board connections during migration. We store the active board code list as a Bullhorn custom multi-select picklist on JobOrder so the admin knows which boards were previously connected and can re-establish them post-migration.

JazzHR does not have a native client relationship management object; client context lives implicitly in the job's hiring lead and job description. Bullhorn's ClientCorporation allows agencies to track client relationships separately from job postings. We flag this as a candidate for post-migration data cleanup: if the customer had informal client data in JazzHR job descriptions, we surface it as a migration inventory item for manual entry into Bullhorn ClientCorporation. This is not an automated mapping but a documented gap requiring admin action.

JazzHR does not have a dedicated Placement object. Historical hiring outcomes for filled roles are implicit in closed Job records and the candidate's final Prospect status. Bullhorn Placement objects track placed candidates, start dates, pay rates, and commission data. For JazzHR migrations with a history of closed jobs and successful hires, we flag the corresponding candidates for Bullhorn Placement record creation as a post-migration manual step rather than inferring placements from implicit data.