Migrate from Harri to Bullhorn ATS & CRM

Harri Workers (employees and applicants) map to Bullhorn Candidate records. We preserve first name, last name, email, phone, employment status, hire date, job title, and department. Employment type (full-time, part-time, seasonal) maps to Bullhorn's EmployeeType custom field or standard classification fields. Active workers import as active Candidates; applicants retain their application status. Harri worker custom properties migrate to Bullhorn Candidate custom fields (customObject1s through customObject10s depending on edition), which Bullhorn Support provisions before migration begins.

Harri Locations (restaurant or hotel properties) map to Bullhorn ClientCorporation records. Each Location's address, manager assignment, and associated property metadata become Bullhorn ClientCorporation fields. For hospitality operators transitioning to staffing models, the Location is the client company; for operators maintaining direct employment, the Location maps to an internal ClientCorporation used for reporting and compliance tracking. We chunk export by Location and validate completeness per site before loading into Bullhorn.

Harri Positions define job listings within a Location, including title, pay rate, FT/PT/seasonal classification, and department. Bullhorn JobOrder captures the same fields: title, employmentType, salary, and pay rate. We map Position title to JobOrder title, FT/PT classification to JobOrder employmentType, and pay rate to JobOrder salary or a custom pay rate field. Custom Position properties (shift requirements, coverage needs, job description) migrate to JobOrder custom fields.

Harri Applications track candidate submissions for Positions, including application date, source, pipeline stage, and interview scores. Bullhorn JobSubmission (accessible via the Candidate and JobOrder relationship) captures submission date, status, source, and rating. We map Harri application stage names (customer-configured) to Bullhorn JobSubmission status values, preserving interview scores in custom rating fields. Pipeline stage names vary by Harri customer configuration, so we create a customer-specific stage mapping table during scoping.

Bullhorn does not have a native shift scheduling object. Harri shift data (assigned shifts with start/end times, shift type, and coverage requirements) cannot map to a standard Bullhorn entity. We migrate shift data as Candidate custom fields (e.g., preferredShiftStart__c, preferredShiftEnd__c, shiftType__c, availabilityNotes__c) or document it as a configuration recommendation for Bullhorn Onboarding (formerly Able) if the customer licenses that module. The customer decides the target structure during scoping.

Harri onboarding task checklists migrate as Bullhorn Task records linked to the Candidate, or as Candidate custom fields if the tasks are status flags rather than dated actions. We map task name, completion status, due date, and responsible manager. Custom onboarding task fields map to Candidate custom fields. Bullhorn Onboarding (formerly Able) handles structured onboarding workflows natively; we document whether the customer licenses this module and flag it as a rebuild target.

Harri compliance records (certification expiry, mandatory training completion, regulatory acknowledgements) are compliance record types that vary by jurisdiction and customer setup. Bullhorn has no native compliance tracking module for hospitality-specific regulations. We flatten Harri compliance records into Candidate custom fields (e.g., certificationExpiryDate__c, tipCreditStatus__c, mandatoryTrainingCompleted__c) and preserve the original compliance record type as a custom picklist value. The customer admin rebuilds any active compliance reminder workflows in Bullhorn Automation (formerly Herefish) post-migration.

Harri stores employee documents (contracts, ID scans, policies) as file attachments on Worker records. We migrate these as Bullhorn ContentDocument records attached to the corresponding Candidate via ContentDocumentLink. Filenames and original upload timestamps are preserved. Document type (contract, ID, policy) is stored in a custom field on the ContentDocument or as a Candidate custom field to aid searchability. Bullhorn supports PDF, DOC, and image formats natively.

Harri pay rates are stored on the Position object. Bullhorn captures pay rate on the Placement record (for placed candidates) and on the JobOrder (for the job opening). We map Harri Position pay rate to Bullhorn JobOrder salary or to Placement payRate depending on whether the worker has been placed. Payroll data itself (earnings, deductions, pay stubs) lives in Harri's integrated third-party payroll provider and does not migrate; we instruct customers to export historical payroll from their payroll provider separately.

Harri employee engagement and pulse survey responses are tied to the Harri engagement module and have no documented export mechanism. Bullhorn has no engagement survey module natively. We exclude engagement survey data from migration scope and flag it upfront. Customers who need historical engagement data export it manually from Harri's UI before termination. We note Bullhorn's integration with third-party engagement tools (Culture Amp, Lattice) as a post-migration replacement path.

Harri handles payroll via integration with third-party providers rather than natively. Historical earnings, deductions, pay stubs, and tax withholdings are stored in the integrated payroll system, not in Harri. We do not migrate payroll data. The customer exports historical payroll from their payroll provider and maps it into Bullhorn Back Office (if licensed) or a separate payroll system post-migration.

Harri custom properties on Workers (beyond standard fields) map to Bullhorn Candidate custom objects. Bullhorn Support must provision custom objects before migration; the Custom Object Setup Spreadsheet is submitted as a ticket. Growth and Enterprise editions support up to 10 custom objects with 55 fields each; Bullhorn ATS supports 2. We map each Harri custom property to a typed Bullhorn custom field (text, date, drop-down, checkbox) and configure the field mapping in Bullhorn Admin > Field Mappings before migration.