Migrate from Dayforce to Bullhorn ATS & CRM

Dayforce Worker records map to Bullhorn Candidate. We extract biographical data (legal name, date of birth, address, contact information), employment status, and the Dayforce worker number as the Bullhorn Candidate externalID for dedupe. Dayforce Quick Entry data attached to a Worker migrates as a Candidate note with a timestamp reference. Workers who have been placed or are actively assigned in Dayforce carry an active assignment flag we use to populate the Candidate status and last-placement date in Bullhorn.

Dayforce Job Assignments associate a Worker to a Job with effective dates, classification codes, and assignment status. We map Job Assignment status (Active, Terminated, On Leave) to Bullhorn Candidate employment status on the Person record. Department, employment type, and work location from Job Assignment transfer to custom fields or the Job Order's corporate information section. Terminated assignments generate a placement history record in Bullhorn with the end date and termination reason preserved.

Dayforce Job records define role-level attributes including job title, FLSA classification, and Workers Comp codes. We create Bullhorn Job Orders as the role-level record, populating title, required skills (from Dayforce job qualifications), and job description. Multiple active Job Assignments under a single Dayforce Job produce multiple Bullhorn Candidate records with the same Job Order reference, representing individual placements under a shared role.

Dayforce Position Terms define the duration and status of a position (ongoing, fixed-term, seasonal). We map Position Term status and duration to Bullhorn Candidate custom fields tracking employment type (full-time, part-time, contract) and assignment end date. The ShortName sort key from Dayforce's PositionTerm export becomes a Bullhorn reference number for cross-system audits.

Dayforce Legal Entities define the employing corporate entity per jurisdiction. We map each Dayforce Legal Entity to a Bullhorn Corporation record used as the employer of record for staffing and placement purposes. Corporate address, tax ID, and jurisdiction flags transfer to the Bullhorn Corporation. This mapping is required before any Candidate or Job Order migration because Bullhorn ties employment and placement records to a Corporation.

Dayforce Pay Rates are effective-dated on Workers with rate type, amount, and currency. Bullhorn has no native equivalent. We create a custom object Employment_Compensation_History__c on the Candidate record with fields for effective_date, rate_type, hourly_or_salary, amount, currency, and end_date. Effective-dated rates with overlapping start dates are normalized chronologically before import: Dayforce auto end-dates a prior rate when a new one overlaps, and we replicate that logic to preserve a clean rate sequence. We flag any gaps in the rate history that indicate a pay discontinuity.

Dayforce Earning Groupings categorize pay components (hours-based, flat, bonus, commission) with MTD/QTD/YTD accumulations. Bullhorn's placement and billing records track commission and contractor pay rates but not HR earning accumulations. We create a custom object Earning_Component__c linked to Candidate, with fields for component_type, hours_or_flat, current_accumulation, and pay_frequency. Accumulation totals migrate as snapshot values at the time of cutover.

Dayforce Time Off Balances track accrual balances, carryover, and usage per Worker. Bullhorn does not natively manage accrual tracking. We create a custom object Time_Off_Snapshot__c on the Candidate record capturing the accrual type, current balance, accrual rate, carryover amount, and expiration date at migration time. We note that ongoing accrual calculations do not continue post-migration; the customer must configure accrual logic in Bullhorn's custom object or a connected time-tracking tool if ongoing accrual tracking is required.

Dayforce maps benefit plan options to Tiers based on dependent coverage levels with carrier-compatible 063/064 record export. Bullhorn has no native benefits enrollment or administration object. We create a custom object Benefits_Enrollment__c linked to Candidate capturing plan_name, coverage_tier (Employee, Employee+Spouse, Employee+Children, Family), election_status, monthly_premium, and carrier_name. Carrier feed files (063/064 records) do not migrate to Bullhorn and must be reconfigured with the new benefits administrator or carrier directly.

Dayforce Workers Comp codes are assigned to Jobs in Org Setup with classification rates and multi-select job-to-code mappings. Bullhorn Job Orders support custom fields for compliance classification. We extract the Workers Comp code-to-job mapping from the Job Assignment export and create a custom object Workers_Comp_Classification__c linked to the Job Order, populating code, classification_description, and rate per code.

Dayforce manages documents attached to Workers (offer letters, contracts, certifications, I-9s). Bullhorn's Document entity attaches files to Candidate records. We extract document metadata (document type, upload date, file name) and binary blobs where accessible via the Dayforce API, and load them as Bullhorn Candidate documents. Document type taxonomy differs between systems: we map Dayforce document types to the closest Bullhorn document category during import. I-9 and tax withholding forms may require re-execution under the new employer and are flagged for the customer's HR admin.

Dayforce supports custom fields at the Worker level with computed-value functions. We extract all custom field values and create matching custom fields on the Bullhorn Candidate object with equivalent data types (text, number, date, picklist). Custom field functions (computed values) do not replicate in Bullhorn; we preserve the last computed value as a static field and document the original function logic for the customer's Bullhorn admin to rebuild as a formula field if supported on the custom field type.

Dayforce Workers can have an assigned HR owner or manager. We resolve Dayforce worker owners by email match against Bullhorn User records. Any Dayforce owner without a matching Bullhorn User is held in a reconciliation queue for the customer's Bullhorn admin to provision before record migration resumes. Bullhorn's user-based ownership model differs from Dayforce's HR role assignment, so manager relationships may require a custom field on the Candidate record rather than a native ownership link.