Migrate from Rival Recruit to Bullhorn ATS & CRM

Rival Recruit candidate records map 1:1 to Bullhorn Candidate. The source candidate ID becomes a custom field rival_candidate_id__c for cross-reference. Contact info (name, email, phone, address), work history, education, source attribution, and current stage status transfer directly. Resume attachments extract as binary files and reattach to Bullhorn via the Document entity linked to the Candidate. Active pipeline stage maps to Bullhorn's Candidate status values, which we configure as a picklist matching the source stage names.

Rival Recruit Positions map to Bullhorn Job (the JobOrder entity in Bullhorn's API). Title, department, location, hiring manager (mapped to Bullhorn Owner/User), and open/closed status transfer directly. The position approval workflow state is preserved as a custom field rather than an active workflow, since Bullhorn does not replicate Rival Workflow definitions. Job status (Open/Closed/On Hold) maps to Bullhorn's employmentType and status fields.

Rival Recruit onboarding journeys managed in Rival Workflow tie to new hire records. Bullhorn does not have a native onboarding journey object; we map active onboarding journeys to Bullhorn Employee records (Employee entity) with onboarding status stored as a custom field onboarding_journey_status__c. Pending I-9, tax forms, and compliance documents attach to the Employee record. We flag any onboarding steps that reference undocumented Rival Onboarding API endpoints and fall back to bulk export for those records.

Resumes, cover letters, offer letters, background check results, and compliance documents extract from Rival Recruit as binary attachments with their metadata. We remap each document to the corresponding Bullhorn entity (Candidate, JobOrder, or Placement) using the Bullhorn Document API. Document type labels (resume, cover_letter, offer_letter) map to Bullhorn's description field with a custom document_type__c picklist for filtering.

Rival Recruit employee records (personal info, job title, department, manager, start date, employment status) map 1:1 to Bullhorn Employee. Effective-dated employment changes preserve their historical timestamps in a custom field employment_history__c as a JSON array. Bullhorn's Employee entity supports termination records, which we create from the Rival Recruit employment status field when applicable.

Rival platform users (name, email, role, team assignment) map to Bullhorn User records. We match by email address during migration. The Owner assignment on Candidate, Job, and Employee records resolves to the Bullhorn User ID after User import completes. Any Rival Recruit user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes.

Rival Recruit tags applied to candidates for segmentation extract as a flat lookup table (candidate_id, tag_name). Bullhorn supports tagging on Candidate records via the tags field. We reapply tag assignments as Bullhorn tags on the migrated Candidate records. If tag count exceeds Bullhorn's practical tag limit, we convert excess tags to a custom multi-select picklist on the Candidate record.

Rival Recruit branded career site configurations, job board distribution settings, and employee testimonial content are configurable assets, not transactional records. We export the site configuration as a structured JSON document and the content blocks as a written inventory for the customer's team to rebuild in Bullhorn's Career Portal or a Bullhorn-endorsed WordPress plugin. This is not a live migration of site data.

Rival Recruit onboarding, offboarding, and internal mobility workflows define journeys with steps, assignees, and conditions. Bullhorn Workflows and Rival Workflows are architecturally distinct and cannot migrate as code. We export workflow definitions as JSON blueprints and remap step owners to Bullhorn User IDs where possible. The customer receives a written workflow inventory document with recommended Bullhorn automation equivalents for each journey. Rebuild is handled by the customer's Bullhorn admin or an implementation partner post-migration.

Rival Recruit interview events (date, time, interviewer, candidate, position) map to Bullhorn Appointment records attached to the Candidate and Job. Interview scorecards require manual rebuild in Bullhorn; we document the scorecard fields and structure as a separate inventory. Calendar relationships (interviewer availability, interview type) transfer as Appointment metadata where supported by the Bullhorn API.

Rival Recruit custom fields on candidates and positions are entirely customer-specific with no universal default. We perform a pre-migration schema audit via the Rival Recruit API to enumerate every active custom field and its data type. Bullhorn's Growth and Enterprise editions allow up to 10 Custom Objects with 55 fields each (ATS Growth capped at 2). We map each discovered Rival custom field to a Bullhorn custom field, using the appropriate Bullhorn field type (text, number, picklist, date, checkbox, multi-select). Fields that exceed Bullhorn's character limits receive truncation with a note in the migration log.

Organizations with multi-year histories in SilkRoad Technology may have legacy data referencing SilkRoad-specific naming conventions, workflow IDs, and API endpoints. We audit the Rival Recruit export for SilkRoad-era field names, deprecated workflow references, and outdated integration configuration. These artifacts are renamed or flagged for manual review before Bullhorn import. Any deprecated endpoint references in the export are mapped to Bullhorn equivalents and documented in the migration report.