Migrate from Recruiterflow to Bullhorn ATS & CRM

Recruiterflow Candidates map directly to Bullhorn Candidate. Standard fields (firstName, lastName, email, phone, status, source) map 1:1. Custom candidate fields from Recruiterflow migrate to Bullhorn custom Candidate fields. We source the Recruiterflow custom field definition from Recruiterflow support before extraction because the API does not return field definitions alongside record data. Off-Limits flags stored as candidate tags or custom fields in Recruiterflow migrate as Bullhorn Tags with a compliance category. ATS Growth (Team Edition) Bullhorn customers cannot use the API for candidate import; we flag this before migration begins.

Recruiterflow Contacts (client-side relationships) map to Bullhorn Contact. The company association links to Bullhorn ClientCorporation via the corporationID lookup. Contact lifecycle stages from Recruiterflow migrate as custom fields or picklist values on Bullhorn Contact depending on the customer's configuration preference during scoping.

Recruiterflow Jobs map to Bullhorn JobOrder. Job title, description, location, employment type, and owner migrate directly. Recruiterflow job pipeline stages map to Bullhorn JobOrder status and custom status fields. Each JobOrder requires an assigned User (the owner/recruiter) that we resolve via email matching against Bullhorn Users. JobOrder creation must precede any Candidate-to-Job associations (submissions, placements) because those references are foreign keys.

Recruiterflow Placements map to Bullhorn Placement. Placements carry compensation data (fee, startDate, endDate, payRate, billRate) and placement status. Bullhorn Placement requires a valid JobOrder reference and a Candidate reference; we validate both exist in Bullhorn before inserting Placements. If the Recruiterflow Job does not have a corresponding JobOrder in Bullhorn, we hold Placements in a reconciliation queue pending JobOrder creation.

Recruiterflow Companies map to Bullhorn ClientCorporation. Company name, address, industry, size, and associated contacts migrate directly. ClientCorporation is created before any related Contact, JobOrder, or Placement records because those objects reference corporationID as a lookup. Custom company fields migrate as Bullhorn custom fields on ClientCorporation using the schema sourced from Recruiterflow support.

Recruiterflow Deals track revenue opportunities tied to Companies. They map to Bullhorn Opportunity with deal value, stage, and owner migrated. Deal-specific fields like custom deal stages and client-specific probability mappings require Bullhorn Opportunity custom fields. Opportunity must have a valid ClientCorporation (Account) reference; we resolve this via company name or domain matching during the transform phase.

Recruiterflow Users map to Bullhorn User records. Owner assignments on Candidates, Jobs, Placements, Companies, Deals, and Activities all reference a Bullhorn User. We match Recruiterflow Users by email against Bullhorn Users and hold unmatched owners in a reconciliation queue for Bullhorn admin provisioning before migration resumes. ATS Growth edition does not include API access; if the destination Bullhorn is ATS Growth, User provisioning and record assignment require manual Bullhorn admin action.

Recruiterflow call logs migrate to Bullhorn Task records with TaskSubtype=Call. Call disposition, duration, and outcome stored in Recruiterflow's call activity endpoint migrate as Bullhorn custom Task fields. Activity timestamps preserve the original Recruiterflow activity date for timeline continuity. Bullhorn enforces 100,000 API calls per month; large call histories are chunked and scheduled across off-peak hours to avoid exceeding the monthly limit.

Recruiterflow notes migrate to Bullhorn Note records. Notes are associated with the parent record (Candidate, Contact, JobOrder, ClientCorporation, Opportunity, or Placement) via the Bullhorn note's targetID and targetType fields. Rich text content migrates as-is. Bullhorn's Note object does not support file attachments directly; any attached documents migrate separately via Bullhorn's document endpoints.

Recruiterflow exposes separate API endpoints for each custom activity type. Bullhorn has no generic custom activity object, so we map custom activity types to either Bullhorn Note records (for informational entries) or custom Task records with a custom TaskSubtype or type field that the customer defines during scoping. The choice depends on whether the custom activity represents a timestamped event (Task) or a free-text annotation (Note). We document the mapping per custom activity type in the migration specification.

Documents attached to Candidates, Jobs, Companies, or Placements in Recruiterflow (accessible via GET /api/external/document/get) are downloaded and re-uploaded to Bullhorn as attachments on the corresponding record. Bullhorn uses either its native Document object or Salesforce ContentDocument if the Bullhorn instance is on the Salesforce platform. We preserve document names and MIME types; binary content re-uploads as-is.

Recruiterflow sequence enrollments (email, SMS, WhatsApp, social) cannot migrate as active campaign memberships because Bullhorn Automation Engine uses a different cadence model. We export sequence membership and step data, then flag each enrolled Candidate with a Bullhorn Tag indicating the original sequence name and enrollment status (active, completed, stopped) so that the Bullhorn admin can re-enroll candidates in equivalent Bullhorn Automation Engine sequences post-migration. We do not migrate sequence step content or cadence logic.