Migrate from Recruit ATS by HR Cloud to Recruit CRM & ATS

HR Cloud Job records map directly to Recruit CRM Job. We map title, description, location, department, employment type, and status (open/closed/archived). Custom fields attached to the Job posting migrate as Job-level custom fields in Recruit CRM. Job ID in HR Cloud is preserved in a migration ID map so that Applications can be linked to the correct Job record after import.

HR Cloud Candidate records map directly to Recruit CRM Candidate. We map all standard contact fields (name, email, phone, address), work history, education, and resume file as a binary attachment. Custom fields on Candidate migrate to Recruit CRM Candidate custom fields. The HR Cloud Candidate ID is preserved in a migration ID map for cross-object lookup resolution.

The Application junction between Candidate and Job migrates to Recruit CRM Application. We map applied date, current stage (resolved via the pipeline stage ordinal mapping), source channel, and rejection reason if applicable. Custom application-level fields migrate with value mapping against Recruit CRM's custom field schema. Parent record lookups (Candidate ID and Job ID) are resolved through the migration ID maps created during the Job and Candidate phases.

HR Cloud Pipeline Stages are fully custom and ordered by ordinal position. We extract the stage name and ordinal position, then configure the corresponding Job Pipeline in Recruit CRM with matching stage names and order. Stage IDs are system-generated on both platforms and must be remapped; the ordinal position is the stable anchor that preserves Kanban column ordering in Recruit CRM.

Tags on Candidates and Jobs export as string label arrays. We apply the full tag set identically in Recruit CRM, handling multi-tag records as arrays. Tags that do not exist in Recruit CRM are created during import.

Standard custom fields (text, number, date, picklist) on Candidate and Job migrate as identically-typed Recruit CRM custom fields. Entity-type custom fields (cross-object linkages to other Candidate or Job records) are detected during the pre-flight audit and preserved in a dependency map. We flag these to the customer's admin before migration; post-migration re-linkage is a manual step using the dependency map because Recruit CRM generates new record IDs on insert.

HR Cloud entity-type custom fields that link a Candidate record to another Candidate or Job record cannot be migrated as live references because Recruit CRM generates new record IDs. We extract the source record IDs and target record IDs, preserve them in a cross-object dependency map, and hand off the map to the customer's admin for manual re-linkage in Recruit CRM. This is a documented post-migration step, not an automated migration step.

Resume files, cover letters, and uploaded documents attached to Candidates and Jobs migrate as Recruit CRM File records. We preserve the original filename and MIME type. Large attachments are chunked for API upload using Recruit CRM's file upload endpoint, and files are linked to the parent record via the migration ID map.

Notes attached to Candidates migrate as Recruit CRM Note records with the original author and timestamp preserved. Note body migrates as plain text. Note thread structure does not migrate separately; all notes land as flat entries in Recruit CRM's timeline against the Candidate.

Recruit CRM's Client object is a CRM-layer record that has no equivalent in Recruit ATS by HR Cloud. We flag this as an empty migration target: the customer populates Client records manually or via a separate import after migration. Client records are typically created by agency admins to represent hiring companies on the client side of the placement relationship.

Recruit CRM's Contact object (separate from Candidate) represents a hiring manager or procurement contact at a Client. HR Cloud has no Contact equivalent. We flag this as a manual post-migration population step for the customer's admin team. Contacts are linked to Candidates via Recruit CRM's relationship model.