Migrate from Rival to Bullhorn ATS & CRM

Rival employee records map to Bullhorn Candidate. Core fields (firstName, lastName, email, title, department, hireDate) translate directly. Rival custom fields discovered during schema discovery phase require per-migration field-mapping to Bullhorn Candidate customObject fields. Candidate is the primary person record in Bullhorn and must be loaded before any JobSubmission or Placement records because Placement references Candidate via foreign key. We preserve Rival employee IDs in a custom field rival_employee_id__c on Candidate for audit traceability.

Rival's department and reporting-line hierarchy is decomposed into Bullhorn ClientCorporation (for organizational units with client or company relationships) and Bullhorn Department (for internal org structure). Reporting relationships stored as manager-employee links in Rival are preserved as a custom field rival_manager_id__c on Candidate, with a post-migration script that resolves the reference to the manager's Bullhorn Candidate record.

Rival effective-dated compensation rows (salary, bonus, equity, benefits plan) map to Bullhorn Custom Objects attached to Candidate. Each effective_date row becomes a separate Custom Object record with compensation_effective_date__c, base_salary__c, bonus_target__c, and benefits_tier__c fields. Bullhorn Support must provision the Custom Object via the setup spreadsheet before we can write to it; this adds 5-10 business days to the project timeline and is done before migration execution begins.

Rival PTO balances are current-state snapshots at migration time. We write these as a single Custom Object record per Candidate with fields pto_balance_hours__c, pto_accrual_rate__c, and pto_snapshot_date__c. Ongoing accruals after migration are handled manually or through Bullhorn's third-party payroll integrations post-migration. Bullhorn does not have a native PTO accrual engine; this is an HR-administration gap that Bullhorn expects to be filled by external HRIS or payroll tools.

Rival benefits data (plan name, coverage tier, enrollment date, carrier) migrates to Bullhorn Custom Object fields on Candidate. Carrier-specific plan IDs do not map 1:1 to Bullhorn because Bullhorn is a staffing ATS, not an HRIS, and has no native benefits administration module. We map what exists (plan name, tier, enrollment date) and flag carrier-specific IDs for manual reconciliation post-migration.

Job title and department assignments on Rival employee records map directly to Candidate.title and the Bullhorn Department lookup. Title history in Rival is preserved as a Note on the Candidate record if the customer requires the full history; the current title is the primary field.

Rival location fields (office address, city, state, remote designation) map to Candidate address fields in Bullhorn. If Rival stores company-wide office locations separate from employee assignments, we map those to ClientCorporation addresses. Remote or work-from-home designations migrate as a text field rather than a structured picklist unless Bullhorn's schema includes a remote-friendly designation field.

Rival user accounts with admin, manager, and employee role types map to Bullhorn User records. Rival role names (Admin, Manager, Employee) map to Bullhorn permission sets or profile assignments. We extract distinct user records referenced on employee profiles and match by email against Bullhorn Users. Any Rival user without a Bullhorn User counterpart goes to a reconciliation queue for the customer's Bullhorn admin to provision.

Rival employee documents (offer letters, contracts, ID scans) are binary blobs with no documented export endpoint. We cannot guarantee document fidelity in a self-serve migration. We export document filenames and associate them with employee IDs in a mapping file for the customer's admin to re-upload manually post-migration. This is documented as a separate workstream with an estimated manual effort based on document count.

Rival custom fields vary by customer organization and have no stable public schema. We discover the live schema during scoping by coordinating with the customer's Rival administrator, building a per-migration field-mapping table before executing any writes. Bullhorn custom fields live on Custom Objects (customObject1s through customObject10s) that must be provisioned by Bullhorn Support via the setup spreadsheet. Each Custom Object supports up to 55 fields with limits on checkbox, dropdown, and text field counts per Bullhorn KB.

Rival stores salary changes, title changes, and org moves as effective-dated events rather than immutable snapshots. We extract the full effective-dated history and write each row as a separate Custom Object record on the Candidate with an effective_date field, preserving the sequence. This is distinct from Bullhorn's standard Audit History, which tracks field changes after they occur in Bullhorn rather than importing historical changes.

Rival onboarding task automation sequences are not migrated as code. We extract a list of active onboarding workflows, the tasks within each, the stagger logic (start date offset, completion dependencies), and any conditional rules. This is delivered as a written inventory for the customer's Bullhorn admin or implementation partner to rebuild using Bullhorn Automation (Herefish) or a third-party onboarding tool. Bullhorn's native task management does not include the staggered start-date logic that Rival's automation provides.