Migrate from Hireology to Bullhorn ATS & CRM

Hireology Jobs map to Bullhorn JobOrder. The Job's title, description, employmentType, and location address transfer directly. Hireology's Location association (which ties the job to a specific franchise or retail site) maps to JobOrder's address and a custom field jobLocation__c carrying the Hireology Location name. If the destination organization represents multiple former Hireology customers or franchises as separate ClientCorporations, we reassociate each JobOrder to the appropriate Bullhorn client account during import.

Hireology Candidate records map to Bullhorn Candidate. Core profile fields (firstName, lastName, email, phone, address) migrate directly. We preserve the candidate's Hireology ID in a custom field hireology_candidate_id__c for audit and cross-reference. If a Candidate has applied to multiple Jobs in Hireology, all associated JobSubmissions are preserved against the same Bullhorn Candidate record.

Hireology Applications map to Bullhorn JobSubmission. Each Application links one Candidate to one Job at one Location. We preserve the applicationDate, current status, and stage-change history where available via Hireology's API. The JobSubmission.dateAdded maps to the Hireology application date. Stage change history is preserved as a custom text area field migration_stage_history__c in JSON format for admin reference.

Hireology interview scorecards are sub-objects on the Application with per-question ratings, rating scales, and free-text reviewer comments. Bullhorn does not have a native standardized interview scorecard object; scorecard data migrates as Note records linked to the JobSubmission, or as a Bullhorn custom object if the customer has commissioned one via Bullhorn Support. Before migration, we surface the rubric variance across locations and job types during the scoping call and ask the customer to confirm the target scorecard format. A uniform rubric is created in Bullhorn before scorecard import begins.

Background check metadata (check type, result date, pass/fail status) migrates as fields on the Bullhorn Candidate record or in a Bullhorn custom object. The actual screening report documents are not downloadable via Hireology's API and do not transfer. Candidates who have completed background checks in Hireology require re-initiation in Bullhorn, which can delay onboarding for regulated roles. We flag each affected candidate record and provide a re-screening checklist as part of the cutover documentation.

Hireology Locations represent individual franchise or retail sites, each with its own hiring manager and configuration. Bullhorn does not have a native multi-location model; franchise or site-level records map to Bullhorn ClientCorporation entities if the organization operates as a client relationship, or to a custom location__c field on JobOrder if the locations are operational divisions rather than clients. The customer's intended Bullhorn data model determines the mapping at scoping.

Hireology users (admins, hiring managers, recruiters) map to Bullhorn Users. We match by email address. Role and permission assignments are documented from Hireology and mapped to Bullhorn Role and Permission Set assignments during the Bullhorn configuration phase. Multi-location role hierarchies in Hireology may require a simplified permission model in Bullhorn if the Bullhorn edition limits role complexity.

Hireology custom fields on Jobs have no public registry. We discover them by sampling a representative set of Job records during the discovery phase, comparing the payload against the standard Hireology Job schema, and building a delta list of non-standard fields. Each discovered custom field maps to a Bullhorn JobOrder custom field, which must be pre-created via Bullhorn Support if the customer is on Bullhorn ATS (two limit) or Bullhorn ATS Growth (none). Enterprise customers with ten available custom object slots have more flexibility.

Same discovery approach as Job custom fields: we sample Candidate records, identify non-standard fields, and map them to Bullhorn Candidate custom fields. Bullhorn's custom fields per entity are limited by edition, so we prioritize the most operationally critical custom fields and document any that exceed the edition limit for customer review.

Hireology custom fields on Applications follow the same discovery-and-mapping process. These map to Bullhorn JobSubmission custom fields or a Bullhorn custom object attached to JobSubmission. The edition-specific limit applies across all entity types, so we coordinate custom field allocation across JobOrder, Candidate, and JobSubmission during schema design.

SkillSurvey reference check results embedded in the Hireology Candidate record migrate as structured fields (check date, status, reference type, overall rating) on the Bullhorn Candidate or in a Bullhorn custom object. SkillSurvey does not transfer as an active integration; the reference check history is preserved as data, and future reference checks must be initiated through Bullhorn's integration with a reference check provider or manually.

Job board distribution records (which boards received a posting, when it was distributed, performance metrics) are not exportable via Hireology's public API. We migrate the job content itself. The job posting distribution history must be reconstructed in Bullhorn's job board distribution module post-migration. We provide a list of all historical job posting targets and dates from Hireology's internal records if available, for the customer's admin to re-enter.

Hireology workflow templates defining stage sequences, automated actions, and approval gates are stored in Hireology's configuration layer and are not accessible via the public API. We deliver a written inventory of every workflow template inferred from the customer's stage configurations, job configurations, and any documented process guides. The customer's Bullhorn admin or implementation partner rebuilds the workflow as Bullhorn placement workflow, Opportunity sales process, or Bullhorn Automation Engine configuration post-migration.

Hireology's ADP Workforce Now integration passes new hire data from the offer stage into payroll. This integration is a connection configuration, not a data record. We document the ADP integration settings and new hire field mapping from Hireology so that the customer's Bullhorn admin can establish a comparable integration with ADP or a different payroll provider in Bullhorn. Active payroll integration data (benefits, deductions, tax withholding) lives in ADP, not in Hireology, and does not require migration from Hireology's ATS layer.