☠Saaspocalypse
← Workday HCM · Enterprise HRIS
The migration runbook

Migrating off Workday HCM — phase by phase.

Workday HCM migrations live or die on three Workday-specific realities: data extraction goes through SOAP-based Workday Web Services (or RaaS reports), the business-process catalogue is the actual product (hundreds of approval chains accumulated over years), and the security-group + supervisory-org tree has to be remodelled before a single row of worker data moves. We scope tightly: HCM module only — Finance + Adaptive Planning + in-country Workday Payroll stay.

24-36 weeks (incl. a full quarter of parallel run) end-to-endFixed priceParallel run before cutoverYou own the code

The phases, tuned to Workday HCM

Each phase below is the Workday HCM-specific version of our standard playbook. Same shape every engagement, different specifics per SaaS.

  1. Scope-locking workshop (HCM only)

    2 weeks

    Workday is a suite — Finance, HCM, Adaptive Planning, Payroll. We carve out HCM only and put the rest explicitly out of scope, in writing, before anything else. Every Workday rebuild that gets in trouble does so by quietly expanding scope.

    ✓List every Workday business process in the catalogue — most teams have 1,000+ steps inherited from the implementation partner
    ✓Tag which ones are actually used (last 90 days) vs. inherited and dead
    ✓Confirm Finance + Adaptive Planning + Workday Payroll (per region) are out of scope
    ✓Identify the supervisory-org tree depth and the security-group inheritance model
    ✓Document every external integration that Workday currently feeds (HRIS to ATS, to payroll providers, to identity)
    You walk away with

    A signed HCM-only Scope Document + an active business-process inventory + a confirmed Finance/Payroll out-of-scope statement.

  2. Worker schema + security model design

    2 weeks

    The security-group + supervisory-org tree gets remodelled as a small, readable RBAC model in code. Worker IDs (Employee_ID and Universal_ID) get preserved as columns so payroll and identity systems keep resolving.

    ✓Design the `workers` table preserving both Workday `Employee_ID` and `Universal_ID`
    ✓Model the supervisory-org tree as a closure table (efficient ancestor/descendant queries)
    ✓Replace security groups with 4-6 named roles (HRBP, manager, comp planner, payroll ops, admin, viewer) defined in code
    ✓Plan multi-region absence rules as data, not as 200 business-process steps
    ✓Sign DPA + map sub-processors (sensitive HR data — get this right)
    You walk away with

    Schema migrations + an ADR for the RBAC + a documented multi-region absence rule set.

  3. Extract via Workday Web Services + RaaS

    3-4 weeks

    Workday's primary API is SOAP-based Web Services (per module: Human_Resources, Compensation, Talent, Absence). For tabular extracts, RaaS reports exposed as REST endpoints are usually faster than building SOAP envelopes for every field.

    ✓Authenticate via Integration System User (ISU) credentials with the right Functional Area access
    ✓Pull worker data via the Human_Resources Web Service (Get_Workers operation, paginated by `Response_Filter`)
    ✓Pull absence balances + history via the Absence Web Service
    ✓Pull compensation + bonus history via the Compensation Web Service
    ✓Stand up RaaS reports for high-volume tabular extracts (faster than SOAP envelopes per field)
    ✓Pull the supervisory-org tree via Get_Organizations + reconstruct the closure table
    You walk away with

    A re-runnable extract pipeline + a reconciliation report against the Workday Standard People Report.

  4. Build + weekly demos

    10-14 weeks

    The new HCM module is built around what your HRBPs actually do on a Tuesday afternoon, not around the 1,000+ business-process steps Workday accumulated. Business processes become TypeScript state machines reviewed in PRs.

    ✓Worker profiles + the supervisory-org tree as a live, queryable graph
    ✓Multi-region absence: NHS-aligned rota rules, statutory leave, sickness — as data + tests, not as a UI maze
    ✓Talent + performance review cycles run as durable workflows on Inngest
    ✓Comp planning UI: a spreadsheet-like grid backed by Postgres, with snapshot history
    ✓Mobile flows that clinical / shift staff actually use — built mobile-first, not as an afterthought
    ✓Sync layer exports to PayFit / Deel / Remote / ADP per region (whoever runs payroll there)
    You walk away with

    A working HCM module on a staging tenant, with HRBP and manager flows demoed weekly.

  5. Parallel run — one full quarter

    12-13 weeks (one quarter)

    Workday HCM stays authoritative for a full quarter. We mirror worker data nightly, run one complete review cycle in both systems, run one complete comp cycle in both systems, run one quarterly absence-accrual reset. Only then do we cut over.

    ✓Nightly Workday → new system mirror via Get_Workers + Get_Absence_Inputs
    ✓Run a complete performance-review cycle in both systems, reconcile ratings + comments
    ✓Run a complete comp-planning cycle in both systems, reconcile every increase + bonus
    ✓Verify a quarterly absence-accrual reset matches across regions
    ✓Train HRBPs in three 60-minute sessions per region, recorded
    ✓Re-point downstream integrations (identity, ATS feed, payroll feeds) one at a time with a kill switch
    You walk away with

    A reconciliation dashboard showing zero drift across a full quarter + signed sign-offs from each regional HR lead.

  6. Cutover + Workday HCM read-only

    1 day + 6-month fallback

    On the day, Workday HCM (only) goes read-only. Workday Finance, Adaptive Planning and any in-country Workday Payroll keep running. The new HCM module becomes the system of record for worker data and feeds the downstream integrations.

    ✓Cut HRBP and manager SSO to the new app
    ✓Lock Workday HCM module to read-only via security-group changes
    ✓Workday Finance + Adaptive Planning + Workday Payroll continue normally
    ✓Re-point identity provisioning (Okta / Azure AD) to read from the new system
    ✓Hold the Workday HCM read-only window for 6 months as a compliance + audit safety net
    You walk away with

    A Cutover Runbook + a 6-month Workday HCM read-only window + a confirmed reduction on the next Workday renewal SOW.

