Migrate from ZenHR to Bullhorn ATS & CRM

ZenHR Employee records map to Bullhorn Candidate. The ZenHR Personal section (name, date of birth, nationality, address, contact details) maps to Bullhorn Candidate fields (firstName, lastName, email, phone, address). The Professional section (job title, department, employment type, start date) maps to Candidate custom fields or standard fields depending on the customer's field inventory. The Financial section (salary, bank details) has no native Bullhorn home and is migrated as Bullhorn custom fields on the Candidate record. We discover all active ZenHR custom fields during the pre-migration audit and pre-create the corresponding Bullhorn custom fields before import begins.

ZenHR's Financial section (salary components, bank details, payment frequency) cannot map to a native Bullhorn object because Bullhorn has no payroll engine. We migrate salary bands, compensation type, and bank information as Bullhorn Candidate custom fields (up to 55 per custom object). If the customer requires full payroll history, we flag that Bullhorn Back Office is the correct destination and migrate payroll data as a written data dictionary alongside the migration rather than inside it.

ZenHR Branches map to Bullhorn Corporations. Each Branch's name, location, and department structure map to Corporation name, address, and Corporate Departments. We preserve the cross-branch assignment logic by mapping each Employee's branch reference to the corresponding Bullhorn Corporation. Bullhorn Corporation records must be created before Candidate records so that the corpID lookup is satisfied at insert time.

ZenHR Levels (seniority tiers) and Positions (job titles within levels) map to Bullhorn Corporate Departments and Job Order title fields. We reconstruct the ZenHR organizational hierarchy as Bullhorn Corporate Departments with parent-child relationships, and preserve the Position name as a custom field on the Candidate record to retain job title history.

ZenHR Documents (contracts, certifications, IDs, offer letters) migrate as Bullhorn ContentDocument records attached via ContentDocumentLink to the corresponding Candidate. We transfer document type, expiry date, upload date, and e-signature audit trail metadata. Binary files are re-uploaded via Bullhorn's REST API using multipart form encoding. Expiry alerts do not migrate; Bullhorn's document expiry reminder feature requires manual reconfiguration post-migration.

ZenHR Timeoff records (leave balance, accrual transactions, request history) have no native Bullhorn equivalent. We migrate the current leave balance as Bullhorn Candidate custom fields (e.g., annual_leave_balance__c, sick_leave_balance__c) and the transaction history as a Note attached to the Candidate with a structured text body listing accrual dates, deductions, and balances. Pending leave requests are flagged during scoping for the customer to handle manually post-migration.

ZenHR Employee Loans with principal, remaining balance, and repayment schedule have no native Bullhorn object. We migrate active loan status, outstanding principal, and monthly repayment amount as Bullhorn Candidate custom fields. Full loan history (past repayments, interest calculations) migrates as a structured Note on the Candidate record. If Bullhorn Back Office is in scope, loan deductions can be modeled as payroll items in that module separately.

ZenHR Overtime records (type, hours, rate, date range) migrate as Bullhorn Candidate custom fields for current-period overtime totals, with historical overtime entries captured as Notes on the Candidate record. ZenHR's configurable Overtime Types map to custom picklist values on the overtime custom field. Bullhorn's native overtime tracking is not available as a standard ATS feature.

ZenHR Termination records with effective date, termination reason, and EOSB (End-of-Service Benefit) or gratuity settlement amount migrate as Bullhorn Placement records in a closed status (placement type = Direct Hire, status = Stopped Working) with a Note containing the EOSB amount, gratuity calculation basis, and final settlement details. The termination effective_date is preserved as the Placement endDate rather than the migration timestamp to maintain audit integrity under MENA labor law.

ZenATS Candidates and Vacancies are a distinct ATS module within ZenHR. Candidate records, pipeline stages, and interview data map to Bullhorn Candidate with the ZenATS vacancy stage preserved as a custom field on the Candidate record. However, ZenATS SMS and email communication bodies are not exposed via the ZenHR standard API — only metadata (timestamps, template names) is available. We flag this gap during scoping and recommend a manual ZenATS export of communication history before migration begins. The communication metadata migrates with the Candidate; the bodies do not.

ZenATS Vacancies map to Bullhorn Job Orders. The vacancy title, description, required skills, and location map directly. The ZenATS pipeline stage history (applied, screening, interviewing, offer, hired, rejected) is preserved as Bullhorn Job Submission status values on the Candidate record's associated Job Submission. We reconstruct the pipeline as Bullhorn Job Order Record Type and Sales Process with stage values aligned to the customer's ZenATS workflow.

ZenHR Users (system login records distinct from the Employee profile) map to Bullhorn Users. We match by email address. Any ZenHR User without a matching Bullhorn User goes to a reconciliation queue for the customer's Bullhorn admin to provision. Role-based permissions in ZenHR do not map directly to Bullhorn user type and permission sets — we document the ZenHR role assignments as a written access matrix for the admin to rebuild in Bullhorn Admin settings.

ZenHR Branch Employee Shifts and Attendance Details (clock-in/clock-out events) generate a high volume of granular records for large workforces. ZenHR's API does not expose a documented bulk attendance endpoint. We paginate using cursor-based pagination and scope aggregated attendance summaries (e.g., monthly attendance rate per employee) as Bullhorn Candidate custom fields rather than individual punch events. This reduces API load and migration time by orders of magnitude while preserving the attendance data needed for payroll recalculation in the destination system.