Migrate from Workday Recruiting to Recruit CRM & ATS

Workday Job Requisitions map directly to Recruit CRM Job records. We map title, department, location, employment type, and job description fields to their Recruit CRM equivalents. Confidential Requisitions from Workday are represented using Recruit CRM's confidential flag or a custom field. The Requisition's approval chain and workflow routing are not migratable as automation — we document the approval structure as a written handoff for your Recruit CRM admin to configure under Workflows post-migration.

Workday Candidate records (the talent pool entity separate from Worker/HCM records) map to Recruit CRM Candidate records. We map name, email, phone, address, education, skills, work history, and source attribution. When a single person has applied to multiple Requisitions in Workday, we write each application as a separate Job Application in Recruit CRM linked to the same Candidate record, preserving the multi-application chain as structured notes. Personal mobile numbers and preferred contact preferences migrate to Recruit CRM's contact detail fields.

Workday Job Applications link a Candidate to a Job Requisition and carry the application status, stage in the hiring process, and submission timestamp. We map application status to Recruit CRM Application status values, interview stage to the corresponding stage in Recruit CRM's job pipeline, and preserve the original submission date. Scorecard data, interview ratings, and evaluation comments attached to the Workday Application serialize into Recruit CRM's scorecard fields or as notes on the Application record.

Workday's Supervisory Organization hierarchy has no native equivalent in Recruit CRM, which uses a flat Client and Job structure. We translate the top-level Supervisory Organization tree into Recruit CRM Client records (if the org structure maps to clients or hiring companies) or into a flat Hiring Team structure per Job. Any org-level attributes — cost center, regulatory region, compliance flag — are captured as custom fields on the mapped Recruit CRM record. We flag any hierarchy depth that cannot be represented in Recruit CRM's flat model and document it for your admin.

Workday Positions represent the headcount slot within a Supervisory Organization and are distinct from the Job Requisition. Recruit CRM does not model Positions separately. We map Position title, job profile, pay range, and headcount status into supplemental custom fields on the Recruit CRM Job record. If your Workday tenant uses staffing-specific position restrictions (FTE, contractor, location-specific), we map those to Recruit CRM job type and employment type fields. Position-specific headcount approvals do not migrate as workflow logic.

Workday Candidate Notes (free-form notes attached to a Candidate or Application) map to Recruit CRM Notes on the Candidate or Application record. We preserve the note author, original timestamp, and full note body. Notes created by specific recruiters are attributed to the matching Recruit CRM user by email lookup. Large note volumes are chunked by record during import to avoid API timeouts.

Workday Interview Kits define the structured interview plan, and submitted Scorecards are tied to a specific Evaluator and Application. Recruit CRM provides customizable interview scorecards with rating fields and comment areas. We serialize the Workday scorecard evaluator name, score values, and written feedback into the corresponding Recruit CRM scorecard fields. If the Workday scorecard uses structured questions that Recruit CRM cannot natively model, we preserve the full scorecard content as a PDF attachment on the Application. We flag which Interview Kit templates need to be configured in Recruit CRM before the migration cutover.

Background check records are not a first-class Workday Recruiting object — they are typically managed via third-party integrations (HireRight, Checkr) or stored as attachments to the hire. We map any structured background check metadata (check type, status, completion date, vendor) from Workday into Recruit CRM custom fields on the Candidate or Application record. Full background check PDFs are recovered from Workday's attachment storage and re-uploaded as document attachments in Recruit CRM under the Candidate record. We flag any background check records stored only in a third-party system outside the Workday tenant.

Workday generates offer letters via business processes tied to the Requisition. Migrated offer data — offer amount, start date, offer status, terms — maps to Recruit CRM's offer tracking fields if configured, or is preserved as a structured note and PDF attachment on the Application record. Signed offer letter PDFs are recovered from Workday's document storage and re-uploaded as attachments. We flag any offers still in pending status at migration time so your recruiting team can decide on final disposition before the source system is closed.

Workday Custom Objects extend delivered business objects (Candidate, Requisition, Worker, etc.) to capture company-specific recruiting data. Recruit CRM does not have a separate Custom Object registration model — instead, we translate Workday custom object fields into Recruit CRM custom fields on the equivalent standard object (Candidate, Job, Application). We pre-create these custom fields in Recruit CRM before migration begins, matching Workday's field types (text, number, date, picklist) to their Recruit CRM equivalents. Any multi-instanced custom object (e.g., vaccination records) that cannot map to a standard Recruit CRM object is flagged for manual re-creation post-migration.

Resume files in Workday are stored as Candidate attachments. Workday frequently serves resume files as ephemeral signed S3 URLs or temporary blob URLs that expire after the export window closes. We initiate a file recovery pass at the start of migration to download all accessible resume files from Workday before URLs expire, then re-upload them as native Recruit CRM Candidate attachments. For any record where the original resume URL is no longer reachable, we flag the Candidate with a recovery-pending status and document the action your team needs to take (request from source ATS, request from candidate, or archive).

Workday Workers are the HCM-side employee record created via the Revise Hire business process after a Job Application is finalized. Workers in Workday Recruiting are distinct from Candidate records and live in the HCM module. We map Workday Workers with a Hire Date to Recruit CRM Candidate records with a hired status, linked back to the original Application. The full HCM Worker record (compensation, benefits, organizational assignment) does not migrate to Recruit CRM, which is an ATS/CRM and not an HRIS. We flag any Worker records that have a hire but no corresponding Application record in Workday so the gap can be documented.