Replacing PeopleSoft with Workday: Integrating 200+ Enterprise Systems

Why HCM transformations fail (and what we did differently)

Most HCM transformations don't fail at the HCM layer. Workday and SuccessFactors are mature platforms — the vendors know what they're doing. They fail at the edges, in the integrations. The HRIS is the spine that connects payroll, tax, finance, security, identity, directory, governance, learning, performance, mobility, travel, expenses and a long tail of bespoke business processes. Replace the spine without replacing the connectors carefully, and the body falls apart.

When we took on the program, the inventory came back at 200+ integrated systems, mostly built up over a decade of ad-hoc point-to-point links into the PeopleSoft database. Some were nightly file extracts. Some were near real-time SOAP services. Some were direct read-only views into the PeopleSoft schema. A few — and we only found these in deep discovery — were undocumented stored procedures.

The architecture problem we had to solve wasn't "how do we move to Workday". It was "how do we re-front 200 integrations against a new platform with a completely different API model, on a timeline measured in quarters, without missing a pay run".

The four-layer integration strategy

We classified every one of the 200+ integrations into one of four patterns and built a target architecture for each. Most of the program ran on rails after that.

1. Real-time API integrations. Identity, security, and directory systems consume Workday events through REST/SOAP web services. New hires hit Active Directory, the entitlement systems and the access-review feeds within minutes.
2. File-based batch.Payroll, tax filing, pension administration and a long list of legacy systems consume scheduled extracts. We standardized on a single outbound file pattern with strict versioning, so future consumer changes don't cascade across the fleet.
3. Middleware-bridged.A handful of systems expected the old PeopleSoft contract and couldn't be changed on our timeline. We bridged them through the enterprise integration middleware, translating Workday payloads into the legacy shape so the consumer was unchanged.
4. Direct deprecation. A surprising number of integrations were dead — built years ago, owned by teams that had moved on, consumed by systems that had been retired. We turned them off. (This always saves more time than expected.)

The Workday API edge

Workday is API-rich but opinionated. It exposes WSDL-based SOAP services for almost everything, plus modern REST endpoints for newer surfaces. The right pattern is to wrap them — never expose Workday directly to internal consumers.

We built a thin integration edgein front of Workday: an internally-published catalogue of REST services that translate from the bank's domain vocabulary (worker, role, cost-centre, manager) into Workday's native objects. That edge is where authn, authz, throttling, retry, idempotency and audit live. It also means consumers don't have to learn Workday — and if Workday ships a breaking change, only the edge moves.

For high-volume reads (org-chart data, role mappings, hierarchy walks), we mirror Workday data into a read-side store updated by Workday Outbound EIBs and event subscriptions. Batch consumers hit the mirror; the live Workday tenant doesn't get hammered.

Single sign-on and mobile, done once

Two cross-cutting initiatives lived inside the program because doing them later would have been twice the cost.

The first was SSO across the Workday surface. SAML federation from the bank's identity provider into Workday for both desktop and mobile, paired with conditional access on session risk. End users get one login; the security team gets centralized session control and a clean audit trail.

The second was mobile via AirWatch (now Workspace ONE) as the EMM. Workday Mobile is deployed through AirWatch with policy controls — no copy/paste of sensitive data, conditional access, remote wipe on lost devices. Rolling that out alongside the HCM cutover meant we never had to revisit mobile after go-live.

Cutover: phased, parallel, reversible

For a system that drives payroll and tax filings, big-bang is not an option. We ran parallel for one full pay cycle: PeopleSoft and Workday produced outputs simultaneously, the integration edge fed downstream systems from PeopleSoft (the system of record at that moment), and a reconciliation engine compared every record between the two HRIS platforms. Variances were triaged daily.

Cutover happened domain by domain, not all at once: Core HR first, then Compensation, then Time Tracking, then Talent. For each domain, the system of record flipped only after a clean parallel run. Roll-back was scripted — we never went into a phase without a tested way out.

What an enterprise can take from this

• Inventory before architecture. The first six weeks were a full integration discovery — schema reads, scheduled jobs, undocumented procedures. Skip this and the program will discover surprises during cutover.
• Wrap the SaaS. Never let internal consumers couple directly to Workday WSDLs. The thin integration edge is the single most valuable thing we built.
• Read replicas for read-heavy consumers. Workday tenants don't love being hammered for org data. Mirror, then read.
• Phase the cutover. Domain by domain, parallel-run, reconciled — not all at once.
• Bundle SSO and mobile in-flight. Doing them with the cutover is dramatically cheaper than doing them after.

Doing this in your enterprise?

SEYSO has architected and led HCM, ERP and SaaS migrations across Tier-1 banks and large enterprises. If you're planning a Workday, SuccessFactors or other major SaaS cutover with a long tail of legacy integrations, we'd love to talk. The integration map is always the work — and it's the work we do best.