Migrate from People First to Bullhorn ATS & CRM

People First employee records map to Bullhorn Candidate profiles. We extract name fields (firstName, lastName), job title, department reference, start date (dateOfHire), email, and phone. The Bullhorn Candidate record is the primary person record in Bullhorn's staffing data model. We resolve the target Candidate corporate ownership (the Bullhorn user or entity that owns the candidate record) from the migration user context. Custom employer-specific employee properties require field-by-field validation against any discovered People First export schema before migration.

People First user accounts (admin and end-user) with active status map to Bullhorn User records. We match by email address as the dedupe key. People First role assignments (admin, manager, employee) map to Bullhorn UserType and associated Bullhorn permission profiles. Users without an active Bullhorn license assignment are provisioned as inactive User records for reconciliation.

Organisational structure from People First maps to Bullhorn via a custom Department object (Front Office Growth/Enterprise) or as a text field on Candidate if the Bullhorn edition does not support Custom Objects (ATS Growth has zero custom objects, Bullhorn ATS has 2). We request the customer's Bullhorn edition during scoping and design the department mapping accordingly. Parent-child department hierarchy is preserved in custom fields or a separate Department lookup object.

Benefits data from People First (health, dental, retirement plans) requires Bullhorn Custom Object configuration because Bullhorn does not have a native Benefits object. We design a Benefit custom object with fields for plan type, provider, enrollment date, and coverage level, attached to the Candidate record. ATS Growth editions without custom object support flag Benefits for manual post-migration re-entry. We request the customer provides the specific benefit plan inventory during discovery.

PTO or time-off balance data maps to a Bullhorn Custom Object (TimeOffBalance) on Candidate with fields for leave type, accrued balance, used balance, and year-to-date accrual. Accrual history truncation risk applies if the People First export only provides current balances without historical accrual records. We validate the export against a sample of 10-20 employee records during discovery to confirm data completeness.

People First recognition and employee engagement records map to Bullhorn Note records (for recognition awards, kudos, and milestone acknowledgments) and Task records (for engagement surveys and pulse check activities). Recognition type, date, and issuer map to custom fields on the Note. We preserve the original People First timestamp as the Note body or ActivityDate on the Task. Value-level terminology mapping (People First recognition categories to Bullhorn-compatible labels) is resolved during the transformation phase with customer validation.

People First custom employer-specific employee fields have no publicly documented schema. We request the customer provides a field inventory during scoping (field names, data types, picklist values). Custom fields map to Bullhorn custom object fields on Candidate (customObject1s-customObject10s depending on edition) or as direct custom fields on the Candidate entity if the Bullhorn edition supports custom Candidate fields. ATS Growth: no custom objects available. Bullhorn ATS: 2 custom objects maximum. Front Office Growth/Enterprise: 10 custom objects with up to 55 fields each.

People First role assignments (admin, HR manager, employee tier) map to Bullhorn User profile assignments and a custom text field role_source__c preserving the original People First role name. Bullhorn's standard profile model (Standard, Recruiter, Sales, API Only, Read Only) requires the customer to confirm the target role mapping during scoping. Role hierarchies in People First that do not map directly to Bullhorn profiles are documented in the handoff summary.

Employee documents (employment contracts, policy acknowledgements) stored in People First require file-level extraction from the customer's export. We ingest documents as Bullhorn ContentVersion records and link them via ContentDocumentLink to the corresponding Candidate record. The file naming convention from People First export must include or be mappable to a Candidate identifier (email or employee ID) for linking. Documents without a resolvable candidate reference go to a reconciliation queue.

People First conflict resolution case records (mediation requests, grievance filings, resolution outcomes) are a core People First object with no direct Bullhorn equivalent. We map these to a Bullhorn Custom Object (ConflictCase) with fields for case type, parties involved (linked via Candidate lookups), filing date, status, and resolution summary. Bullhorn ATS and ATS Growth editions may lack custom object capacity; in those cases, conflict records are mapped to Note records with a custom type field for classification, and the customer is advised on the limitation.

People First organisational settings (company name, address, HR policy configurations) map to Bullhorn Corporate (ClientCorporation) settings and org-level configuration. The primary ClientCorporation record in Bullhorn holds the company-level data. Bullhorn's Corporate settings include industry classification, address, and billing contact fields that cover the standard org-wide configuration scope.

People First engagement activity records (if exported from the platform) map to Bullhorn Task records for discrete actions and Event records for scheduled meetings. Task records use TaskSubtype (Call, Email, Task) to classify the activity type. We preserve the original People First timestamp as ActivityDate on Task or StartDateTime on Event. Bullhorn's REST API is used for activity ingestion with batch chunking and rate-limit handling. Any People First activity data not captured in the export is noted as a gap in the migration report.