Migrate from Happy Hire to Recruit CRM & ATS

Happy Hire candidate profiles (name, email, phone, resume, source attribution, status) migrate directly to Recruit CRM Person records. We preserve the candidate source field as a custom Person field and flag any required Recruit CRM fields (such as mandatory email format) that are empty in the Happy Hire export. If the source instance uses a flat model with application data stored as embedded fields on the candidate record, we split that data into a separate Application object during the transform phase before inserting into Recruit CRM.

Happy Hire applications linking a Candidate to a Job with stage and timestamp data map to Recruit CRM Application records. Stage transitions, stage-change timestamps, and application notes preserve in structured custom fields on the Application object. We resolve the Person-to-Candidate reference and the Job reference during migration using Happy Hire's internal IDs matched to the migrated Recruit CRM Person and Job record IDs.

Happy Hire job records (title, description, location, department, status) map to Recruit CRM Job records. Active and closed job status migrates directly. We remap Happy Hire custom job fields to Recruit CRM custom fields using field-type matching (text, picklist, number, date) verified during the discovery export. Posting URLs and board-level posting metadata migrate as structured text fields on the Job record.

Happy Hire user accounts (name, email, role) migrate to Recruit CRM user accounts with matching roles. We resolve users by email address as the dedupe key. Any Happy Hire user without a corresponding Recruit CRM account goes to a reconciliation queue for the customer's admin to provision before the candidate and job migration phases begin, because OwnerId references on Application records require a valid user to be present.

Post-hire Employee records from Happy Hire migrate to Recruit CRM Person records with a custom employment status field set to Hired and custom fields for start date, department, and employment type. The original candidate record and the post-hire employee record share the same email address and are deduplicated during import by email key, producing a single Person record with enriched employment data rather than two separate records.

Happy Hire scorecard templates and completed evaluations (structured ratings and free-text notes) migrate as custom fields on the Recruit CRM Application object. We map the scorecard template name to a custom Application field group and each rating dimension to a numeric or picklist custom field. Free-text reviewer notes migrate as a long-text custom field on the Application. The relationship to the candidate (Person) is preserved by resolving the Application's PersonId reference at migration time.

Onboarding task names, assignees, and completion statuses from Happy Hire migrate as structured custom fields on the Recruit CRM Person record. Subtask nesting may flatten during migration depending on the depth of the Happy Hire task hierarchy; we document the original nesting structure in a JSON field on the Person record for the admin to reference during Recruit CRM task rebuild. Assignee resolution uses the User mapping to link to the correct Recruit CRM user.

External job board posting metadata (board name, posting URL, posting date, expiry date) migrates as structured text fields on the Recruit CRM Job record. Board-level analytics such as click-through rates do not migrate because Happy Hire does not expose this data in standard exports. The customer receives a written list of active and historical board postings as a reference document for re-posting inside Recruit CRM if needed.

Candidate source attribution in Happy Hire (LinkedIn, referral, job board, etc.) migrates to a custom picklist field on the Recruit CRM Person record. We extract the distinct source values from the Happy Hire export and create the corresponding picklist options in Recruit CRM before migration. Any source values that do not have a matching picklist option are flagged for the customer's admin to review and approve before the Person import runs.

Happy Hire custom fields at the Candidate level map to Recruit CRM custom fields on the Person object. We perform field-type analysis during discovery (text vs. picklist vs. number vs. date vs. checkbox) and configure the matching Recruit CRM field type before any data loads. Custom fields that have no corresponding Recruit CRM field are documented in a gap report for the customer's admin to create post-migration. This ensures no custom candidate data is silently dropped during the import.

Happy Hire custom fields at the Job level map to Recruit CRM custom fields on the Job object using the same field-type matching process as for Person fields. Job-level custom fields are migrated before active job data to ensure the schema is ready when Application records reference the Job during the application-phase migration.

Happy Hire jobs with an active status that are currently receiving applications are flagged during scoping and held in a dedicated migration queue. We preserve these records in an open state until the cutover window closes, then migrate them last with a verified Job board URL and any pending applications captured as delta records. This prevents candidates applying in the final days before cutover from landing in Happy Hire with no corresponding Recruit CRM job.