Migrate your Workday Recruiting data

Worker is Workday HCM's primary employee record. It is distinct from the Candidate object and only created when a hire is finalized via a Revise Hire business process. We map source employee records to Workers but cannot create them until a Requisition → Position chain is established in the target tenant.

Positions are the staffing backbone in Workday and must belong to a Supervisory Organization. They are distinct from Job Requisitions — a Position represents the headcount slot, while a Requisition is the recruiting request against it. Source systems often do not model Positions explicitly, so we map Job or Requisition records to this object and create the Supervisory Organization hierarchy on your behalf.

Supervisory Organizations form the org chart and are a prerequisite for every Position write. Source ATS platforms do not have an equivalent hierarchy. We construct this tree from org chart data you provide, flagging gaps where a referenced manager does not yet exist as a Worker in the target tenant.

Job Requisitions are the core recruiting object in Workday and map cleanly from source Job/Requisition records. Confidential Requisitions are supported. We preserve all standard fields (department, location, worker type, job profile) and custom requisition fields.

Candidates are the talent pool entity, separate from Workers. In migrations from application-centric platforms, a single candidate often has multiple applications across multiple jobs. We flatten this into one Candidate per unique person, then write multiple Job Applications against the appropriate Requisitions. Active vs. inactive status must be explicitly mapped since Workday derives it from application state.

Job Applications link Candidates to Job Requisitions. Scorecards, interview ratings, and evaluation data live on the Application. We map these as structured notes or Interview Kit attachments in the target since Workday's native structured interview data requires pre-configured scorecard templates in the destination tenant.

Interview Kits define the interview plan and question banks. When migrating from platforms with free-form scorecards (Greenhouse, Lever), we serialize the structured evaluation data as attachments and flag that the destination tenant must configure equivalent Interview Kits before the kit can be used at scale.

Scorecards in Workday are tied to Interview Kits and submitted by specific evaluators. Source platforms often store scorecards as flat text blocks or custom fields. We map evaluator name and score data into the nearest native Workday scorecard structure or into a Candidate note, and flag where the destination Interview Kit is missing.

Free-form notes attached to a Candidate or Application are supported. We import these as native Workday Candidate Notes, preserving author and timestamp where available.

Background check records are not a first-class Workday Recruiting object by default — they are typically managed via third-party integrations (HireRight, Checkr) or as attachments to the hire. We migrate background check status as a structured document or note, and flag whether the target tenant has an active background check integration configured.

Workday generates offer letters via business processes tied to the Requisition. Migrated offers from external systems are typically loaded as approved offer records or as PDF attachments to the Application. We map offer status, compensation details, and start date, and flag that the target tenant's offer template and approval chain must be configured.

Custom Objects extend Workday's delivered business objects (Worker, Position, Candidate, etc.) to capture company-specific data. They are permanent once created and appear in the Workday object graph. We migrate Custom Object data as structured fields on the parent object or as JSON-encoded attributes, and flag any Custom Objects that must be pre-created in the target tenant with matching field schemas.

Attachments in Workday are stored against the Candidate or Application object. Source ATS platforms frequently serve resume URLs as ephemeral signed S3 links that expire post-export. We download and re-upload all accessible resume files during migration and flag any records where the original attachment URL is no longer accessible.