Migrate from Scout by Rebelware to Bullhorn ATS & CRM

Scout Job records map to Bullhorn JobOrder. We map title, description, department, location, status, and employment type. JobOrder serves as the parent container for all candidate submissions. Bullhorn's JobOrder has separate fields for address components (city, state, zip) that Scout stores as a single location string; we parse and split these during transformation. Status mapping is explicit: Scout's open/closed maps to Bullhorn's status values (Open, Interview, Offer, etc.).

Scout's LinkedIn, Indeed, and other job board OAuth connections cannot be transferred to Bullhorn. We extract the integration configuration (board name, posting frequency, job categories linked) as metadata and flag each board for re-authentication in Bullhorn's integrations panel during cutover. Bullhorn has native connectors for major job boards; the customer reconnects each board with fresh OAuth credentials post-migration.

Scout Candidate records map directly to Bullhorn Candidate. We map contact information (name, email, phone, address), work history, education, skills, and source. Candidate Custom Fields require explicit value-mapping against Bullhorn's custom field schema; Bullhorn's Field Mappings tool in Admin controls where these appear on the Add/Edit pages. We request the full list of Scout custom field definitions during scoping to build the mapping table before migration.

Scout Applications link a Candidate to a Job and carry pipeline stage data. We map the Candidate reference, JobOrder reference, date applied, and status. Bullhorn's JobSubmission represents the same relationship. Stage history with transition timestamps migrates as a series of JobSubmission records with stage-change entries recorded in Bullhorn's activity log; we preserve timestamps where Bullhorn's model supports them.

Scout's configurable pipeline stages (Applied, Screening, Interview, Offer, Hired, and any custom names) require an explicit mapping table because Scout organizations define their own stage names and counts. We request a screenshot of the Scout pipeline configuration during scoping and map each Scout stage to the corresponding Bullhorn JobOrder status or to a Bullhorn Record Type stage that we configure before migration. Stages that do not map directly go to a default status with a flag for admin review.

Scout Interview Notes are unstructured free-text fields attached to Candidates. We extract note content, author (mapped to Bullhorn User by email), and timestamp. Bullhorn has a Notes section on Candidate records for free-text content. Where Scout notes contain structured rating data (numerical scores, rating categories), we parse and route to Bullhorn's native rating fields or to a custom rating object rather than leaving in free text.

Scout numerical ratings assigned by interviewers map to Bullhorn custom numeric fields on Candidate or to a dedicated custom rating object. We preserve the numeric value, the rated-by user reference, and the date. Bullhorn's standard Candidate record does not have a native rating field at all editions; we configure a custom field (type: number or currency) during schema design if the customer wants structured ratings migrated.

Scout flexible user roles and permission scopes map to Bullhorn User roles. Bullhorn distinguishes usertype (Admin, Standard, Read Only, Limited Access) and permission sets. We extract Scout user records (name, email, role designation) and map to Bullhorn User with the closest equivalent role. Bullhorn's Admin usertype is required for Field Mapping access; we flag any Scout admin users so they receive Admin-level access in Bullhorn.

Scout performance reporting on job openings and applicant pipeline generates summary metrics that we extract as report metadata. Bullhorn's native reporting is scoped to Bullhorn entities (Candidate, JobOrder, Placement) and has different report types and dimensions. We migrate report summary data to a Bullhorn custom object or deliver as a structured CSV so the customer can recreate the reports in Bullhorn's reporting module post-migration.

Scout custom fields on Candidates require explicit value-mapping against Bullhorn's Field Mappings tool. Bullhorn editions have different custom field limits; Bullhorn ATS Growth has no custom objects, Bullhorn ATS supports 2 custom objects with 55 fields each, and Growth/Enterprise supports 10 custom objects with 55 fields each. We confirm the destination edition during scoping and configure the custom field schema before importing any candidate records with custom data.

Scout custom fields on Applications map to Bullhorn JobSubmission custom fields if Bullhorn's edition supports them, or to a custom object linked to JobSubmission. Application-level custom fields are less common but require mapping when present. We parse the Scout field definition (field name, type, values) and create the equivalent Bullhorn field during schema setup, mapping picklist values explicitly.

If Scout contains client or company records separate from job data, these map to Bullhorn ClientCorporation. Bullhorn uses ClientCorporation as the parent entity for all client-related records (contacts, job orders, placements). We extract client name, address, industry, and contact information, and resolve the ClientCorporation ID before importing any related JobOrders. Scout users without separate client records will not have data in this object; we verify during discovery.