Migrate from Paylocity to Bullhorn ATS & CRM

Paylocity Employee records map to Bullhorn Candidate. The composite Paylocity Employee ID plus Company ID is stored as a permanent external ID field (pcty_employee_id__c + pcty_company_id__c) on the Bullhorn Candidate record. This preserves the full source identity for any future payroll integration or audit trail. Candidate name, email, phone, address, and employment status map to Bullhorn standard Candidate fields. The migration resolves the Paylocity Company ID to a Bullhorn ClientCorporation or Corporate Department reference where applicable.

Paylocity Company ID entities map to Bullhorn ClientCorporation records when the migration scope includes mapping internal organizational structure. Each Paylocity Company ID (representing a legal entity, subsidiary, or benefit division) becomes a ClientCorporation with the company's legal name, address, and tax ID. The Company ID is stored as an external ID on the ClientCorporation for reconciliation.

Paylocity biographical fields (legal name, date of birth, address, contact info) and employment data (hire date, termination date, job title, department, employment status, FLSA classification) map to Bullhorn Candidate standard fields and custom fields. Hire date maps to dateAvailable; job title maps to occupation; department maps to a custom Candidate field. We apply Bullhorn's field-type rules (date fields, text fields, picklist fields) during mapping.

Organizations with multiple Paylocity Company IDs require explicit mapping to Bullhorn's entity structure. We detect all active Company IDs during discovery and create a corresponding ClientCorporation per entity. If the destination Bullhorn org supports departments within a ClientCorporation, we use that for additional granularity. We flag any duplicate Candidate records that would result from an employee ID appearing under multiple Company IDs and apply a de-duplication strategy (prefer active Company ID, archive secondary) before import.

Paylocity compensation records (pay rates, salary changes, bonus amounts, pay frequency, effective dates) do not have a native Bullhorn equivalent. We create a Bullhorn Custom Object (CandidateCompensation) linked to Candidate via a lookup relationship, with fields for payType, baseRate, effectiveDate, payFrequency, bonusAmount, and currency. Historical compensation records migrate as read-only reference entries ordered by effective date. Pay-type-aware mapping handles hourly, salary, and commission structures distinctly.

Paylocity benefits enrollment data (carrier, plan name, coverage level, deduction amounts, election status) migrates to a Bullhorn Custom Object (CandidateBenefits) linked to Candidate. The migration preserves benefit plan names, enrollment dates, and deduction amounts as reference records. Plan-level rules, contribution tiers, and eligibility criteria are not migrated because Bullhorn does not have a benefits administration engine and these configurations would have no functional destination.

Historical pay run records (gross pay, net pay, tax withholdings, deduction line items) from Paylocity migrate to a Bullhorn Custom Object (PayRunReference) linked to Candidate. These are read-only reference records; Bullhorn does not process payroll and cannot recalculate tax withholding. We preserve the most recent 12-24 months of pay run history as reference data based on customer scope. Retroactive pay adjustments migrate as adjustment entries with a flag noting they are historical reference only.

Paylocity W-4 federal allowances, state withholding allowances, and supplemental tax rate elections migrate to a Bullhorn Custom Object (TaxWithholdingRef) linked to Candidate. These records are migrated as a snapshot of the employee's last known tax election as of the migration date. Bullhorn does not have a tax withholding engine, so the migration does not establish any active withholding process; the records serve as a reference for the customer's payroll team to re-enter elections in their chosen payroll system post-migration.

Paylocity accrual balance snapshots (PTO available, PTO used, sick balance, personal balance, carryover amounts, policy year) migrate to a Bullhorn Custom Object (AccrualSnapshot) linked to Candidate. We capture the balance as of the migration date and flag it as a static snapshot, not a live balance. Bullhorn's accrual engine does not recalculate; if the customer wants live accrual tracking in Bullhorn, they must implement a third-party time-off management integration or custom accrual calculation logic post-migration. We note any Paylocity accrual calculation discrepancies discovered during export so the customer can correct balances before migration.

Paylocity allows custom employee properties to be created independently in the HR module and the Payroll module, meaning a custom property may appear in one module's API response but not the other. We query both module-specific endpoints during discovery and reconcile the union of all custom fields. We map text, number, and date custom fields to Bullhorn Candidate custom fields of equivalent type. Picklist and multi-select custom fields map to Bullhorn picklist or multi-select-picklist fields where the allowed values are preserved. Where Paylocity field names overlap but data types differ, we apply explicit type casting and log a discrepancy note in the migration manifest.

Employee documents stored in Paylocity (offer letters, signed agreements, certifications, I-9 forms, performance reviews) migrate as Bullhorn Candidate documents. We map file type, employee association, and document category to Bullhorn's document model. Documents are uploaded via Bullhorn's file attachment API and linked to the Candidate record. File naming preserves the original document descriptor from Paylocity. Bullhorn's document size limits apply; documents exceeding Bullhorn's file size threshold are flagged for alternative storage and linked by URL reference.

Paylocity employees with HR administrator, payroll processor, or system configuration roles map to Bullhorn User records by email match. Any Paylocity user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Bullhorn User provisioning (active vs inactive status, role assignment) is the customer's responsibility; we map the role context from Paylocity to Bullhorn role descriptions for the admin's reference.