Migrate from Candidate Manager to Bullhorn ATS & CRM

Candidate Manager candidate records map to Bullhorn Candidate. We extract name, contact details, resume file, application date, source attribution, and status stage from CSV exports. The Candidate Manager resume file is stored as a resume blob or file reference; we download and attach it to the Bullhorn Candidate record via the resume field or ContentDocument attachment. Ranking and pre-profiling scores from Candidate Manager transfer as custom number fields on the Bullhorn Candidate record because Bullhorn has no native scoring object. Application date maps to dateAdded; source attribution maps to source. Candidate Manager status stage (Applied, Under Consideration, Interviewing, Hired) is preserved in a custom text field cm_original_stage__c and mapped to the nearest Bullhorn Candidate status.

Candidate Manager job orders carry requisition metadata, department, location, and open date. We map these as Bullhorn Job Order records. Title, description, address, and employment type transfer directly. The Candidate Manager job ID is preserved in a custom field cm_job_id__c for reconciliation. Custom fields attached to job orders in Candidate Manager are discovered during the scoping call and mapped to Bullhorn custom fields or Job Order standard fields depending on type match. Bullhorn's Job Order requires an assigned User as the recruiterOwner before insert.

Candidate Manager uses fixed stage names that cannot be reconfigured at the workflow level. We preserve the original stage label as a custom property cm_original_stage__c on the Bullhorn Candidate record. For each Candidate Manager stage (Applied, Under Consideration, Interviewing, Hired, etc.), we map to the nearest Bullhorn Candidate status value and note the mapping in the migration specification. If the customer has configured Candidate Manager stages beyond the standard set, we treat them as custom picklist values to add to the Bullhorn Candidate status field during schema setup.

Numeric ranking and screening scores from Candidate Manager are stored as candidate properties. We transfer these as-is into Bullhorn custom number fields (cm_ranking_score__c, cm_preprofiling_score__c) on the Candidate record. Bullhorn does not have a native scoring object at the ATS tier, so these values land as custom fields. They are searchable in Bullhorn's additional criteria filters and visible on the Candidate record. We flag any score that falls outside the range supported by Bullhorn's number field type during validation.

Records created or modified via the Candidate Manager hiring manager portal carry an owner attribution field. We preserve this as a custom text field cm_hiring_manager__c on the Bullhorn Candidate record. If the hiring manager does not exist as a formal Bullhorn User, we flag the record for the customer's admin to provision the User account and update the assignment post-migration. Bullhorn requires a valid OwnerId (User reference) on most standard record types; a null or invalid owner causes insert failure.

Agencies submitting candidates through the Candidate Manager staffing portal are tracked as submission sources. We map agency name and submission ID to the Bullhorn Candidate record using the source field and a custom field cm_agency_submission_id__c. Agency-specific notes attached to the submission are preserved in a custom text field cm_agency_notes__c on the Candidate record. Bullhorn's source picklist is extended to include agency names that do not match existing Bullhorn source values during schema setup.

Candidate Manager extends into onboarding for hired candidates. We migrate onboarding task completion status and document references for candidates with a Hired stage. Task status maps to Bullhorn Onboarding task records if the customer licenses Bullhorn Onboarding (formerly Able). Document references migrate as ContentDocument attachments linked to the Placement record. We flag any e-signature or form-fill data that does not export cleanly from Candidate Manager; this data typically requires manual re-entry by the customer's onboarding team post-migration.

Candidate Manager's reporting module generates aggregate data exports covering historical hiring funnel metrics. These records reflect a point-in-time snapshot from Candidate Manager and do not represent live Bullhorn data. We deliver them as supplementary records in a Bullhorn Custom Object (cm_funnel_metrics__c) so the customer retains the historical context. The data is marked with cm_source_created_date__c to distinguish it from Bullhorn-native reporting. Rebuilding equivalent funnel reporting in Bullhorn Analytics or Canvas is documented separately as a post-migration admin task.

Candidate Manager custom fields at the candidate level are not documented in a machine-readable schema. We discover them during the scoping call by reviewing a sample export and a walkthrough of the Candidate Manager admin interface. Each discovered custom field is mapped to a Bullhorn custom field on the Candidate object (with __c suffix per Bullhorn convention). Field type mapping: text to Text, date to Date, number to Number, picklist to Picklist (with values extended). Required fields in Candidate Manager are flagged for Bullhorn field validation rules.

Candidate Manager custom fields at the job order level are mapped to Bullhorn custom fields on the Job Order object. We follow the same discovery and type-mapping process as candidate-level custom fields. Bullhorn Job Order supports up to 55 custom fields per Custom Object configuration; if the customer's Job Order custom field count exceeds this, we prioritize the fields most critical to placement workflow and flag the remainder for manual entry or a second-pass migration.

The application relationship between a Candidate record and a Job Order in Candidate Manager maps to Bullhorn's CandidateSubmission or JobOrderCandidate relationship. Bullhorn's REST API requires that both the Candidate and the Job Order exist before the relationship record is inserted. We sequence the migration so that Job Orders are loaded first (with recruiterOwner resolved to a Bullhorn User), then Candidates (with status mapped), then relationship records (with candidateID and jobOrderID resolved). This dependency order prevents the foreign-key violations that occur if the relationship is written before the parent records.

Candidate Manager user and owner records map to Bullhorn User. We resolve owners by email match against the Bullhorn User table. Any Candidate Manager Owner without a matching Bullhorn User goes to a reconciliation queue for the customer's admin to provision the User before record import resumes. Active Candidate Manager users who are not provisioned in Bullhorn will have their records assigned to a system migration user temporarily, with reassignment documented for the admin to complete post-migration.