Migrate from RecruitBPM to Bullhorn ATS & CRM

RecruitBPM Candidate records map 1:1 to Bullhorn Candidate. The RecruitBPM resume (stored as binary attachment) migrates as a file linked to the Bullhorn Candidate's document entity. Candidate status, skills, source attribution, and contact details transfer directly. We use Bullhorn's Candidate POST endpoint with the isDeleted=false flag preserved and populate the dateLastModified from RecruitBPM's activity log timestamp. Phone, email, address, and LinkedIn URL migrate to Bullhorn Candidate's name, email, phone, and webAddress fields.

RecruitBPM Client records map 1:1 to Bullhorn ClientCorporation. The client name, industry, billing address, primary contact, and relationship notes transfer directly. ClientCorporation is created before any Candidate or JobOrder import so that lookups from JobOrder to client are satisfied at insert time. We resolve RecruitBPM's client status (active/inactive) to Bullhorn's status field.

RecruitBPM Job Order records map to Bullhorn JobOrder with ClientCorporationId resolved via the Client-to-ClientCorporation mapping. Job Order status, requirements, compensation, location, and description transfer directly. The RecruitBPM pipeline stage name is mapped to Bullhorn's JobOrder status picklist values (e.g., New, Open, Full, Placed, Cancelled). We configure any non-standard status values as Bullhorn custom picklist entries before import.

RecruitBPM Placements map to Bullhorn Placement with references resolved to the migrated CandidateId and JobOrderId. Start date, end date, compensation (bill rate, pay rate, fee), and placement status transfer directly. Placement count per Candidate is tracked via Bullhorn's placementCount field on Candidate. We use Bullhorn's Placement POST endpoint with the Candidate and JobOrder lookup fields populated from the parent-record resolution table built during the Candidate and JobOrder migration phases.

RecruitBPM Talent Pools are segregated candidate collections by skill, location, or certification. Bullhorn does not have a native Talent Pool entity. We map pool membership to a Bullhorn Candidate custom multi-select picklist field (e.g., talent_pool__c) with each distinct pool name as a picklist value, preserving which candidates belong to which pool. If the customer has fewer than 15 distinct pools, we use a custom field; if more, we document the pool structure as a separate CSV reference table.

RecruitBPM interview records (scheduled time, interviewer, format, outcome notes) map to Bullhorn Appointment. Bullhorn Appointment is linked to a Candidate or Lead via the transactionType and candidateId/jobOrderId fields. For RecruitBPM recorded video interviews, we migrate the interview record as an Appointment with notes, but the video file itself migrates as a ContentDocument (binary blob) linked via ContentDocumentLink to the Candidate. Format (video, phone, in-person) migrates as an Appointment custom field.

RecruitBPM custom assessment results (form schema plus candidate responses) cannot map to a native Bullhorn entity because Bullhorn does not have an assessment form object. We migrate assessment results as structured Note records with a custom noteType field set to 'Assessment' and a body containing the form name, question, and response. The custom form schema itself is documented in the handoff inventory for the customer's Bullhorn admin to rebuild as a Bullhorn form or third-party assessment tool integration.

RecruitBPM activity records (calls, emails, SMS, voicemails, notes) tied to Candidates and Clients map to Bullhorn Note and Task entities. Email bodies migrate as Note with a noteType of 'Email'. Call logs migrate as Task with taskType='Call' and CallDuration in minutes. We link each activity to the migrated Candidate or ClientCorporation via the personID and clientCorporationID fields respectively. Bullhorn's REST API supports bulk inserts for Note and Task, which we use with batch sizes of 200 per request and rate-limit handling.

RecruitBPM's customizable Job Order pipeline stages (tenant-defined names and counts) map to Bullhorn's JobOrder status picklist values. We extract the full stage list during scoping, add any non-standard stage names as Bullhorn custom status values, and assign probability percentages per stage. The mapping table between RecruitBPM stage names and Bullhorn status values is documented in the migration handoff as a reference for the Bullhorn admin.

RecruitBPM's tenant-specific custom fields (across Candidates, Clients, Job Orders) are extracted in full during scoping. We map each to a Bullhorn custom field on the equivalent entity, provisioning the destination schema before data migration begins. Bullhorn custom fields follow the {fieldName}_c naming convention and are typed to match RecruitBPM's field type (text, number, date, picklist). Any RecruitBPM custom fields with no Bullhorn equivalent are documented in the handoff with a recommended Bullhorn custom field definition.

RecruitBPM platform users (recruiters, admins, hiring managers) map to Bullhorn User records by email match. Owner assignment on Candidates, Job Orders, and Placements is preserved by resolving the RecruitBPM userId to the Bullhorn User ID. Any RecruitBPM user without a matching Bullhorn User is placed in a reconciliation queue for the customer's Bullhorn admin to provision before the relevant records are migrated. Permissions, team structures, and role hierarchies are not migrated; we document the RecruitBPM role assignments for the admin to rebuild in Bullhorn.

Resume files, contracts, and onboarding documents stored in RecruitBPM migrate as Bullhorn ContentDocument records linked via ContentDocumentLink to the parent Candidate, ClientCorporation, JobOrder, or Placement. We verify file format compatibility (PDF, DOCX, RTF supported by Bullhorn) and flag any unsupported binary formats during scoping. Resume files are mapped to Bullhorn Candidate's primary resume field where applicable. Large attachments (over 25 MB) exceed Bullhorn's file size limit and are flagged for separate delivery as a ZIP archive.