Workday · HCM · Master data

Workday Worker Data Migration

Migrate workers into Workday, covering staged hire events, position assignment, supervisory organisations, effective-dated history and the business process framework that governs the load.

Discuss Your Migration All Migration Objects

Object overview

The single most important thing to understand about migrating workers into Workday is that a Hire is not an insert. It is a business process with steps, conditions and approvals. A load that treats it as a row insert either fails validation or leaves events sitting in flight awaiting approval, which looks exactly like missing data.

History is reconstructed as an ordered stream of dated events — hire, job change, transfer, promotion, termination, rehire — rather than as history rows. Sequence matters as much as content: out-of-order events produce a worker whose current state is right and whose history is nonsense.

What data is typically migrated

Scope is agreed in discovery; this is the shape of the object.

Data area	Typical information
Worker	Worker ID, name, personal data, contact information
Hire event	Hire date, position, job profile, supervisory organisation, employee type
Position	Position assignment where position management is in use
Job history	Staged events reconstructing job changes, transfers and status changes
Compensation	Compensation plan assignment, grade and amounts
Organisation assignments	Cost centre, region, company and custom organisations

Object relationships

Dependency drives load sequence: a child cannot exist before its parent.

Supervisory organisation

└─ Position (if position management)

└─ Worker

└─ Hire event

└─ Job change / transfer events (dated)

└─ Compensation

└─ Organisation assignments

Object migration flow

Source Workers→DataMove→Map & transform→Validate→Workday Workers→DataVault reconciliation→Sign-off

Before you migrate this object

Confirm each of these before the first migration cycle.

□Supervisory organisation design is complete and loaded

□Job profiles, job families and compensation structures are configured

□Position management scope is decided

□Business process definitions are configured and tested with a sample load

□Population and history depth are agreed

□Employee versus contingent worker classification rules are agreed

□Licence reconciliation approach is agreed with the Workday programme

Common source systems

Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

UKG Production-provenPeopleSoft SupportedSAP SuccessFactors SupportedOracle HCM Cloud SupportedADP SupportedCeridian Dayforce Supported

Source-to-target mapping examples

Object-level equivalence. Field-level mapping is produced per engagement.

Source system	Source entity	Target object
UKG Ready	Employee + job assignment	Workday Worker + Hire event + Position
PeopleSoft	JOB (effective-dated rows)	Workday staged events
SuccessFactors	Employment + job_info	Workday Worker + Hire + Job Change events

Migration methods for this object

EIB (Enterprise Interface Builder) — spreadsheet-shaped bulk loads against a web service

Core Connectors and Workday Studio for higher volume and complexity

Staged hire events with effective dates reconstructing history

RaaS for extraction and for reconciliation reporting after load

Extraction considerations

Which population, and how deepTotal worker records normally exceed active headcount by a wide margin once terminated and rehired populations are counted. Both the population and the history depth are agreed before extraction, because they drive tenant size and licence reconciliation.

Events, not rowsThe source is usually row-based history. Extraction has to capture enough to reconstruct what event caused each change, not merely what the values became.

Terminated and rehired workersA rehire is a separate employment period. Sources modelling it as a status flag need reconstructing into distinct hire and termination events.

Configuration alongside dataJob profiles, supervisory organisations, locations and compensation structures are extracted or designed as reference data, because Workday will not stage a worker into an organisation that does not exist.

Transformation rules

History to an ordered event streamThe core transformation. Each source change becomes a dated Workday event of the correct type, sequenced so the resulting state is right at every point in time.

Department structure to supervisory organisationsWorkday's organisational model is not a department tree. The target hierarchy is designed and source values mapped onto it.

Job codes to job profilesCrosswalked to the job profiles configured in the tenant.

Employee type and worker typeEmployee versus contingent worker is a Workday distinction that many sources do not model explicitly.

Manager to supervisory organisationWorkday derives reporting from organisation membership rather than a manager field, so a manager hierarchy becomes an organisational structure.

Data quality and validation

Supervisory organisation exists

And is available at the event effective date.

Position exists where position management applies

And is unfilled at the hire date.

Job profile exists

Every event references a configured profile.

Event sequence is valid

