Migrate from Hireology to Zoho Recruit

Hireology Jobs (representing open positions at a specific location) map to Zoho Recruit Job Openings. The job title, description, department, and employment type transfer directly. Hireology's location association on the Job migrates to Zoho Recruit's custom Location field (created as a text or picklist field on Job Opening) since Zoho Recruit has no native multi-location module. We preserve the original Hireology location ID as a reference field for reconciliation.

Hireology Candidates map to Zoho Recruit Candidates. CRITICAL: Zoho Recruit requires a Last Name value on every Candidate record; records without a last name will be rejected during import. We preprocess all Candidates to populate Last Name from available fields (first name concatenated, company name, or 'Not Provided') and flag any records with missing critical fields for customer review before migration begins. Email address becomes the primary dedupe key.

Hireology Applications (linking a Candidate to a Job at a specific location) map to the association between a Zoho Recruit Candidate and a Job Opening. We create this association using Zoho Recruit's candidate-job linkage with the application date, current stage, and stage-change history preserved in custom fields on the Candidate record or in the interview module. The stage history from Hireology becomes a custom field (application_stage_history__c) holding a JSON snapshot of stage transitions.

Hireology Interview Scorecards are sub-objects on Application with variable questions, rating scales, and reviewer assignments per location and job type. Zoho Recruit uses a standardized scorecard model with configurable criteria. We normalize all location-specific rubrics into a common Zoho Recruit scorecard format during the migration phase, selecting the most representative rubric from the customer's Hireology instance as the target. Customer must confirm the target rubric during scoping. Individual scores transfer as criteria ratings with reviewer names and comments preserved.

Hireology Locations (franchise sites, retail branches, or regional offices) have no native Zoho Recruit equivalent. We map each Location to a custom picklist or text field on Job Opening called hireology_location__c, and optionally associate the location's hiring manager in Hireology with a Zoho Recruit User record. If the customer uses Zoho Recruit's Client module for external hiring managers, we can create Client records per location. The mapping choice is confirmed during the discovery call.

Hireology Users (admins, hiring managers, recruiters) with role-based permissions map to Zoho Recruit Users. We resolve by email match. Multi-location role hierarchies in Hireology (regional manager overseeing multiple locations) require Zoho Recruit's role hierarchy configuration, which we document in the migration output. Any Hireology User without a matching Zoho Recruit User email goes to a reconciliation queue for the customer's admin to provision before record migration.

Hireology stores background check result metadata (check type, date, pass/fail status from SkillSurvey) as part of the Candidate record. The actual report documents cannot be exported via the Hireology API. We migrate the structured metadata to Zoho Recruit custom fields on the Candidate (bg_check_status__c, bg_check_type__c, bg_check_date__c). Candidates with completed background checks must be flagged for re-initiation of screening in Zoho Recruit if the destination organization uses Checkr or another provider. This delay to onboarding is disclosed during scoping.

Hireology custom fields on Jobs map to Zoho Recruit custom fields on Job Opening. We discover all custom fields during the discovery phase by sampling Hireology API responses across Jobs, comparing the payload against the standard schema, and identifying fields not in the base API response. Custom field data types map to Zoho Recruit field types (text, number, date, picklist, checkbox). Any unmapped fields are flagged for customer review before migration.

Same discovery and mapping approach as custom fields on Jobs. Hireology custom fields on Candidates (common additions include source channel, referral info, or role-specific attributes) map to Zoho Recruit Candidate custom fields. Last Name field requirement must be validated before any custom field mapping proceeds. We create all custom fields in Zoho Recruit via API before importing any data to avoid validation errors.

Hireology custom fields on Applications may contain stage-specific data or hiring-manager notes. We map these to either Candidate-level custom fields or Job Opening-level custom fields depending on whether the data is candidate-centric or role-centric. The assignment is confirmed during the mapping call with the customer. Application-level custom fields that are stage-specific may require transformation into a JSON or multi-value field in Zoho Recruit since Zoho Recruit does not have a native Application object with its own field space.

SkillSurvey reference check results stored on the Hireology Candidate record map to Zoho Recruit Candidate custom fields (reference_check_score__c, reference_check_completed_date__c) and an attached Note with the detailed reference summary. The SkillSurvey rating and commentary transfer as structured data. Candidates with pending or incomplete SkillSurvey checks are flagged as a separate migration batch pending completion, so they do not block the main migration timeline.

Hireology's ADP Workforce Now integration passes new hire data from the offer stage into payroll. This integration operates at the point of hire completion, not during the candidate migration. We migrate the candidate's final status and offer details but do not migrate the ADP integration connection itself, as it requires re-authentication in Zoho Recruit with ADP or a replacement payroll connector. The migration output includes a payroll integration checklist for the customer's HRIS admin to re-establish after cutover.