Migrate from PeopleForce to Bullhorn ATS & CRM

PeopleForce Employee records map directly to Bullhorn Candidate records. Name, email, phone, address, employment status, start date, and employee type transfer to Bullhorn Candidate fields. We use the Candidate email address as the dedupe key during import. Active and inactive employment status maps to Bullhorn Candidate status values. Employee type (full-time, part-time, contractor) maps to Bullhorn's employmentType field. The PeopleForce employee ID is preserved in a custom field peopleforce_id__c for audit and reconciliation.

PeopleForce Employee records that represent hiring managers, team leads, or approvers who should exist as business contacts in Bullhorn's CRM layer are mapped to Contact records in parallel with the Candidate mapping. The decision on which Employees map to Candidate versus Contact is made during scoping based on whether the Person is a job seeker or a client/contact in the Bullhorn context. Both mappings use the same source Employee record; the destination depends on the employee's role in the recruiting workflow.

PeopleForce Positions capture job title, department, employment type, and effective dates. Open positions in PeopleForce that represent recruiting needs map to Bullhorn Job records. The PeopleForce job title maps to the Bullhorn Job title; department maps to a Bullhorn custom field or Category. We configure the Job status, employment type, and salary range fields at migration time using the position's effective dates to set the Job startDate. Bullhorn Job has a much richer schema (skill requirements, qualifications, client corporation linking) that the position data populates partially.

PeopleForce PeopleRecruit vacancy records (job postings, application history, pipeline stages) map to Bullhorn Job records with candidate submissions tracked as submissions or CandidateProcess records. Open, closed, and draft vacancy status maps to Bullhorn Job status (Open, Closed, Hired). Application history migrates as Bullhorn submission records attached to the Job, preserving the candidate's application date and stage progression. Job board multiposting settings do not transfer; we document the configuration for admin rebuild in Bullhorn.

PeopleForce profile photos, bio data, emergency contacts, and skills are stored as structured sub-objects on Employee. Bullhorn Candidate supports custom fields and Custom Objects for extended data. Skills migrate as Bullhorn Candidate custom fields (skillText fields or a skills Custom Object). Emergency contacts and profile metadata migrate to a Bullhorn Candidate Custom Object. Bullhorn ATS edition limits 2 Custom Objects per entity; Growth/Enterprise allows 10. We configure the Custom Object schema during migration scoping and validate against the customer's Bullhorn edition.

PeopleForce leave balances and request history have no native Bullhorn equivalent because Bullhorn is a recruiting ATS, not an HRIS. Leave data migrates as a Bullhorn Custom Object (LeaveRecord) attached to the Candidate or Contact. We preserve leave type, balance, accrual date, and approval status as Custom Object fields. Policy definitions themselves are not migratable as code; we deliver a written policy inventory document for the admin to reconfigure in Bullhorn's policy settings if supported by their Bullhorn edition.

PeopleForce performance review cycles, submitted review forms, and scores are migrated as a Bullhorn Custom Object (PerformanceReview) linked to the Candidate or Contact. Completed review scores and dates transfer; the review form builder configurations (questions, rating scales, weighting) do not migrate as code. Bullhorn's form builder is used to recreate review templates. The review Custom Object stores the submitted score, reviewer name, review period, and any free-text feedback as historical records.

PeopleForce employee documents (contracts, ID copies, certifications) migrate as Bullhorn ContentDocument records attached via ContentDocumentLink to the corresponding Candidate or Contact record. We extract document metadata (filename, upload date, document type) and content from PeopleForce's API. Bullhorn supports document storage per record; the customer's Bullhorn storage allocation applies to migrated documents.

PeopleForce Kudos and Recognition records are migrated as a Bullhorn Custom Object (Recognition) linked to the Employee (Candidate/Contact). Bullhorn does not have a native recognition module. We preserve the giver, recipient, message, and timestamp as Custom Object fields. Bullhorn ATS edition limits 2 Custom Objects per entity; we coordinate the Recognition Custom Object placement during scoping to avoid conflicting with other custom object assignments.

PeopleForce onboarding and offboarding checklist task completion status and history migrate as Bullhorn Task records attached to the Candidate. Each checklist item becomes a Task with a status matching the completion state in PeopleForce. The checklist templates themselves are platform-specific and do not migrate; we document the checklist structure in a written handoff so the Bullhorn admin can rebuild onboarding task templates in Bullhorn Tasks or a custom onboarding workflow.

PeopleForce custom fields on the Employee object are inventoried during discovery, typed (text, number, date, dropdown), and mapped to Bullhorn equivalent custom fields on the destination entity (Candidate, Contact, or Job). Bullhorn enforces a finite set of custom field edit types (free text, dropdown, checkbox, mini picker, and others per Bullhorn field options). We map PeopleForce data types to the nearest Bullhorn field type and flag any type conversions (e.g., PeopleForce multi-select dropdowns to Bullhorn multi-select picklist).

PeopleForce custom fields on Position, Leave, Performance Review, and other HR objects map to fields within Bullhorn Custom Objects created for each HR module. We pre-create the Custom Object schema in Bullhorn during the sandbox validation phase, including all custom field definitions, before importing any HR data. Bullhorn Growth and Enterprise editions allow 10 Custom Objects per entity with 55 fields each; Bullhorn ATS limits 2 Custom Objects per entity. We validate the destination edition against the migration scope before production load.

PeopleForce employment history (prior positions, tenure, compensation changes) stored across linked records is consolidated into a Bullhorn Candidate employment section. We flatten prior position records into Bullhorn Candidate workHistory custom fields or a WorkHistory Custom Object per candidate. Compensation history is migrated as a separate Custom Object (CompensationHistory) attached to the Candidate, as Bullhorn does not have a native compensation tracking field on Candidate. The customer should confirm whether their Bullhorn edition supports the required number of custom objects before committing to a full compensation history migration.

PeopleForce Workflows built on attribute-based triggers (e.g., trigger an onboarding task when a new hire start date arrives) do not migrate as automation code. Bullhorn's workflow engine uses a different trigger and action model. We deliver a written workflow inventory documenting every active PeopleForce workflow: its trigger, conditions, actions, and the recommended Bullhorn equivalent (Bullhorn Tasks + Automation rules or a Bullhorn partner workflow tool). The customer's Bullhorn admin or a Bullhorn implementation partner rebuilds them post-migration.