Migrer hors de Workday HCM — phase par phase.
Les migrations Workday HCM se jouent sur trois réalités spécifiques : l'extraction passe par les Workday Web Services (SOAP) ou les rapports RaaS, le catalogue de business processes est en soi le produit (des centaines de chaînes d'approbation accumulées), et l'arbre security-group + supervisory-org doit être remodelé avant qu'une seule ligne de collaborateur ne bouge. On cadre serré : HCM uniquement — Finance, Adaptive Planning et Workday Payroll dans les pays où il tourne restent en place.
Les phases, taillées pour Workday HCM
Chaque phase ci-dessous, c'est la version spécifique Workday HCM de notre démarche standard. Même structure à chaque mission, des détails par SaaS.
Scope-locking workshop (HCM only)
2 weeksWorkday 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)Ce que vous repartez avecA signed HCM-only Scope Document + an active business-process inventory + a confirmed Finance/Payroll out-of-scope statement.
Worker schema + security model design
2 weeksThe 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)Ce que vous repartez avecSchema migrations + an ADR for the RBAC + a documented multi-region absence rule set.
Extract via Workday Web Services + RaaS
3-4 weeksWorkday'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 tableCe que vous repartez avecA re-runnable extract pipeline + a reconciliation report against the Workday Standard People Report.
Build + weekly demos
10-14 weeksThe 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)Ce que vous repartez avecA working HCM module on a staging tenant, with HRBP and manager flows demoed weekly.
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 switchCe que vous repartez avecA reconciliation dashboard showing zero drift across a full quarter + signed sign-offs from each regional HR lead.
Cutover + Workday HCM read-only
1 day + 6-month fallbackOn 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 netCe que vous repartez avecA Cutover Runbook + a 6-month Workday HCM read-only window + a confirmed reduction on the next Workday renewal SOW.
Les API Workday HCM qu'on tape vraiment
Les endpoints concrets qu'on utilise pour extraire vos données pendant la phase de parallel run. Les scripts d'extraction restent — ils resservent à chaque renouvellement.
POST /ccx/service/{tenant}/Human_Resources/v42.0 (SOAP)POST /ccx/service/{tenant}/Absence_Management/v42.0 (SOAP)POST /ccx/service/{tenant}/Compensation/v42.0 (SOAP)POST /ccx/service/{tenant}/Talent/v42.0 (SOAP)GET /ccx/service/customreport2/{tenant}/{report}?format=jsonPOST /ccx/oauth2/{tenant}/tokenPOST /ccx/service/{tenant}/Staffing/v42.0 (SOAP)Les pièges propres à Workday HCM
Ce qu'on a appris à la dure (ou ce que la doc minimise). On les met sur la table dès le kick-off, comme ça personne n'est surpris en semaine 6.
- ⚠Workday's primary API is SOAP, not REST — SOAP envelopes per Functional Area + per-field marshalling is genuinely tedious. RaaS reports are usually faster for tabular extracts.
- ⚠Business-process catalogue is the actual product. A typical implementation accumulates 1,000+ approval-chain steps that nobody can fully document. Inventory ruthlessly in Phase 1; rebuild only what's still firing.
- ⚠Security groups + supervisory-org inheritance is famously hard to flatten. Plan the RBAC remodel as a Phase 2 deliverable, not a cutover surprise.
- ⚠Worker ID strategy matters — Workday exposes both Employee_ID and Universal_ID (and a separate WD_Worker_ID). Preserve all three as columns so payroll, identity and downstream integrations keep resolving.
- ⚠Multi-region statutory rules (UK NHS, Germany BetrVG, France code du travail, US FLSA) don't reduce to a single absence engine. Plan per-region rule sets early; don't try to write one generic engine.
- ⚠Workday Studio integrations are XML-pipeline scripts that break in surprising ways. Replace them, don't migrate them — keep the old ones running until each downstream cuts over.
- ⚠ISU (Integration System User) credentials need the right Functional Area access scoped by the Workday admin. Procurement of those scopes can take weeks — start in Phase 2, not Phase 3.
- ⚠Comp cycles, review cycles and absence-accrual resets are quarterly events. The parallel run must span a full quarter or you'll miss a category of bug that only fires at quarter-end.
Ce qui reste en place
Une migration marche quand elle est cadrée honnêtement. Voilà ce qu'on ne touche pas — par choix.
- ·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
Cadrer une migration Workday HCM.
Dites-nous votre nombre de licences, la date de fin de contrat et les intégrations que vous ne pouvez pas perdre. On revient sous un jour ouvré avec un cadrage forfaitaire et un calendrier calé sur votre renouvellement.
Cadrer une migration Workday HCM
Un jour ouvré. NDA + DPA sur demande.