Migrate your Hireology data

Jobs are the primary posting object in Hireology, representing open positions at a specific location. All standard fields (title, description, location, department) map cleanly. We preserve the job's associated pipeline stage and any location-specific assignments.

Candidates are applicant profiles that may be tied to multiple Jobs across locations. We map the core profile fields and preserve the candidate's current application status. Note that Hireology does not deduplicate candidates automatically if the same person applies to multiple roles.

Applications link a Candidate to a specific Job at a specific location. We preserve the application date, current stage, and any stage-change history available via the API. Interview scores attached to the application are included in the migration.

Interview scorecards are stored as sub-objects on the Application. The schema supports multiple reviewers with per-question ratings and free-text comments. We map the scores to the destination's equivalent evaluation object, noting that rating rubrics differ between platforms.

Hireology integrates with third-party background check providers (including SkillSurvey for reference checks) and stores results as part of the Candidate or Application record. Results are typically stored as PDF references or structured pass/fail flags. We migrate the reference data but not the actual background report documents, which remain with the screening provider.

Custom fields can be added to Jobs, Candidates, and Applications but there is no unified custom field registry exposed via the public API. We discover custom fields during the discovery phase by sampling records and then map each to the destination field, flagging any that have no equivalent in the target schema.

Locations in Hireology represent individual franchise or retail sites. Each location can have its own hiring manager and configuration. We map location records and reassociate them with the corresponding entities in the destination system.

Users include admins, hiring managers, and recruiters with role-based permissions. We map users to the destination system, preserving role assignments. Multi-location role hierarchies can be complex and may require manual review during cutover.

Job board posting records and distribution history (which boards received the posting, when it was distributed) are not exported via the API. We migrate the job content itself but not the distribution metadata. Re-posting to job boards at cutover is handled separately by the customer.

Workflow templates defining the sequence of stages, automated actions, and approval gates are stored in Hireology's configuration layer and are not accessible via the public API. These must be manually recreated in the destination system.