The Workday HCM APIs we'd actually hit

Concrete endpoints we use to extract your data during the parallel-run phase. We keep the extract scripts — they're useful at every renewal.

Workday Web Services — Human_Resources
POST /ccx/service/{tenant}/Human_Resources/v42.0 (SOAP)
The primary worker-data API — Get_Workers, Maintain_Worker_Documents, etc. Paginated via Response_Filter.
Workday Web Services — Absence_Management
POST /ccx/service/{tenant}/Absence_Management/v42.0 (SOAP)
Absence balances, accruals, time-off events and approvals across regions
Workday Web Services — Compensation
POST /ccx/service/{tenant}/Compensation/v42.0 (SOAP)
Comp history, salary changes, bonus + variable pay
Workday Web Services — Talent
POST /ccx/service/{tenant}/Talent/v42.0 (SOAP)
Performance reviews, ratings, succession candidates
RaaS (Reports as a Service)
GET /ccx/service/customreport2/{tenant}/{report}?format=json
Tabular extracts via Workday custom reports exposed as REST — faster than SOAP for high-volume rows
Workday Identity OAuth
POST /ccx/oauth2/{tenant}/token
OAuth 2.0 for Integration System User (ISU) credentials with scoped Functional Area access
Workday Web Services — Staffing (Get_Organizations)
POST /ccx/service/{tenant}/Staffing/v42.0 (SOAP)
Pull the supervisory-org tree + reporting lines so we can rebuild the closure table

The Workday HCM-specific gotchas

Things we've learnt the hard way (or that the documentation understates). We'll surface these on the kickoff call so nobody is surprised in week 6.

What stays where it is

Migrations work because they're scoped honestly. Here's what we don't move — by design.

  • ·Workday Finance — stays where it is, full stop
  • ·Adaptive Planning — stays where it is
  • ·Workday Payroll in regions where it's live — kept; the new HCM exports to it instead of replacing it
  • ·Workday Recruiting — replaced separately if needed (Lever / Greenhouse) or kept
  • ·Workday Studio integrations — replaced with TypeScript + Inngest, not migrated
  • ·Workday Reports library — rebuilt in Metabase on the new Postgres warehouse

Get a Workday HCM-shaped migration plan.

Tell us your seat count, contract end date, and the integrations you can't lose. We'll come back within a business day with a fixed-price scope and a timeline tuned to your renewal.

Scope a Workday HCM migration

One business day. NDA + DPA on request.