Migrate from Bullhorn Connexys ATS to Recruit CRM & ATS

Bullhorn Candidate records map to Recruit CRM Candidates with full field coverage for name, email, phone, resume (parsed or raw file), work history, skills, salary expectations, and tax information. We preserve GDPR consent flags in a custom consent_date and consent_source field on the Candidate record. Resume files export via Bullhorn REST API and import as attachments to the corresponding Recruit CRM Candidate; large volumes require chunking across multiple API windows to stay within the 100,000 monthly call ceiling.

Bullhorn JobOrders map to Recruit CRM Jobs. Standard job fields (title, description, requirements, salary range, location, status) migrate directly. Custom job fields map to Recruit CRM custom fields on the Job record. We resolve the owning Recruiter (User) reference by email match against Recruit CRM users before import so that the assignment is live at insert time rather than patched afterward.

Bullhorn Accounts map to Recruit CRM Clients. Billing address, industry classification, client tier, and contact associations migrate directly. Bullhorn supports multiple contacts per Account; we map these to Recruit CRM Client records with their associated Contact records linked via the Client-Contact relationship. The Account's primary billing contact maps to the Client's primary contact field.

Bullhorn Contact records map to Recruit CRM Contacts with full name, email, phone, title, and department fields preserved. We preserve the link between Contact and the parent Client (Bullhorn Account) by resolving the Client ID at migration time. Custom Contact fields map to Recruit CRM Contact custom fields; any fields exceeding Recruit CRM's field length or type constraints are flagged for truncation or type conversion during the transform phase.

Bullhorn Placements map to Recruit CRM Placements, capturing the hire outcome linking Candidate to Job and recording start date, end date, salary, and placement status. We preserve the links to both the Candidate record and the Job record by resolving the respective IDs at migration time. Placement history and status transitions migrate as a text audit log entry on the Placement record because Recruit CRM tracks stage history through its activity log rather than a separate junction object.

Bullhorn Custom Objects (up to 10 on Front Office Growth/Enterprise; 2 on Bullhorn ATS, each with up to 55 fields) require a schema redesign for Recruit CRM, which does not have a separate Custom Object construct. We map each Custom Object to a set of custom fields on the primary entity it extends (Candidate, Contact, Client, or Job). Fields that cannot fit within Recruit CRM's field-per-entity limits are flagged for explicit customer decision: either split across related entities or left as a manual re-entry item in a shared spreadsheet. Custom Object relationships to other entities migrate as ID reference fields or multi-select lookups where Recruit CRM supports them.

Bullhorn User records map to Recruit CRM users by email match. Bullhorn's OwnerId references on Candidate, Job, Contact, and Placement records resolve to the corresponding Recruit CRM user at migration time. Any Bullhorn User without a matching Recruit CRM user is held in a reconciliation queue for the customer's admin to provision before that phase of migration resumes. Inactive Bullhorn users migrate as inactive Recruit CRM users with a flag indicating their historical ownership of records.

Bullhorn resume files and attachments export via the REST API. Because Bullhorn's API rate limit of 100,000 calls per month constrains bulk attachment retrieval, we chunk attachment exports into batches of 500 files and schedule them across off-peak windows. Large files (over 10 MB) are flagged for the customer to export manually if needed. Resume text parsed by Bullhorn migrates as structured fields (skills, experience, education) in addition to the raw file attachment.

Bullhorn activity feeds and note content on Candidate, Contact, Job, and Placement records migrate to Recruit CRM Tasks and Notes. We preserve note body text, author (mapped via User email), and original timestamp. Bullhorn's Activity feeds covering email, calls, and meetings map to Recruit CRM Tasks with the activity type captured in a custom task_type field. Bullhorn Job Reporting stage transitions migrate as note entries on the Candidate or Job record because Recruit CRM does not have a dedicated stage-history junction object; the text entry includes the original stage name, target stage name, timestamp, and transitioning user.

Bullhorn's pipeline stage sequence (Application through Submittal, Interview, Offer, Placement) maps to Recruit CRM's configurable Kanban pipeline stages per Job. We extract the stage names from Bullhorn's Job Reporting records and map them to Recruit CRM stage configuration during the schema design phase. Stage probabilities migrate as percentage values in a custom probability field on the Job pipeline configuration. Bullhorn's Job Reporting junction records tracking candidate movement through stages are converted to a text audit log on the Candidate record in Recruit CRM rather than a live-junction object, since Recruit CRM handles stage history through its activity timeline.