No job change before hire; no event after termination without a rehire.

Effective dates are consistent

Events are chronologically ordered per worker.

Worker ID uniqueness

Across the whole load, including rehires.

Load sequence and dependencies

What has to exist before this object can load.

1Supervisory organisations
2Locations and cost centres
3Job profiles and job families
4Compensation plans and grades
5Positions (if position management)
6Worker hire events
7Job change and transfer events in date order
8Compensation
9Organisation assignments

Common migration errors

What actually fails on this object, and why.

Business process not completedThe event loaded but sits awaiting approval, so the data appears missing. Almost always a business process configuration issue rather than a data issue.

Supervisory organisation not foundThe organisation was not created before the worker was staged.

Position already filledTwo workers staged into the same position, common when position management is introduced during the migration.

Event out of sequenceA job change dated before the hire event, or an event after termination.

Job profile not foundThe crosswalk produced a value not configured in the tenant.

Effective date before organisation availabilityThe organisation exists but not as at that date.

Reconciliation

Counts alone rarely prove this object migrated correctly.

Active headcount at cutover, by supervisory organisation

Total worker records including terminated — the figure that drives licence reconciliation

Event count per worker compared to the source change history

Workers with in-flight business processes: this must be zero before sign-off

Compensation coverage: every active worker has a compensation record

Manager and organisation membership compared to the source hierarchy

Should all historical records be migrated?

Detailed history for long-terminated workers is a strong archive candidate. Workday tenant sizing and licence positions both respond to worker volume, and retention obligations can usually be met with a searchable archive rather than by loading decades of terminated populations into the tenant.

Legacy system archival Historical reporting

How Syntra ETL supports this object

DataMove

Extraction, mapping, transformation, validation preparation and target load generation.

Explore DataMove →

DataVault

Preserves source, prepared and target states for reconciliation, lineage and audit evidence.

Explore DataVault →

DataLens

Migration progress, data quality, exceptions and readiness across cycles.

Explore DataLens →

Relevant migration routes

Source-specific guidance for moving this object.

UKG→Workday

Successfully delivered projects involving this object

Published case studies whose scope included workers.

InfiniumSMS+5 more→Oracle Autonomous Database (ATP)Catholic Healthcare TrustHealthcare · USA

5 Legacy systems retired
~8 TB Data archived
~150K Attachments

All five legacy systems decommissioned; the consolidated archive is live in production.SUCCESSFULLY DECOMMISSIONEDView Project →Kronos→DataVault ArchiveMulti-Hospital US Health SystemHealthcare · USA

12,000+ Employee records archived
18 Kronos data areas preserved
25+ Reports on the archive

Legacy workforce system taken through a ten-stage decommissioning process to sign-off.SUCCESSFULLY DECOMMISSIONEDView Project →Paycom→Oracle Fusion HCMMajor US Healthcare ProviderHealthcare · USA

99%+ Accuracy at go-live
4 Delivery phases
6 mths Initial load to cutover

Data accuracy taken from a 60%+ first load to 99%+ at go-live.GO-LIVE COMPLETEView Project →

Frequently asked questions

Why do Workday loads fail even when the data is correct?

Because a Hire is a business process, not an insert. If the process configuration expects an approval step, the event loads and then waits — which looks like missing data. Business process configuration is tested with a sample load before the first full cycle.

How is worker history reconstructed in Workday?

As an ordered stream of dated events rather than history rows. Each source change becomes an event of the correct type at the correct effective date, sequenced so the worker's state is right at every point in time.

What has to exist before workers can be staged?

Supervisory organisations, locations, cost centres, job profiles and compensation structures — and positions, where position management is in use. Workday will not stage a worker into an organisation that does not exist.

How are terminated and rehired workers handled?

As distinct employment periods with their own hire and termination events. Sources that model a rehire as a status change need reconstructing, or the break in service is lost.

Why does total worker count matter more than headcount?

Because tenant sizing and licence reconciliation respond to total records, and terminated plus rehired populations usually exceed active headcount substantially. Agreeing the population early prevents a surprise late in the programme.

Planning a similar data migration?

Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.

Discuss Your Migration Explore Migration Routes