Migrate from HR-ON to Bullhorn ATS & CRM

HR-ON Employee records map to Bullhorn Candidate. The core employee properties (firstName, lastName, email, jobTitle, department, startDate) map directly to Bullhorn Candidate fields (firstName, lastName, email, title, department, dateAdded). We resolve HR-ON systemFields by parsing org metadata (such as location, manager, employment type) and either mapping them to standard Bullhorn Candidate fields or flagging them for Bullhorn Custom Object creation. HR-ON custom properties migrate as custom Candidate fields. The Candidate entity is the Bullhorn ATS core; all other entities reference it.

HR-ON user accounts map to Bullhorn User records when the HR-ON user represents a recruiter or staffing consultant who will log into Bullhorn. We match by email address. HR-ON systemFields indicating admin roles, department ownership, or approval authority map to Bullhorn User permissions and department assignments. Note that Bullhorn ATS Growth does not include API access; User record creation and role assignment may require Bullhorn support coordination depending on edition.

HR-ON stores org structure (departments, reporting lines, cost centers) within systemFields on Employee records rather than as separate objects. We parse these systemFields and reconstruct them as Bullhorn Department records or as a Bullhorn Custom Object with department assignments attached to User and Candidate. If the customer uses Bullhorn ATS Growth (which lacks Custom Objects), we map department data to a custom text field on User and note the limitation. This decision is made during scoping based on the destination Bullhorn edition.

HR-ON document templates with name, description, documentType, dateFormat, and language metadata (da_DK, en_US) do not have a direct Bullhorn equivalent. Bullhorn stores documents as ContentDocument records attached to the relevant entity (Candidate, ClientContact, JobOrder). We export the template metadata as a JSON manifest with the original language and dateFormat preserved, and we note each template that requires manual re-creation in Bullhorn or replacement with Bullhorn's document generation (if the Bullhorn edition supports it). Document templates themselves do not migrate as reusable templates.

HR-ON generated documents (binary blobs or PDF links) attached to Employee records migrate as Bullhorn ContentDocument records linked via ContentDocumentLink to the corresponding Bullhorn Candidate. The original document language (da_DK or en_US) and dateFormat metadata are stored in a Bullhorn Custom Object field or as notes on the ContentDocument for post-migration reassignment if the document attaches to the wrong Bullhorn template. We flag any document over 25 MB for customer review because Bullhorn's file size limits may require chunking.

HR-ON supports custom properties on Employee records beyond systemFields. We extract all non-systemFields and assess data type compatibility with Bullhorn's field type options (text, number, date, picklist, checkbox, multi-select picklist). Bullhorn ATS Growth allows 2 Custom Objects with 55 fields each; Bullhorn Front Office Growth/Enterprise allows 10. Multi-select picklist values from HR-ON map to Bullhorn multi-select picklist fields with the same option set. We pre-create the destination fields in a Bullhorn Sandbox before production migration.

HR-ON stores dates in four formats depending on locale and template settings: DD-MM-YYYY, DD/MM/YYYY, YYYY-MM-DD, or written form. Bullhorn expects ISO 8601 (YYYY-MM-DD) for all date fields. We normalize every date value from HR-ON to ISO 8601 during the extraction phase, validate against the destination Bullhorn field requirements, and flag any dates outside the range 1900-01-01 to 2100-12-31 for manual review. The original HR-ON dateFormat metadata is preserved in a custom field for audit.

HR-ON stores language preferences per template and employee at da_DK (Danish) and en_US (English). We carry this through as Bullhorn Candidate custom fields (candidateLanguage and templateLanguage) so that localized content rendering is preserved. Bullhorn does not have native multi-language template support, so the language field serves informational purposes and is used by the customer to manually reassign document templates post-migration.

HR-ON systemFields on Employee records (such as employeeStatus, employmentType, costCenter, location, managerId, terminationDate) are parsed and mapped. Standard-compatible fields map directly to Bullhorn Candidate. Fields without a Bullhorn equivalent (such as custom HR-ON cost codes or approval chains) require Bullhorn Custom Object fields, which must be created by Bullhorn Support before migration. We include these in the Custom Object Setup Sheet and coordinate the support ticket as part of the migration approach.

HR-ON user roles (Admin, Manager, Employee) map to Bullhorn User roles with different permission models. Bullhorn's role-based access control operates at the entity and field level. We map default HR-ON roles to the nearest Bullhorn equivalents (Standard User, Admin) and flag any HR-ON-specific permissions (such as payroll access or approval authority) that have no Bullhorn User Role equivalent. These are noted for the customer's Bullhorn admin to configure post-migration.

HR-ON user accounts map to Bullhorn User records by email address match. Any HR-ON user without a corresponding Bullhorn User goes to a reconciliation queue where the customer's Bullhorn admin provisions the missing account. Bullhorn User records are required before Candidate records with assigned owners can be imported because OwnerId references must be satisfied at insert time. We validate User existence before record migration begins.

HR-ON stores hireDate, terminationDate, and other employment timestamps. We map these to Bullhorn Candidate date fields (dateAdded for hire, custom terminationDate field if needed). Historical employment dates before Bullhorn's earliest supported range are stored as text fields to avoid validation errors. We flag records with termination dates for Bullhorn admin review because Bullhorn ATS treats inactive candidates differently from HR-ON's active/inactive employee model.