Migrate from JOIN to Bullhorn ATS & CRM

JOIN Jobs map to Bullhorn JobOrder. We extract the full job record (title, description, department, location, employment type, posting status) and map it to the Bullhorn JobOrder standard fields. The Bullhorn JobOrder must be inserted before any Candidate or JobSubmission records because JobSubmission references JobOrderID as a foreign key. If the JOIN job posting has expired or is closed, we preserve the status and set JobOrder.isDeleted or isClosed accordingly.

JOIN Candidate records map directly to Bullhorn Candidate with contact info, work history, education, skills tags, and source attribution. The Candidate's current pipeline stage from JOIN migrates as a custom Candidate text field because Bullhorn's standard status values are scoped to JobSubmission rather than Candidate. We resolve Candidate duplicates by email dedupe before insert.

JOIN Applications (the join table linking a Candidate to a Job) map to Bullhorn JobSubmission. The mapping preserves applied date, referral source, and rejection or offer flags. JobSubmission is inserted after both JobOrder and Candidate are loaded so that JobOrderID and CandidateID foreign keys are satisfied. A rejection or offer on the JOIN Application maps to JobSubmission.status with the corresponding Bullhorn status value.

JOIN exposes no universal stage schema; each job carries its own stage sequence that varies by plan. We extract the full stage list per job during the scan phase and build a customer-specific mapping table. In Bullhorn, we scope stage values to the JobOrder's Sales Process and record type. Where JOIN has more stages than Bullhorn supports, we collapse intermediate stages and preserve the stage-entry date as a custom field on JobSubmission so no timing context is lost.

Structured interview evaluations from JOIN migrate as Bullhorn Note records attached to the JobSubmission or Candidate. Where the evaluation uses a rubric with numeric scores, we map each criterion to a custom Candidate field or JobSubmission custom field. Free-text feedback migrates as Note body text with the interviewer name and interview date in the Note title.

JOIN employer-defined custom fields on Jobs map to Bullhorn JobOrder custom fields. Bullhorn supports ~55 custom fields per entity. We detect all JOIN Job custom fields during the scan, validate the count against Bullhorn's limit, and flag any overflow to the customer for custom object design. Custom fields are created in Bullhorn via the Field Mappings admin panel before data load.

JOIN Candidate custom fields map to Bullhorn Candidate custom fields. Bullhorn's custom field limit per entity (~55 fields) may require a custom object or a JSON-serialised text block for fields exceeding the limit. We surface the full custom field schema at scoping, confirm the intended mapping with the customer, and create the destination fields before migration. Custom fields that cannot map to typed Bullhorn fields land as free-text custom properties and can be restructured post-migration.

Candidate resume files and supporting documents export from JOIN and upload to Bullhorn as Candidate resume files or ContentDocument records linked via ContentDocumentLink. JOIN file naming uses internal IDs that we normalise to CandidateName_JobTitle_Date during export to prevent filename collisions and ensure files are identifiable in Bullhorn. We validate each file uploads successfully before marking the Candidate record as complete.

JOIN Owners map to Bullhorn User records. We match by email address against the Bullhorn destination User table. Any JOIN Owner without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Migration cannot proceed past User reconciliation because User references are required on JobOrder, Candidate, and JobSubmission.

If JOIN stores employer company records separate from Jobs, those map to Bullhorn ClientCorporation. ClientCorporation is created before JobOrder when a client record exists in JOIN, providing the ClientCorporationID for the JobOrder foreign key. JOIN employer-branding data (company description, website, industry) maps to the corresponding ClientCorporation standard fields.

JOIN does not expose email threads, scheduled events, or interview activity through a documented API endpoint. We require the customer to export this data as a CSV from the JOIN dashboard before cutover. We ingest the CSV alongside the API extract, normalise the activity data (email body, event date, interviewer name), and attach each entry as a Bullhorn Note linked to the Candidate or JobSubmission. Stage-entry timestamps from JOIN also land as custom date fields on JobSubmission, preserving the original pipeline timing context.

JOIN's 250+ job board distribution network has no direct Bullhorn equivalent as a native feature. Bullhorn distributes job postings through its integrated job board connectors and the Bullhorn Marketplace (350+ partner integrations). We document each active JOIN job board posting as a JobOrder custom field or an external reference note so the customer's Bullhorn admin can re-enable distribution on the equivalent Bullhorn-integrated board at their preferred time.