Migrate from Cornerstone Recruiting to Bullhorn ATS & CRM

Cornerstone Requisition records map to Bullhorn Job Order. RequisitionId becomes JobOrder.id for reference tracking; RequisitionName maps to Title; PositionId maps to a custom text field positionId__c (Bullhorn Job Order has no native PositionId equivalent). DivisionId and LocationId from the OU hierarchy map to Bullhorn's Category and Branch or a custom Location lookup. We pre-create the mapping between source OU types and Bullhorn Locations during scoping because Cornerstone OUs are portal-defined and not discoverable via a schema API.

Cornerstone Candidate records (Name, Email, Phone, Address, Ethnicity) map directly to Bullhorn Candidate. The Candidate object in Bullhorn is the primary person record and includes all contact information, employment history, and skills. We preserve the Cornerstone candidate ID in a custom field cornerstone_id__c for reconciliation and audit. Bullhorn Candidate does not have a native ethnicity field, so ethnicity data migrates to a custom text field if compliance reporting requires it.

Cornerstone JobApplicant (the intersection of Candidate and Requisition) maps to Bullhorn JobSubmission. ApplicationReceivedDateLocal maps to dateAdded; AverageRating maps to a custom rating field. CandidateType distinguishes between Employee, Contingent, and Candidate types and maps to the Bullhorn submission's employmentType field. PositionId links the submission to the migrated Job Order.

Cornerstone Application records represent a candidate's full application state and workflow status within a requisition. We map Application status to Bullhorn's Placement record and its associated status workflow. Applications that result in a hire become Placements with status = Active; those that do not remain as JobSubmissions with status = Placed or a custom Closed status. The mapping requires confirming the customer's Bullhorn placement track (ListBed) configuration before migration.

Cornerstone OU types (Cost Center, Division, Legal Entity, Location, Position) have no direct Bullhorn equivalent. We map source Locations to Bullhorn Locations, source Divisions to a custom Division field on the Job Order or Company record, and source Legal Entities to Bullhorn Company records with a custom type field. This is a manual mapping exercise during scoping because OUs are portal-defined and vary by customer. We do not migrate OU hierarchies that have no functional equivalent in Bullhorn's staffing model.

Cornerstone Requisition custom fields (returned by GET Job Requisition Custom Field API) map to Bullhorn Job Order custom fields. We create the Bullhorn custom fields via the Field Mappings admin interface before migration, matching field types where possible. Picklist-type custom fields in Cornerstone map to Bullhorn picklists; text fields map to text fields. Bullhorn Field Mappings allows administrators to choose what fields display, where, and what values they contain, which we configure before loading data.

Cornerstone Application custom fields map to Bullhorn custom fields on JobSubmission or the related Placement record. The target object depends on when in the workflow the field is populated: pre-placement fields target JobSubmission; post-placement fields target Placement. We confirm the customer's Bullhorn placement track schema before migration and pre-create fields accordingly. Bullhorn's custom field creation via Field Mappings supports text, number, date, picklist, and Boolean types.

Cornerstone candidate attachments (resumes, cover letters, supporting documents) migrate to Bullhorn Candidate attachments. We extract file metadata and content via the Attachment API and re-associate them with migrated Bullhorn Candidate records using candidate ID matching. Bullhorn supports resume parsing into structured fields (skills, experience, education) as a post-migration step; we preserve the raw attachment as-is during migration to avoid data loss from parsing errors.

Cornerstone Application Workflow stages are portal-specific and define stage progression through the hiring process. We map each Cornerstone workflow stage to a Bullhorn JobSubmission status or a custom status value on the Placement record. Bullhorn's workflow automation (Bullhorn Automation) handles stage transitions post-migration; we do not migrate the workflow logic as code. The migration delivers a written stage mapping table documenting every Cornerstone stage and its Bullhorn equivalent.

Cornerstone creates an Employee record in Core HR upon hire, with employment status, compensation history, and manager assignment. Bullhorn does not have a native HR Core object; contractor and contingent worker records map to Bullhorn Contact (for client contacts) or Placement (for placed candidates). We split post-hire records based on the customer's intended use: employee-facing data stays in a written handoff document for the customer's HRIS; placed candidate data migrates as Placement records.

Cornerstone Requisition owners and hiring managers map to Bullhorn User records. We match by email address during migration. Any Cornerstone owner without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes. Bullhorn's User object includes firstName, lastName, email, and status (active/inactive), which we map from the Cornerstone owner record.

Cornerstone's Bulk API explicitly does not support loading data to secure custom fields and sensitive PII fields (SPII). We identify which custom fields are marked as sensitive in the Cornerstone schema during discovery and exclude them from bulk import operations. Post-migration, the customer must manually re-enter or securely re-provision these fields in Bullhorn. We deliver a written inventory of every excluded field with its label, data type, and sample values (for format reference only, with no actual PII content) so the customer's Bullhorn admin can rebuild them.

Cornerstone's Bulk API settings object with LoadPrimaryKey (0 = User ID, 1 = GUID) and default password behavior applies only to Cornerstone's Core HR Bulk API. Bullhorn uses a different authentication and user provisioning model and does not accept bulk user loads via a comparable mechanism. We handle owner matching via email resolution against Bullhorn's existing User table rather than bulk user creation.