Migrate from E-Staff to Bullhorn ATS & CRM

E-Staff Candidate records map directly to Bullhorn Candidate. E-Staff stores candidate contact info, skills, employment history, and staffing status in its Candidate object. We preserve the candidate's original record ID as a custom field e_staff_candidate_id__c for cross-system audit. Bullhorn's Candidate is the parent record for all subsequent JobSubmission and Placement objects, so it must insert first. E-Staff custom fields on Candidate are audited during scoping and mapped to Bullhorn standard fields or Custom Objects depending on Bullhorn edition limits.

E-Staff JobOrder records map to Bullhorn JobOrder. JobOrder in Bullhorn represents an open req with fields for title, description, status, and pay/compensation range. The E-Staff job classification or skill requirement maps to Bullhorn's skills or custom fields. Bullhorn's JobOrder is the parent record for JobSubmission records, so it inserts before any candidate submission records. If E-Staff tracks multiple job statuses, we configure Bullhorn JobOrder Status values during the schema phase.

E-Staff Placement records map to Bullhorn Placement. Placement is the core staffing transaction record representing a candidate placed at a client. E-Staff stores effective start date, end date, pay rate, bill rate, and assignment status in this object. We map effective-dated compensation rows as Bullhorn custom fields on the Placement record: placement_effective_date__c, placement_base_pay__c, placement_bill_rate__c, and placement_pay_rate__c preserve the staffing history audit trail. Bullhorn ATS Growth edition may have limited placement fields; Front Office Growth and Enterprise support Custom Objects for additional staffing attributes.

E-Staff Client records map to Bullhorn ClientCorporation. ClientCorporation is Bullhorn's company record representing the hiring client. The E-Staff client name, address, industry classification, and account manager fields map to Bullhorn ClientCorporation standard fields. ClientCorporation must insert before any Placement or JobOrder referencing it, so that the Bullhorn clientID foreign key resolves at migration time. If E-Staff stores client-specific custom fields (preferred industries, MSA status, tier classification), these map to Bullhorn ClientCorporation custom fields.

E-Staff client contact records map to Bullhorn ClientContact. ClientContact represents the hiring manager or procurement contact at the client company. E-Staff stores contact name, email, phone, title, and relationship status in this object. We resolve the ClientCorporation reference by matching client name, then set the corporationID on ClientContact to the newly inserted Bullhorn ClientCorporation. ClientContact must insert after ClientCorporation to satisfy Bullhorn's required corporationID lookup.

E-Staff Employee records (standard HRMS object) and Candidate records (staffing object) are distinct in E-Staff's unified schema. Both map to Bullhorn Candidate because Bullhorn uses Candidate to represent both temporary workers and direct-hire employees on the same record type. We split by E-Staff record type: Employee records flagged as internal staff map to Bullhorn Candidate with a custom field record_origin__c = 'E-Staff Employee'; Candidate records map with record_origin__c = 'E-Staff Candidate'. The origin field preserves the E-Staff object lineage for reporting.

E-Staff Department records map to Bullhorn Department if the destination Bullhorn org includes Bullhorn Middle Office. Bullhorn Middle Office handles the back-office org structure including departments and cost centers. If the customer's Bullhorn deployment does not include Middle Office, we map Department to a Bullhorn custom field or flag it as out-of-scope for the admin to configure post-migration.

E-Staff payroll history rows (effective-dated compensation records) do not map to a standalone Bullhorn object. Bullhorn stores payroll and timesheet data in Bullhorn Middle Office, which is a separate module from the ATS. We map effective-dated payroll rows to custom fields on the Bullhorn Placement record: effective_date__c, pay_rate__c, billing_rate__c, overtime_eligible__c. Each payroll row becomes a separate Placement insert with historical dates, preserving the compensation audit trail. Customers needing full payroll history in Bullhorn should consider adding Middle Office; we flag this as a separate scope recommendation during scoping.

E-Staff allows user-defined custom fields with no enforced naming convention, so every E-Staff custom field must be audited, typed, and explicitly mapped during scoping. Bullhorn's Custom Object system requires Bullhorn Support to create each Custom Object, with field-type limits per object (up to 20 checkbox/dropdown/picker fields and up to 20 text fields). Bullhorn ATS Growth has 0 Custom Objects; Bullhorn ATS caps at 2; Front Office Growth and Enterprise allow 10 Custom Objects with 55 fields each. We pre-create the destination schema before migration, configuring Bullhorn Custom Objects via support ticket, and then map E-Staff custom field values into the typed Bullhorn fields. Any E-Staff custom fields that exceed Bullhorn's edition limit are flagged for the customer to either upgrade or consolidate into fewer Bullhorn standard fields.

E-Staff engagement records (internal notes, call logs, email threads attached to a Candidate or Placement) map to Bullhorn Task, Event, and Note records. Call engagements map to Bullhorn Task with TaskSubtype = Call; email threads map to Bullhorn Task or Note depending on content type; internal recruiter notes map to Bullhorn Note. The Bullhorn REST API supports these as entity types with bulk insert capability. Parent-record resolution (linking tasks to the correct Candidate, JobOrder, or Placement) is resolved by matching E-Staff's foreign key references to the newly inserted Bullhorn IDs before each batch commits.

E-Staff staff user accounts map to Bullhorn User records. We match by email address during the migration. Any E-Staff Owner referenced on Candidate, Placement, or JobOrder records is resolved to a Bullhorn User by email lookup before the referencing records insert. Owners without a matching Bullhorn User go to a reconciliation queue; the customer's Bullhorn admin provisions missing Users before record import resumes. Bullhorn supports active and inactive User states; we map the E-Staff active/inactive flag to the Bullhorn isActive field.

E-Staff tracks candidate status transitions (e.g., New, Screening, Interview, Placed, Archived) as audit rows or effective-dated fields. Bullhorn Candidate does not natively store status history as separate records. We map the current candidate status to Bullhorn's Candidate status field and store the most recent prior status in a custom field last_legacy_status__c. If the customer requires full status history for compliance or audit purposes and the Bullhorn edition supports Custom Objects, we create a CandidateCustomObject with status and effective_date fields for each transition row.