Migrate from BambooHR to Bullhorn ATS & CRM

BambooHR Employee records split into two Bullhorn targets depending on employment lifecycle stage. Employees who are currently active candidates for new roles (internal mobility, secondments, or sourcing candidates) map to Bullhorn Candidate records. Employees being recorded as placed staff from a prior agency engagement map to Bullhorn Contact records attached to a ClientCorporation. The split rule is defined during scoping based on the customer's use case — internal mobility cases go to Candidate; agency placement records go to Contact. Basic name, email, phone, address, and emergency contact fields migrate directly; BambooHR employment status, termination date, and hire date are stored as custom fields on the Bullhorn record because Bullhorn's standard fields are recruitment-focused.

BambooHR ATS Applicant records map directly to Bullhorn Candidate. Pipeline stage names (Applied, Phone Screen, Interview, Offer, Hired, Rejected) from BambooHR map to Bullhorn Candidate status and leadStatus fields, with manual mapping per customer because BambooHR pipeline stages are customer-defined. Resume files attached to BambooHR applicants migrate as Bullhorn Candidate resumes (file upload via Bullhorn REST API or document management). Custom application fields from BambooHR (any field beyond name, email, phone, resume, and stage) migrate as Bullhorn custom fields on the Candidate entity, with field type validation against Bullhorn's supported types (text, number, date, dropdown, multi-select, checkbox).

BambooHR job postings in the ATS layer map to Bullhorn JobOrder records. BambooHR job title, job description, employment type (full-time, part-time, contract), and location map to Bullhorn JobOrder title, description, employmentType, and addressCity/addressState fields. The BambooHR job status (Open, Filled, Closed) maps to Bullhorn JobOrder status (Open, Interviewing, Offer, Closed, Cancelled). Any BambooHR custom job fields migrate as custom fields on Bullhorn JobOrder.

BambooHR applications (Applicant-to-Job associations with application date, source, and custom fields) map to Bullhorn CandidateSubmission when the candidate is submitted to a job but not yet placed, and to Bullhorn Placement when the candidate is hired into the role. The mapping type is conditional based on BambooHR application status. Placements carry startDate, endDate, payRate, billRate, and client assignment — these map from BambooHR offer details and employment terms fields.

BambooHR Employee records that have an email address matching an existing Bullhorn User account resolve to that User record for OwnerId assignment on Candidate, JobOrder, and Placement records. BambooHR employees without a Bullhorn User account go into a reconciliation queue; the customer's Bullhorn admin provisions User accounts for those employees before record import resumes. This is a prerequisite step before Candidate import can proceed because Bullhorn requires a non-null OwnerId on record creation.

BambooHR time-off balances (accrued PTO, sick leave, personal days) and request history have no native Bullhorn equivalent because Bullhorn is an ATS, not an HRIS. We map time-off balances as Bullhorn custom fields on the Candidate or Contact record (if the customer uses Bullhorn for internal staffing and wants to track candidate availability). Time-off request history migrates as Task records with a custom type field for audit purposes, but Bullhorn does not enforce or process these as active policies.

BambooHR benefits enrollment data (health plan, dental, vision, 401k, HSA, FSA) is stored per Employee with customer-specific schema variation. We map benefits data as Bullhorn custom fields on the Candidate or Contact record if the customer wants to carry benefit election history. Benefits carrier names, plan tiers, and coverage effective dates migrate as text and date fields. This is flag scope — many BambooHR benefit exports contain carrier-specific plan codes that do not map to Bullhorn standard fields and require a manual review step during scoping.

BambooHR pay rate, pay type (salary, hourly, exempt), pay frequency, and currency map to Bullhorn custom fields on the Candidate record (for current/past pay) and Placement record (for bill rate and pay rate on placed candidates). BambooHR compensation grades and bands are customer-specific data that we map to Bullhorn custom fields or custom objects as appropriate. Bullhorn's standard compensation fields are placement-focused (billRate, payRate) rather than employment-focused, so we use Bullhorn's custom field infrastructure for pay history.

BambooHR's per-account custom fields (any field not in the standard employee schema) require a Bullhorn custom field to be created before migration data can land. Bullhorn requires a Support ticket to create a new custom object, but custom fields on existing entities (Candidate, JobOrder, ClientCorporation, Placement) can be created by Bullhorn admins via Admin > Field Mappings. We create the Bullhorn custom field definitions during the pre-migration schema phase, validate field types against Bullhorn's supported types (text, number, date, dropdown, multi-select, checkbox, currency), and then map BambooHR values during data transform. Bullhorn has a per-entity limit on custom field count that we verify during scoping.

BambooHR performance review cycles, review scores, and goals are not fully exposed in the standard employee export. We map review completion status and overall scores as Bullhorn custom fields on the Candidate or Contact record. Review text, feedback comments, and manager notes migrate as Bullhorn Note records linked to the Contact record. Detailed performance workflow history (multi-round review cycles, 360 feedback, goal trees) does not map to any Bullhorn standard object and is flagged as scope requiring admin rebuild or a third-party performance management integration.

BambooHR onboarding tasks, checklists, and document requests tied to new hires have no equivalent in Bullhorn ATS. Bullhorn Onboarding (the Able product, formerly a separate acquisition) handles candidate-facing onboarding after placement, not HR onboarding. We inventory BambooHR onboarding task names, checklist states, and document requests during scoping and deliver a written handoff document listing each task and its recommended Bullhorn Onboarding equivalent. The customer's Bullhorn admin or implementation partner rebuilds the onboarding workflow configuration post-migration.

Documents attached to BambooHR employee records (offer letters, signed contracts, certifications, tax forms) migrate as Bullhorn ContentDocument records linked via ContentDocumentLink to the corresponding Candidate or Contact record. BambooHR document binary storage is accessed via the BambooHR API file endpoint; we retrieve each document by employee ID and upload to Bullhorn using the Bullhorn REST API. Document type classification (offer letter, contract, certification) maps to a custom ContentDocument Description field. Bullhorn's Custom Import tool does not handle documents — this is an API-level migration step.