Migrate from RECRU to Bullhorn ATS & CRM

RECRU Candidate records map to Bullhorn Candidate. We extract all standard fields (name, email, phone, skills, work history) plus tenant-added custom properties as key-value pairs. AI-generated match scores from RECRU are preserved as a custom float field recru_match_score__c on the Bullhorn Candidate; this score has no fixed range or calibration and is not comparable to any Bullhorn-native scoring system. Tags applied in RECRU migrate as flat label arrays attached to the Candidate record in Bullhorn. Deleted candidates (GDPR requests run before export) are excluded from the migration dataset.

RECRU Job requisitions carry title, description, department, location, salary range, and hiring pipeline stages. Bullhorn JobOrder is the equivalent object. Pipeline stage order from RECRU maps to a Bullhorn Record Type and Sales Process that we configure before migration. If Bullhorn uses a predefined pipeline structure, RECRU stages map to the closest equivalent stage name and any stages with no clear destination are flagged in the migration report for admin review.

RECRU User accounts (name, email, role, team assignment) map to Bullhorn User records. We resolve by email match against the Bullhorn destination org. Any RECRU User without a matching Bullhorn User is placed in a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Active/inactive status is preserved based on the RECRU account state at export time.

RECRU custom properties on Candidates are extracted as key-value pairs with field name and type. Bullhorn Custom Objects require a support ticket to Bullhorn Support for initial provisioning. Bullhorn Front Office Growth/Enterprise editions support up to 10 Custom Objects with 55 fields each; Bullhorn ATS supports 2; ATS Growth supports none. We pre-create the destination schema via a Bullhorn Support ticket before migration and validate field limits (some Bullhorn fields are capped at 100 characters). We fallback to text fields for unsupported custom field types.

Email threads and message logs attached to RECRU Candidate records migrate as a flattened activity log in Bullhorn. Bullhorn renders each message as a separate Note record or Task activity entry rather than preserving the original thread structure. Message sender, recipient, timestamp, and body content transfer; thread hierarchy does not. Bullhorn's REST API supports Note and Task creation; the original thread structure cannot be fully replicated in Bullhorn's flat activity model.

Interview events in RECRU carry date, interviewer, and outcome. Bullhorn Appointment is the equivalent scheduling object. We map RECRU interview date to Bullhorn Appointment dateTime, interviewer to Appointment attendee relations, and outcome to a custom Appointment field or Note. Not all Bullhorn editions expose full Appointment scheduling; we validate the destination edition's feature availability during scoping.

RECRU pipeline stage names and order migrate as Bullhorn Record Types (one per RECRU pipeline) with corresponding Sales Process stage values. Stage probability percentages from RECRU map to Bullhorn stage probability values with rounding to the nearest integer. Bullhorn's Sales Process whitelists which stage values are valid per Record Type, preventing invalid stage transitions. We configure this in a Bullhorn Sandbox before production migration.

Tags applied to Candidates in RECRU migrate as Bullhorn Candidate Tags. Bullhorn natively supports tagging Candidates with flat label strings. We preserve the tag names exactly and attach them to the corresponding Candidate record in Bullhorn. Tags used for content classification in RECRU do not have a native Bullhorn equivalent beyond the tagging system; we map them as-is.

Evaluation scorecards submitted by interviewers in RECRU migrate as JSON objects attached to the Candidate record. Bullhorn editions that support Custom Objects store them there; editions without Custom Object support receive scorecards as Note records with the scorecard data serialized in the Note body. Destination admin reviews the scorecard format during scoping to determine the preferred storage approach.

RECRU workflow automation rules are JSON-backed in the database with a visual rule builder UI exposing conditional branching. Bullhorn Automation (trigger-action pairs) uses a different model and cannot accept RECRU workflow rules as a direct import. We export the full rule graph including all conditional branches, delays, and actions, and deliver it as a written inventory document. The customer's Bullhorn admin or a Bullhorn partner rebuilds the automation logic in Bullhorn Automation post-migration. Multi-step conditional branches may collapse into single automations or require manual redesign in Bullhorn.

Bullhorn includes ClientCorporation and ClientContact as first-class objects for tracking the client side of the recruiting relationship. RECRU does not have an equivalent native client tracking layer. If the customer has client data stored in RECRU as a related entity or in an external system, we can map it to Bullhorn ClientCorporation during migration. We flag this gap during scoping and determine whether client data exists in RECRU or requires separate export.

Bullhorn Placement records track successfully placed candidates, bill rate, pay rate, start date, and placement status. RECRU does not have a native Placement object. If the customer has placement records stored in RECRU (e.g., as custom fields on a Candidate or Job), we extract them and map to Bullhorn Placement. We flag this during scoping and configure the Bullhorn Placement schema if the customer has placement data to migrate.