Migrate from iRecruit to Bullhorn ATS & CRM

iRecruit Job postings map to Bullhorn JobOrder records. Each iRecruit job carries its title, description, location, employment type, and salary range as standard fields. Job status (open, filled, closed) maps to Bullhorn's status field. Internal and external visibility flags map to the isPublic flag on JobOrder. Active social posting settings (LinkedIn, Facebook, Twitter) do not have a direct Bullhorn API equivalent for bulk configuration — we document the setting state for the customer's admin to reconfigure in Bullhorn's job distribution settings post-migration.

iRecruit candidate profiles map to Bullhorn Candidate records. The candidate's resume is attached as a ContentDocument linked to the Candidate via ContentDocumentLink. Application date, source (Indeed, Monster, direct, etc.), and current stage migrate as standard fields. Candidate email, phone, name, and address fields map directly. Where a candidate has applied to multiple iRecruit jobs, we create one Bullhorn Candidate record with separate JobSubmission records for each application, preserving the per-application stage independently.

Each iRecruit candidate-to-job application maps to a Bullhorn JobSubmission record linking the Candidate to the JobOrder. The submission date, status (new, screening, interview, offer, hired, rejected), and any rejection reason migrate. The JobSubmission is the Bullhorn object that tracks the candidate's movement through the hiring pipeline for a specific job, satisfying the requirement to represent each application as a distinct record.

iRecruit Enterprise requisitions capture the hiring request from a department manager, including job details, department, and approval status. We map requisitions to Bullhorn Lead records if they represent a pre-qualified client hiring need, or to JobOrder if they represent an internal staffing req that becomes a job order in Bullhorn. Requisition approval routing state migrates as a custom field on the target object, not as a Bullhorn workflow — the approval chain requires rebuild in Bullhorn's approval process configuration.

iRecruit iConnect onboarding records contain I-9 completion status, tax form responses (W-4, state equivalents), benefits enrollment selections, and e-signature completion flags. Bullhorn's Able onboarding module handles this differently. We migrate the onboarding form field data and completion state as custom fields on the Bullhorn Candidate record so the Bullhorn admin can initiate onboarding from the correct stage in Able. Active iConnect e-signature invite sessions cannot be transferred as live sessions — they must be restarted in Bullhorn Able on day one of go-live.

iRecruit user accounts (recruiter, hiring manager, admin roles) map to Bullhorn User records. Role assignments and team associations migrate as user-level properties and a custom User field for department affiliation. Session-based authentication tokens cannot migrate. Bullhorn's User records must be provisioned by the customer's Bullhorn admin before the candidate and job migrations run, since OwnerId references on JobOrder and Candidate require a valid Bullhorn User ID.

iRecruit stores knock-out questions as per-job field configurations, and a candidate's answer set varies by the specific job they applied to. Bullhorn does not have a native per-job knock-out question model — the equivalent is a Bullhorn Custom Object attached to the JobOrder, or a set of custom fields on JobOrder. We create a Custom Object (up to 10 on Bullhorn ATS) capturing each knock-out question and its type (boolean pass/fail, multi-select), then attach answer instances as Custom Object records per JobSubmission. This preserves the per-job answer context that would otherwise collapse if mapped to a static custom field on Candidate.

iRecruit custom screening questions are defined at the job level and capture free-text, numeric, or multiple-choice answers from applicants. These migrate as custom fields on Bullhorn JobSubmission so each candidate's answers attach to the specific application record rather than the candidate profile. Bullhorn ATS Growth limits custom fields per entity — we audit the field count during scoping and use Bullhorn's custom field limit structure (up to 20 of any combination of checkboxes, drop-downs, radio, pickers, and text types per entity) as the constraint.

iRecruit communication templates store mass personalised email body text and subject lines tied to specific candidate stages. Template text migrates as Note records attached to a designated Bullhorn User or a Bullhorn custom object created for template storage. Active sending queues and scheduled send-time triggers do not migrate — these are workflow-level features that require rebuild in Bullhorn's automation module. The template body text and subject lines are preserved for the admin to reconfigure in Bullhorn's email template system.

WOTC qualification category, qualifying date, and credit amount range per candidate migrate as custom fields on the Bullhorn Candidate record. Bullhorn has no native WOTC object. We preserve the full WOTC field set (category, qualifying date, credit range, status) so the customer's accounting records are complete. Re-enrollment with the destination payroll provider is a manual post-migration step — the filing window is typically 28 days from hire date, and failure to re-submit forfeits the credit.

iRecruit EEO demographic fields (race/ethnicity, gender, veteran status, disability status) and hiring outcome flags migrate as custom fields on the Bullhorn Candidate record. Bullhorn ATS does not have a native affirmative action reporting module at every tier — EEO reporting on Bullhorn is available through Bullhorn Recruitment Cloud or via third-party compliance tools. We preserve the underlying demographic data so it can feed a reporting tool of the customer's choosing. The generated EEO reports themselves do not migrate as formatted reports.

Where iRecruit has been configured with a custom export file pushing to Sage HRMS or MyPayrollHR, we migrate the export field schema as Bullhorn custom fields and custom objects. The mapping is driven by the customer's existing iRecruit export definition — we work from the export file structure to identify which fields are derived from which source object and replicate that relationship in Bullhorn's schema. Customers on other HRIS platforms will need to re-establish their export pipeline using Bullhorn's API or a Bullhorn marketplace integration post-migration.