Home / Case Studies / UKG Ready → Workday
    CASE STUDY · CONTRACT SECURITY · UNITED STATES

    UKG Ready to Workday for a National Contract-Security Provider

    A national US contract-security provider moved HR, payroll and recruiting from UKG Ready to Workday — around 8,900 active workers, ~14,000 total worker records and seven years of history. Syntra ETL owned the data migration workstream alongside the client's Workday implementation partner, ran it through three accuracy-gated phases at 60%, 90% and 100% data coverage, and archived the UKG history that did not belong in Workday so the legacy tenant could eventually be stood down. In this sector one domain outranks everything: a guard whose licence lands with the wrong expiry date cannot be deployed to a client site.

    ~8,900
    Active workers migrated
    ~14,000
    Total worker records
    7 yrs
    History in scope
    100%
    Licence reconciliation

    The engagement

    The client is a national contract-security provider — three decades in business, licensed across 48 states, and protecting more than 150 enterprise clients across retail, logistics, corporate and education sites. Its workforce is overwhelmingly hourly, highly distributed across client premises, and turns over at rates typical of the guarding sector.

    The organisation was replacing UKG Ready with Workday, including Workday Payroll as the go-forward payroll system. A Workday implementation partner owned tenant configuration — organisations, the job catalogue, plans and security. Syntra ETL was brought in to own the data migration workstream itself: discovery and object mapping, the extract/transform/load build, data-quality profiling, every mock conversion cycle, reconciliation packs, the cutover runbook and delta loads, and post-go-live hypercare.

    🏢

    The client — business owner

    Owned source access, remediation of UKG data quality, the open scope decisions, and sign-off on each mock-cycle reconciliation. Business SMEs ran the mapping workshops with us.

    🧭

    Implementation partner — tenant

    Workday tenant configuration: organisations, job catalogue, compensation and benefit plans, time calculations and security — all prerequisites for each dependent load.

    ⚙️

    Syntra ETL — the data workstream

    Object mapping, extract/transform/load, data-quality profiling, mock cycles, reconciliation and control totals, cutover runbook, delta loads and hypercare — with phase gates tied to the partner's mock-conversion calendar rather than to fixed dates.

    We work this way regularly alongside implementation partners — see Syntra for System Integrators and the UKG Ready → Workday migration solution.

    Why a security workforce is not a generic HCM migration

    Most of the object map is standard Workday conversion. A handful of domains are specific to contract security, and they are where the operational risk actually sits.

    🚨 Guard licences and certifications
    A worker without a valid, correctly dated licence cannot be deployed to a client site. State guard cards, firearms permits and issuing-authority detail migrating with wrong expiry dates — or silently failing to migrate — is immediate operational and compliance exposure, not a reporting inconvenience. This domain got its own reconciliation and its own sign-off, at 100% match rather than sampled.
    Client sites as locations
    In contract security every client site can be a location. Loaded naively that produces a location hierarchy nobody can administer, so a rationalisation rule had to be agreed before the org foundation was built.
    Rehire identity matching
    High-turnover guarding workforces generate heavy rehire volume. Without agreed matching rules and a duplicate-detection report on every mock cycle, the same person arrives in Workday as two workers — with two service dates.
    Multi-rate hourly compensation
    Multiple rates per worker are normal in security — driven by site and bill rate. Compensation had to carry that structure into Workday rather than collapse to a single rate per person.
    Client-site clearances
    Site-level clearance data has no standard Workday home and needed a custom object designed with the implementation partner — sector-critical for deployment decisions.
    Multi-state and union complexity
    A multi-state workforce means payroll tax elections per jurisdiction and state/municipal sick-leave variants on accruals; represented populations bring collective agreements that affect seniority and accrual treatment.

    The object map

    Every UKG Ready source object was mapped to its standard Workday load object or web service, phased, and annotated with its complexity and failure modes. Nine domains, agreed and frozen at the end of Discovery.

    A · Foundation & organisation

    Cost-centre tree to Supervisory Organization, Cost Center and Region; locations and hierarchy; departments; job titles consolidated from UKG sprawl into a clean Workday job catalogue; pay grades; EEO job categories; employee types; union and CBA codes.

    B · Core worker

    The anchor load — ~8,900 active workers via Hire, plus the legacy-key cross-reference spine, personal details, contact information, government IDs, emergency contacts, job data, compensation, supervisory assignment, accounts and security roles.

    C · Employment & comp history

    Sequenced staffing events loaded in strict date order — transfers, promotions and site moves; compensation change events; ~5,100 terminated workers as historical hire/terminate pairs; termination reasons and rehire eligibility; rehire linkage and continuous service dates; leave history.

    D · Time & absence

    Accrual balances loaded as cutover-dated as-of balances and re-run at go-live, with state and municipal sick-leave variants; open and future-dated time-off requests; open pay-period time blocks. Pay rules and time calculations were re-implemented in Workday, not migrated.

    E · Payroll

    Federal, state and local tax elections; payment elections and bank details under encrypted handling; recurring deductions and court-ordered garnishments with balances, limits and remittance detail; YTD payroll balances for a mid-year cutover; in-flight prior-period adjustments closed deliberately.

    F · Benefits

    Current enrolments effective-dated to cutover and validated against carrier files; dependents and beneficiaries with allocation percentages that have to total correctly.

    G · Recruiting

    Open requisitions, active candidates with de-duplication rules, in-flight applications and stages, outstanding offers preserved through cutover, sources and referrals for reporting continuity, and background-check/onboarding status — sector-critical for guard clearance.

    H · Licensing & certifications

    State guard cards and firearms permits as Worker Certifications with issue and expiry dates, issuing authority and licence number; training records; skills; and client-site clearances as a custom object. The domain with its own 100% reconciliation.

    I · Documents & attachments

    Offer letters, disciplinary records and acknowledgements as Worker Documents; I-9 and work authorisation against retention obligations; onboarding documents. Binary volume drove the transfer window.

    See UKG HR, payroll, workforce & time migration and the Workday HCM data migration connector.

    Three phases, by data coverage

    Phase boundaries were set by cumulative share of in-scope data — objects × volume — and aligned to the implementation partner's mock-conversion calendar rather than to fixed dates. Around 20–24 weeks of migration workstream, run in parallel with the Workday implementation.

    PHASE 1 · 10–12 WEEKS60%

    Foundation & active population

    Extract/transform framework build; organisation, location and job foundation; all active workers in current state; current job and compensation; the ID cross-reference spine; and Mock 1 and Mock 2 conversions. This phase carries the one-time build every later cycle reuses.

    PHASE 2 · 6–8 WEEKS90%

    Depth, recruiting & compliance

    Recent employment and compensation history; the terminated and rehire population; absence balances and benefit elections; payroll tax and payment elections; recruiting; guard licences and certifications; then Mock 3 and the Dress Rehearsal. The highest object diversity of the three.

    PHASE 3 · 4 WEEKS100%

    Full history & cutover

    The full seven-year historical backfill; closed requisitions and candidate history; historical documents and attachments; final reconciliation and sign-off; then production cutover and delta loads.

    See our ETL migration cutover plan and Workday data migration guides.

    The cross-cutting workstreams

    Eight workstreams ran across all three phases. These are the parts of a migration that do not appear on an object map but decide whether it lands.

    ID cross-reference & mapping repository

    A single source of truth linking UKG keys to Workday IDs. Every later load and every reconciliation depends on it, which is why it was built in Phase 1 rather than assembled as needed.

    Value mapping & translation tables

    Codes for job, location, reason, status, ethnicity, termination and disposition — held as reviewable data the business could sign off, not as logic buried in transformation code.

    Data-quality profiling & remediation

    Duplicates, missing SSN and date of birth, orphan managers, invalid addresses — profiled in the first two weeks. On a migration like this, remediation usually consumes more effort than the ETL itself, so the backlog was owned by the client with weekly tracking.

    Reconciliation & control totals

    Record counts, financial and rate totals and balance checks, per object, per cycle — issued as a reconciliation pack the business signed off before the next phase opened.

    Mock conversion cycles

    Mock 1 and Mock 2 in Phase 1, Mock 3 and a full Dress Rehearsal in Phase 2 — iterative load, validate and defect-fix cycles run against the partner's calendar.

    Cutover rehearsal, runbook & delta loads

    A timed, sequenced production runbook with an explicit rollback position, plus catch-up loads covering everything that changed between final extract and go-live.

    What moved to Workday — and what was archived instead

    Not everything in a seven-year UKG Ready tenant belongs in a new Workday tenant. Loading history that nobody will transact against inflates cost, extends the cutover window and clutters the target. The deliberate split was: migrate what the business operates on, archive what it only ever needs to look up.

    → Migrated into Workday

    • Active worker population and current state
    • Full worker, job and compensation history across seven years
    • Terminated and rehire population with continuous service
    • Accrual balances as of cutover, open time-off requests
    • Payroll tax elections, payment elections, garnishments, YTD balances
    • Current benefit enrolments, dependents, beneficiaries
    • Open requisitions, active candidates, in-flight applications and offers
    • Guard licences, certifications and client-site clearances
    • Worker documents for active and recent workers

    🗄️ Archived out of UKG instead

    • Pay statement history — high volume, look-up only, no operational value in Workday
    • Historical time detail — timesheets and clock events for an hourly guard workforce are very large; only the open pay period was migrated
    • ACA / 1095 history — retained for the reporting obligation
    • Closed requisitions and the historical candidate pool — limited operational value, and a consent and data-retention review applies before any bulk move
    • Historical benefit elections — retained for audit rather than loaded
    • Interview records and older attachments — retained, not transplanted

    Archiving that content into a governed historical store rather than leaving it inside a licensed UKG tenant is what eventually lets the legacy system be decommissioned instead of maintained indefinitely — the difference between a migration that ends and one that leaves a second system running forever.

    Related: UKG data archival · historical reporting · UKG decommissioning · data retention · payroll & HR data archival.

    Payroll cutover and the parallel-run discipline

    Workday Payroll was the go-forward system, with UKG Ready kept available in parallel as a fallback for an agreed period. That is a sensible contingency — and the single most common way a migration acquires a permanent second system. It was handled as a controlled activity, not an open-ended arrangement.

    One named system of record

    From cutover, Workday is the system of record and UKG is read-only. Data changed in both systems during a parallel run cannot be reconciled afterwards, so freeze rules for the legacy tenant were defined up front.

    Time-boxed, with exit criteria

    The parallel period had a defined end date and explicit exit criteria. An open-ended parallel period is the most common cause of prolonged dual maintenance — and of a decommissioning that never happens.

    Payroll reconciled 100% before go-live

    Payment elections, tax elections and garnishments were reconciled in full — not sampled — before the first live Workday pay run, with that run validated against a UKG comparison.

    Cutover date as a cost lever

    A mid-calendar-year cutover requires YTD payroll balances to be loaded and scales with the number of earning and deduction codes in play; a 1 January cutover removes that work entirely. Naming this early turned a scheduling question into an informed decision.

    See UKG migration cutover strategy and migration reconciliation.

    The risks we named up front

    Every one of these was written into the plan with its mitigation before mobilisation, rather than discovered during a mock cycle.

    Licence data incorrect at go-live · Critical
    Dedicated reconciliation and business sign-off for the certification domain — 100% match required, not sampled.
    Rehire matching creating duplicate workers · High
    Matching rules agreed early, with a duplicate-detection report produced on every mock cycle.
    Source data quality worse than assumed · High
    Profiled in weeks 1–2 of Phase 1, with a remediation backlog owned by the client and tracked weekly.
    Historical volume larger than stated · High
    Counts confirmed per object before Phase 2 and 3 scope was fixed, under volume-based change control. In a high-turnover sector the true historical population is routinely larger than the headline number.
    Payroll incorrect at first live run · High
    Elections and garnishments reconciled 100% pre-go-live; the first run validated against a UKG comparison.
    PII handling across environments · Medium
    Masking in non-production tenants, encrypted transfer and least-privilege access — with SSNs masked and missing values reported pre-load.

    Frequently asked questions

    What is different about migrating a contract-security workforce?+

    Four things. Guard licences and certifications are operationally binding — a worker without a valid, correctly dated licence cannot be deployed to a client site, so that domain gets 100% reconciliation rather than sampling. Every client site can be a location, so the location hierarchy needs a rationalisation rule. High turnover generates heavy rehire volume, which makes identity matching a first-class design decision. And multi-rate hourly compensation driven by site and bill rate has to survive into the target rather than collapse to one rate per worker.

    Why phase by data coverage rather than by module?+

    Because it tracks what actually has to be true before the next step. Phase 1 delivers 60% of in-scope data — objects × volume — and carries the one-time build every later cycle reuses: the extract framework, the ID cross-reference spine, the mapping repository and the reconciliation harness. Phase 2 reaches 90% with the highest object diversity, and Phase 3 takes it to 100% with the historical backfill and cutover. Phase boundaries were aligned to the implementation partner's mock-conversion calendar rather than to fixed dates.

    What was archived instead of migrated, and why?+

    Pay statement history, historical time detail beyond the open pay period, ACA/1095 history, closed requisitions and the historical candidate pool, historical benefit elections and older attachments. All of it is look-up data rather than data the business transacts against — and for an hourly guard workforce, historical time detail alone is very large. Loading it into Workday would have inflated cost and extended the cutover window for no operational gain. Archiving it into a governed store instead is what makes eventual decommissioning of the legacy tenant possible.

    How was the parallel run with UKG controlled?+

    With three rules. Workday is the named system of record from cutover and UKG is read-only, because data changed in both systems during a parallel run cannot be reconciled after the fact. The parallel period is time-boxed with written exit criteria — an open-ended parallel period is the most common cause of prolonged dual maintenance. And retaining UKG as a contingency is distinct from running both payrolls and comparing results, which is a defined activity with its own effort.

    Does the cutover date really change the cost?+

    Materially. A mid-calendar-year cutover requires YTD payroll balances to be loaded, and that work scales with the number of earning and deduction codes in play. A 1 January cutover removes it entirely. It is the single largest cost lever in the payroll domain, which is why it was surfaced as an explicit decision during discovery rather than assumed.

    Which Syntra products were used?+

    All three. DataMove ran extraction, transformation and the Workday loads across every mock cycle and the delta loads. DataVault held the ID cross-reference spine, lineage and reconciliation packs — and the governed archive of the UKG history that was retained rather than migrated. DataLens provided data-quality profiling, duplicate detection, exception tracking and cutover-readiness analytics, then historical reporting over the archive.

    Who does what when there is a Workday implementation partner?+

    The partner owns Workday tenant configuration — organisations, job catalogue, compensation and benefit plans, time calculations, security — which are prerequisites for each dependent load. Syntra ETL owns the data migration workstream: object mapping, extract/transform/load, data quality, mock cycles, reconciliation, cutover and delta loads. The client owns source access, remediation of its own data and sign-off. See Syntra for System Integrators.

    Moving off UKG to Workday?

    Tell us your source footprint, target modules and how much history you actually need in the new tenant — we will map the objects, phase it by data coverage, and archive what does not need to migrate so the legacy system can be retired rather than maintained. We work directly and alongside implementation partners.