Migrate from Hireology to BambooHR

Hireology Candidates are the primary person record representing an applicant. We map core profile fields (first name, last name, email, phone, address, work history, education) directly to BambooHR Employee fields. A Hireology Candidate who was not hired migrates as an Employee record with a status indicating they are a past applicant. If the candidate was hired and the Hireology-to-BambooHR integration already created a BambooHR Employee record, we reconcile by email match and update rather than duplicate. Note that Hireology does not expose a unified candidate profile across all applications via API for candidates who applied to multiple jobs.

Hireology Jobs (open positions at a specific location) map to BambooHR as either a Position record in BambooHR's custom table structure or as structured fields on the hiring-related Employee record. BambooHR does not have a native job posting object for active openings. We map the job title, description, location, and department to the destination, and flag any job-specific requirements that should be preserved as a note on the candidate's employee record. The job's posting status (open/closed) is recorded for cutover documentation.

Hireology Applications link a Candidate to a specific Job at a specific location and record the application date, current stage, and stage-change history. BambooHR does not have a native application object. We map application data as structured fields or notes on the Employee record, preserving the original job title applied for, application date, and current stage at the time of migration. Stage-change history migrates as a dated note sequence for audit trail purposes.

Hireology Interview Scorecards are sub-objects on Application with per-question ratings, rating scales, and free-text reviewer comments. BambooHR has no native scorecard object. We export scorecard data as a structured PDF or CSV file attached to the corresponding Employee record, preserving reviewer name, date, question, rating, and comment. If location-specific rubrics used different rating scales, we normalize to a common five-point scale before export and note the original scale in the file header.

Hireology stores background check result metadata (check type, pass/fail, date, provider) as structured data on the Candidate or Application record. The actual report documents are references to the screening provider and are not downloadable via the Hireology API. We migrate the structured metadata as a BambooHR Employee file attachment and note in the file that the original report document must be obtained from SkillSurvey or the applicable provider directly. Candidates who completed background checks but were not yet hired may need to re-initiate screening in BambooHR or the destination screening provider.

Hireology Locations represent individual franchise or retail sites with their own hiring manager and configuration. BambooHR's organization structure supports departments and divisions but does not have a native multi-site location object. We map each Hireology Location to the corresponding BambooHR department or division, and we attach a location address and hiring manager note to the department record for reference. Multi-location organizations should confirm their desired organizational hierarchy with BambooHR before migration.

Hireology Users (admins, hiring managers, recruiters) with role-based permissions map to BambooHR User accounts. We resolve by email match and map role assignments to BambooHR permission groups. A Hireology user who was also a hiring manager on specific locations must be associated with the corresponding department or employee record in BambooHR. Multi-location role hierarchies in Hireology may need simplification in BambooHR depending on the organizational structure chosen.

Hireology custom fields on Jobs have no public schema registry. We discover them during the discovery phase by sampling 20-30 job records and comparing the payload against the standard Job schema. Discovered custom fields are created as typed custom fields in BambooHR (text, number, date, dropdown) and mapped during migration. Any custom field added without Hireology customer awareness will not appear in our initial discovery and requires a targeted re-scan before migration begins.

Hireology allows custom fields on Candidate records but does not expose a unified custom field registry via API. We apply the same record-sampling discovery method used for Jobs to Candidate records, identifying any non-standard fields and creating equivalent typed custom fields in BambooHR before migration. Candidate-level custom fields related to screening criteria or qualifications map to corresponding Employee custom fields for ongoing use post-migration.

Hireology Application-level custom fields (often used for sourcing channel, referral source, or internal requisition ID) are discovered through record sampling and mapped to BambooHR Employee custom fields. We note that BambooHR's custom field limits vary by plan; Starter plans have stricter limits than Growth and Power plans. We verify the applicable plan limit during scoping and flag any custom field count that would require a plan upgrade.

Hireology's embedded SkillSurvey integration stores reference check responses as structured metadata on the Candidate or Application. The SkillSurvey report itself is a provider-hosted document not accessible via Hireology API. We migrate the structured reference check metadata (reference provider, completion date, response summary, overall reference rating) as a BambooHR Employee file. The full SkillSurvey PDF must be requested directly from SkillSurvey if required for compliance or audit purposes.

Job board posting records and distribution history (which boards received a posting, when it was distributed, performance metrics from the board) are not exported via the Hireology API. We migrate the job content itself (title, description, location, requirements) but not the distribution log. Post-migration, the customer re-posts jobs directly to desired boards from BambooHR or through their existing job board accounts. This is a data gap, not a mapping gap.