Migrate from ZingHR to Bullhorn ATS & CRM

ZingHR employee records map to Bullhorn Candidate as the primary person record. We extract personal details (name, DOB, address, contact), employment details (department, designation, date of joining, employment type), and employment history. The Bullhorn Candidate record serves as the parent for placement, attendance notes, and payroll custom fields. We map ZingHR employee status (active, on leave, separated) to Bullhorn Candidate status, and flag any ZingHR e-Separation records as inactive Candidate records with separation date preserved.

ZingHR department hierarchies map to Bullhorn Corporate records representing the customer's own organizational structure. We extract cost-center assignments and org chart reporting lines from ZingHR's organization report. Bullhorn Corporate records hold company-level details; individual department-level granularity beyond the top-level company name requires a custom field or a custom object (e.g., Internal_Department__c) if Bullhorn's standard Corporate fields are insufficient.

ZingHR location records include geo-coordinates, address details, and location-specific configurations. We extract location names and structured address data from ZingHR's reports. Bullhorn stores addresses on Corporate records and on JobOrder records. For multi-location ZingHR customers, we map each ZingHR location to a Bullhorn Corporate address entry. Geo-coordinates are stored as custom fields on the Corporate record if Bullhorn's standard address block does not capture them.

ZingHR attendance punch-in and punch-out data in raw timestamp format is aggregated into daily attendance summaries to avoid inflating Bullhorn record counts. Aggregated summaries are stored as Note records linked to the Candidate, with the note body containing attendance statistics (days present, days absent, late arrivals, overtime hours) and the note date set to the period end date. Raw timestamp records are not individually migrated to Bullhorn because Bullhorn does not have a native attendance or time-tracking object.

ZingHR leave types (earned leave, sick leave, casual leave, compensatory off) and their entitlement, accrual, used, and balance values map to a Bullhorn Custom Object (Leave_Balance__c) linked to the Candidate. Bullhorn Support must create this custom object because it is not self-service. The number of leave types drives the number of custom object instances per employee. We verify compensatory off balances in ZingHR before cut-off since some users report these do not auto-refresh correctly.

ZingHR payslip data including earnings, deductions, and net pay per pay period maps to a Bullhorn Custom Object (Payroll_History__c) linked to the Candidate or Placement. We sequence records by pay date and handle month-end cutoffs carefully. Bullhorn does not have a native payroll object; pay rate and bill rate are stored as fields on the Placement record, but full payroll history requires the custom object. Custom Object availability is limited by Bullhorn edition: Front Office Growth/Enterprise allows 10, ATS allows 2, and ATS Growth allows 0, which constrains how many payroll periods or additional HR data types can be stored.

ZingHR PMS module goal progress, ratings, and reviewer comments map to a Bullhorn Custom Object (Performance_Review__c) linked to the Candidate. We extract goal titles, alignment to business outcomes, rating values, and reviewer metadata. Bullhorn has no native performance management module; performance history is not surfaced in standard Bullhorn reporting, so the custom object provides a historical record accessible via Bullhorn search and list views. The customer's Bullhorn edition limits how many additional custom objects can be created alongside leave balance and payroll history.

ZingHR employee documents (offer letters, ID proofs, experience letters) are downloaded individually from the ESS portal and mapped to Bullhorn ContentDocument records attached via ContentDocumentLink to the Candidate. We map ZingHR document categories to Bullhorn document type values and flag any documents that exceed Bullhorn's supported attachment size limits. Documents are imported after the Candidate record is created to satisfy the parent-lookup requirement.

ZingHR manager-employee associations are extracted as reporting lines and replicated in Bullhorn by populating the recruiter and supervisor fields on the Candidate record. For Bullhorn's staffing context, the manager relationship maps to the assigned recruiter on a candidate's record and the hiring manager field on related job orders. Bulk manager-change records in ZingHR that are in a pending Maker-Checker approval state are flagged during scoping and excluded from migration until the approval is completed or the admin resolves them in ZingHR before cut-over.

ZingHR Talent Acquisition job postings and active candidate pipelines map to Bullhorn JobOrder records. Each ZingHR job requisition becomes a JobOrder with status, title, description, and requirements fields populated. ZingHR candidate profiles in the recruitment pipeline map to Bullhorn JobApplication records linked to the JobOrder and Candidate. Onboarding checklists from ZingHR do not migrate as workflow items; they are documented in the handoff inventory for the customer's Bullhorn admin to recreate using Bullhorn Automation or Bullhorn Onboarding.

ZingHR Attribute Master API exposes company-specific custom fields and units that may not map to any standard Bullhorn field. We enumerate all ZingHR custom attributes during scoping, classify them as either inline custom fields on the Candidate (if Bullhorn's available custom field slots are sufficient) or as fields within a custom object, and coordinate with Bullhorn Support for custom object setup. Picklist and formula-type custom fields in ZingHR require explicit mapping to Bullhorn picklist values or formula fields respectively.

ZingHR users who are active in the system map to Bullhorn User records. We extract users by email match to the Bullhorn destination environment. Any ZingHR user without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision before record import resumes, because OwnerId references on Bullhorn records are required and cannot be null for most standard objects.