Migrate from Recruit ATS by HR Cloud to Bullhorn ATS & CRM

Recruit ATS Job records map to Bullhorn JobOrder. We extract title, description, location, department, employment type, and status (open/closed/archived). Custom request fields attached to the job posting map to Bullhorn custom fields on JobOrder, which we pre-create in the destination tenant before migration. The job's ordinal position in Recruit ATS is preserved as a sort field but Bullhorn Kanban ordering is managed via its own column configuration rather than a global ordinal.

Recruit ATS Candidate records map directly to Bullhorn Candidate. Standard fields (name, email, phone, address, work history, education) migrate to Bullhorn's Candidate entity. The primary resume file migrates as a Bullhorn Candidate attachment (ContentDocument with binary blob), preserving original filename and MIME type. If the Bullhorn destination uses ATS v2, Candidate records are required before Application V2 records can be created.

Recruit ATS Application records (the junction between Candidate and Job) map to Bullhorn JobSubmission under ATS v1 or Application V2 under ATS v2. We extract applied date, current stage, source channel, and rejection reason. Bullhorn's ATS v2 data model introduces Application V2 as a Bullhorn Recruitment Cloud custom object with different field mapping requirements from ATS v1; we confirm the destination tenant's data model during scoping and configure the import path accordingly. Application-level custom fields require value-mapping against Bullhorn's field type constraints (character limits, picklist values) before import.

Recruit ATS Pipeline Stages are fully custom with ordinal positions and Kanban column names. We extract the stage name, ordinal position, and any stage-specific configuration. Bullhorn JobStage values are defined in the Bullhorn tenant settings and must be pre-created before JobSubmission import; we map Recruit ATS stage names to Bullhorn stage values by ordinal order and produce a stage mapping sheet. Kanban column order is preserved via the ordinal mapping but Bullhorn's Kanban view uses its own column ordering rules.

Recruit ATS Tags are string labels applied to Candidates and Jobs. We export the full tag set and apply them as Bullhorn CandidateTag records linked to the corresponding Candidate. Multi-tag records migrate as arrays and create multiple CandidateTag associations. Bullhorn does not have a native tag system for JobOrder, so Job-level tags from Recruit ATS map to a custom text field on JobOrder.

Recruit ATS supports entity-type custom fields that link a Candidate record to another Candidate or Job record. Bullhorn does not support this cross-record entity linking pattern natively. We detect these fields during the pre-flight audit, preserve the linked-record IDs in a dependency map, and post them to a re-linkage guide. The customer's Bullhorn admin manually re-establishes these links after migration using Bullhorn's custom fields or a lookup tool. We flag any compliance-critical linkages (such as candidate-to-referrer relationships) separately so they are not missed.

Resume files, cover letters, and uploaded documents attached to Candidates and Jobs migrate as Bullhorn ContentDocument records with the original filename and MIME type preserved. Large attachments (over 5 MB) are chunked for API upload using Bullhorn's binary attachment endpoint with retry logic. We preserve the attachment's association to the parent record (Candidate or JobOrder) using ContentDocumentLink.

Notes attached to Candidates in Recruit ATS migrate as Bullhorn Note records linked to the Candidate via ContentDocumentLink. We preserve the note body as plain text, the original author name, and the creation timestamp. Thread structure (replies to notes) does not migrate; all notes land as flat entries in Bullhorn's Note list against the parent Candidate.

Recruit ATS Owner records map to Bullhorn CorporateUser. We resolve by email match against the Bullhorn destination tenant's user table. Any Recruit ATS Owner without a matching Bullhorn CorporateUser goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Owner assignments on Candidate, JobOrder, and JobSubmission migrate as OwnerID references after user resolution is complete.

Recruit ATS Jobs have a client or company reference that maps to Bullhorn ClientCorporation if the destination tenant uses Bullhorn's CRM layer. We extract the client name from Recruit ATS job records and either match against an existing ClientCorporation in Bullhorn or create a new ClientCorporation record. This step is scoped during discovery; if the customer does not use Bullhorn CRM, the client reference migrates as a text field on JobOrder.

Recruit ATS tracks application status changes over time. We extract the full status history with timestamps and migrate it as a series of Note records attached to the JobSubmission, each noting the previous stage, new stage, and timestamp. Bullhorn does not natively store application stage-change history as a structured object, so the history is preserved in searchable note form for audit purposes.

Recruit ATS automation rules (knock-out question triggers, SMS invite sequences, email sequences) are not exposed via the public API and cannot be exported as structured data. We do not migrate automation rules. During the pre-flight audit we produce a written automation registry listing every active rule with its trigger, conditions, and actions. The customer's Bullhorn admin uses this registry to rebuild equivalent automations in Bullhorn Automation, Herefish, or another Bullhorn-native automation tool post-migration.