Migrate from Paycor to Bullhorn ATS & CRM

Paycor Persons (demographic and contact data linked to Employees) map to Bullhorn Candidate records. We export via Paycor's GET /Persons endpoint filtered by Legal Entity, mapping firstName, lastName, email, phone, address, and dateOfBirth to Bullhorn Candidate standard fields. Custom Person fields migrate to Bullhorn Candidate custom fields within the entity limit (10 on Front Office Growth/Enterprise, 2 on Bullhorn ATS). Name and address formats may require normalization to Bullhorn's character limits before import.

Active Paycor Employees map to Bullhorn Candidate records with employment type used to determine placement track. Former Employees who should not appear in the recruiting pipeline map to Bullhorn Contact records under a ClientCorporation. We extract employmentStatus, employeeType, hireDate, and terminationDate from Paycor's Employee object and use these to drive the Candidate versus Contact routing rule during migration design.

Paycor Legal Entities (the organizational hierarchy root representing subsidiaries or distinct business entities) map to Bullhorn ClientCorporation records. Each Legal Entity's name, FEIN, and address become the ClientCorporation name, tax ID, and business address. Subordinate objects including departments, work locations, and pay groups attach under the ClientCorporation after parent creation to satisfy Bullhorn's referential integrity requirements.

Paycor departments (organizational cost centers per Legal Entity) export via the Departments endpoint with department codes, names, and parent-child hierarchy. Bullhorn does not have a native department object. We map department codes to a custom multi-select picklist or tagged classification on ClientCorporation for costing and reporting purposes, with the customer choosing between options during scoping.

Paycor work locations tied to Legal Entities (used for tax jurisdiction, overtime rules, and compliance) map to Bullhorn ClientCorporation address records for the employing entity, and to Candidate address fields for the individual's work location. Multiple work sites per Legal Entity map to individual address lines with jurisdiction flags stored in custom fields for FLSA and state compliance.

Paycor Job Titles (position descriptors from GET /JobTitles) map to Bullhorn Candidate title or skills fields. Job Titles used as filters in Paycor payroll rules are preserved in a custom field on Candidate so that payroll administrators can reference the original classification without rebuilding the rule in Bullhorn's absence of native payroll.

Paycor time-off plans (accrual rules per Legal Entity) and time-off types (PTO, sick, etc.) have no direct Bullhorn equivalent in the core ATS. We map plan accrual rates and carryover rules to Bullhorn Onboarding's time-off tracking module if the customer licenses Bullhorn Onboarding, or to a custom object with accrual balance and plan type fields if Bullhorn Onboarding is not in scope. Current PTO balances migrate as initial balance records.

Paycor Pay Groups define compensation grouping rules for benefits eligibility and costing. Bullhorn Candidate records support compensation-related custom fields (targetSalary, payRate, overtimeRate). We map Pay Group membership to these custom fields and document the Pay Group-to-benefits-eligibility mapping for the customer's admin to configure in Bullhorn Onboarding or a third-party HRIS post-migration.

Paycor benefit deduction codes and garnishment orders are compliance-critical records with no native Bullhorn equivalent. We map these to Bullhorn Custom Objects under the Candidate entity. Front Office Growth and Enterprise editions allow up to 10 custom objects with 55 fields each, which covers active deduction codes, deduction amounts, carrier information, and garnishment court order metadata. We flag any deductions exceeding the 55-field limit for customer review before migration.

Historical Paycor payroll registers, pay stubs, and tax filings require special handling. Bullhorn has no native payroll processing object. We map historical payroll summary records (YTD earnings, tax withholdings, deduction YTD totals) to a Bullhorn custom object under Candidate for audit and compliance continuity. Full pay stub detail does not migrate because Bullhorn lacks the document rendering model to display them; pay stub archives should be exported from Paycor as PDFs and stored in Bullhorn's document management layer post-migration.

Paycor hourly earnings data, time punches, and accrual history export via Employee Earnings and Punch endpoints. Bullhorn's core ATS does not support time-and-billing entries. We map punch summary records to a custom object under Candidate for staffing firms that need placement billing history, or to Bullhorn Onboarding time entries if that module is licensed. Paycor punch data split by Employee and Entity requires separate export queries to avoid double-counting.

Paycor personnel documents (I-9s, W-4s, signed policies) are stored separately from Employee records and require a document archive partner or third-party extraction tool at scale. Bullhorn supports document attachment via ContentDocument and ContentDocumentLink linked to Candidate or ClientCorporation. We coordinate with document archive extraction partners (TAP Innovations is one such provider) for large document volumes and map extracted metadata to Bullhorn ContentDocument records with the original file attached.

Paycor users attached to Employee records (system logins, payroll administrators, HR managers) map to Bullhorn User records by email match. Bullhorn User provisioning must happen before record import because UserId is a required field on Candidate, Contact, and ClientCorporation for assignment and ownership. Users without a matching Bullhorn User go to a reconciliation queue for the customer's admin to provision before migration resumes.

Current PTO balances and accrual transaction history export per Employee and Time Off Plan from Paycor. We map current balance amounts to a Bullhorn custom object field and accrual transaction history to a related custom object child record. This allows Bullhorn Onboarding or the customer's payroll admin to set initial balances in the new system without losing the accrual record of how the balance was built.