Migrate from BeyondPay to Bullhorn ATS & CRM

BeyondPay employee records (biographical data, hire date, job title, department, employment status) map to Bullhorn Candidate for active job seekers and to ClientContact for placed or employed candidates. We split by employment status: W-2 employees with active assignments in BeyondPay become Bullhorn ClientContacts attached to their corresponding ClientCorporation (the staffing firm's client); contract workers on assignment become Bullhorn Candidates with a Placement record linked to the ClientCorporation. Original BeyondPay hire date, department, and job title migrate as custom fields on both entities for compliance and audit purposes.

Year-to-date wage totals, pay period earnings, deductions, and tax withholdings from BeyondPay migrate into Bullhorn custom objects (Front Office Growth or Enterprise tier) or as fields on the Placement record for back-office invoicing use. We chunk payroll exports by calendar year, load prior-year W-2 data before activating any new payroll run in Bullhorn Back Office, and flag any multi-state wage allocations for manual verification. Bullhorn ATS tier does not include custom objects; in that case, we store YTD wage snapshots as note attachments on the ClientContact or Placement record.

Federal, state, and local tax codes, rates, and filing statuses configured in BeyondPay (particularly NJ and PA specific codes) must be translated to Bullhorn's tax table format if Bullhorn Back Office is active, or documented in a configuration guide for the customer's payroll admin to re-enter. We extract the tax jurisdiction list from BeyondPay during scoping, compare it against Bullhorn Back Office's supported state list, and flag any BeyondPay states not supported by Bullhorn for manual tax configuration post-migration.

Bank account routing numbers and account numbers for employee direct deposit migrate as encrypted fields if Bullhorn Back Office is active, or are documented in a secure handoff file for the customer's payroll admin to re-enter in Bullhorn's payroll setup. We flag any BeyondPay employees with multiple split deposits for manual verification before loading, as bank account data requires accuracy above all else and split deposit configurations vary by payroll system. Bullhorn's Back Office direct deposit setup requires separate payroll configuration not covered by Bullhorn ATS alone.

Health, dental, vision, and retirement benefit elections and coverage levels migrate as current-state snapshots in a Bullhorn custom object attached to ClientContact. Historical benefit election changes and effective-dated transitions are noted but not migrated as full audit trails since most ATS platforms do not track benefit history with the same granularity as payroll systems. We flag any BeyondPay benefit carriers not recognized in Bullhorn Back Office for manual re-enrollment.

Hourly employee time entries, overtime calculations, and accrual balances migrate as transaction records if the customer is activating Bullhorn Time & Expense as part of the migration. We flag whether BeyondPay tracks PTO and leave accruals separately, as Bullhorn Time & Expense has specific accrual tracking modules that must be configured before historical leave balance data is loaded. Time entry exports from BeyondPay are sequenced by pay period to align with Bullhorn's time tracking periods.

Court-ordered garnishments, voluntary deductions, and HSA or FSA contributions migrate as active deduction records in a Bullhorn custom object attached to ClientContact. We flag inactive garnishments separately with an end date and do not load them as active records. Bullhorn's Back Office supports deduction configurations but garnishment types, limits, and disposable income calculations must be verified against Bullhorn Back Office's supported garnishment table. Any garnishment type not supported in Bullhorn Back Office is flagged for manual re-entry by the customer's payroll admin.

WC class codes, rates, and carrier information are mapped to Bullhorn's WorkersCompLocation entity or a custom object on Placement. We verify that BeyondPay's class code tables align with the NCCI codes used in Bullhorn Back Office, as mismatches between class codes can cause audit failures in state WC filings. Carrier information migrates to the WorkersCompLocation carrier field. Any custom BeyondPay class codes not found in the standard NCCI table are flagged for manual classification review.

BeyondPay configures custom fields per client with no public schema documentation. We request a complete field inventory from the BeyondPay implementation team during discovery, map each BeyondPay custom field to either a Bullhorn native field (if a matching standard field exists), a Bullhorn Custom Field (if the Bullhorn edition supports custom fields on the entity), or a Bullhorn Custom Object (if no suitable field exists on the entity). Bullhorn ATS Growth does not support custom fields on standard entities; Enterprise or Front Office Growth is required for custom field migration. Any fields without a clear Bullhorn equivalent are flagged for manual review and either mapped to a custom destination field or excluded from the initial migration scope.

BeyondPay custom report definitions, scheduled reports, and saved report configurations are not migratable because BeyondPay does not expose a documented report export or template API. We deliver a written inventory of all active BeyondPay reports with their field selections, filters, and scheduling parameters during scoping, so the customer's admin can rebuild them in Bullhorn's reporting module post-migration. Bullhorn's report builder supports candidate pipeline reports, placement activity, and back-office invoicing reports but may not replicate every BeyondPay payroll-specific report format.

If BeyondPay stores any employer or client company information (separate from the staffing firm's own employee records), those map to Bullhorn ClientCorporation. The BeyondPay company address, industry classification, and account manager fields map to ClientCorporation address, businessSector, and ownerId respectively. If BeyondPay does not store separate company records (beyond the employer's own record), we skip this object and rely on Bullhorn's ClientCorporation setup for the staffing firm's clients separately.

BeyondPay does not expose a user or owner concept equivalent to Bullhorn's User record. However, if BeyondPay tracks payroll administrators or HR contacts, we map those to Bullhorn User records by email match. Any BeyondPay contact without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision. Bullhorn requires active User records for all staff who will log in; recruiters without Bullhorn User accounts are not migrated as Users.