PeopleSoft to SAP Migration: SOX Compliance Guide
PeopleSoft-to-SAP migrations typically happen when a company standardizes on SAP after an acquisition, consolidates financials off a legacy PeopleSoft Financials instance while keeping PeopleSoft HCM, or replaces an aging PeopleSoft environment nearing end of extended support. The SOX exposure is structural: PeopleSoft's permission-list and role model, its Change Assistant-based change record, and whatever SoD tooling was layered on top of it (PeopleSoft Risk Matrix or a third-party GRC add-on) do not carry over to SAP's authorization-object model, transport system, or GRC Access Control rule engine. Every control your auditor has tested in PeopleSoft needs a deliberate, documented equivalent in SAP before go-live. This guide covers the control-continuity sequence specific to that cutover — not the technical data-conversion plan already sitting in your integrator's project charter.
Before you start
- ·Current-state PeopleSoft control matrix complete: every ICFR-relevant control (access, SoD, change management, interface, reconciliation) documented with control owner, frequency, and evidence artifact
- ·SoD conflict inventory from PeopleSoft Risk Matrix or the third-party GRC tool in use, signed off by the SoD risk owner, not IT alone
- ·SAP role design workshop completed with Internal Audit or a control-design resource in the room, working from the target SoD matrix rather than a template
- ·Target-state control matrix drafted: each PeopleSoft control mapped to its SAP equivalent, with gaps flagged explicitly where no direct equivalent exists
- ·Cutover and parallel-run calendar agreed with the external auditor, including which fiscal period's testing will span both systems
Migration steps
Freeze and export the PeopleSoft control baseline
Before SAP configuration begins, capture a complete snapshot of the PeopleSoft control environment: permission list and role assignments, row-level security definitions (Tree security, department scoping), the SoD rule set and any documented conflicts, Change Assistant logs for the trailing 12 months, and the current SOX control matrix mapped to evidence artifacts. Store this outside PeopleSoft itself — it's the reconciliation point for the SAP design and the artifact your auditor will want when asking how you verified nothing was lost in translation.
Re-map every control to its SAP equivalent, not its nearest analog
Work the control matrix line by line. Access controls built on PeopleSoft permission lists and row-level security need to be reproduced through SAP authorization objects, composite roles, and organizational-level restrictions (company code, plant, cost center) — these constructs don't map one-to-one, and a single PeopleSoft row-level rule may require several stacked SAP authorization objects to reproduce the same restriction. Change-management evidence that lived in PeopleSoft's Change Assistant needs an SAP equivalent in the transport system, confirmed to capture requester, approver, and timestamp with equal rigor.
Rebuild the SoD rule set against SAP's authorization-object structure
PeopleSoft's SoD rules are written against permission lists, components, and menu items — none of which exist in SAP. If SAP GRC Access Control is part of the target state, the rule set must be rebuilt from the underlying risk logic (which duties must never combine), translated into SAP transaction codes and authorization objects. Validate the rebuilt rules against real test scenarios; a rushed keyword-level translation routinely produces false negatives because the two systems group functions along different boundaries.
Design SAP roles from the target SoD matrix outward, not by mirroring PeopleSoft roles
PeopleSoft roles built up over years of incremental access requests often already carry latent conflicts. Carrying that shape into SAP composite roles just re-implements the same problem under new role names. Build SAP roles starting from the SoD matrix: define which duties can never combine, then construct roles that structurally prevent the combination, checking every role pairing against the matrix before finalizing the catalog.
Gate cutover provisioning on a documented SoD check
Under cutover deadline pressure, provisioning teams default to giving each user 'the SAP access that matches what they had in PeopleSoft.' This is the most common way conflicts resurface. Require every account created during cutover to pass a documented SoD check against the finalized SAP role catalog before it goes live, with conflicts routed to a compensating-control decision rather than discovered during the first post-cutover control test.
Document cutover-period compensating controls
For the weeks spanning parallel run and go-live, some SAP-native controls — reconciliation reports, automated three-way match, interface monitoring — won't have a full cycle of production data to validate against. Document which controls are affected, the compensating control covering the gap, the owner, and the retirement date once the primary SAP control is confirmed operating effectively.
Run a full control test cycle in SAP before closing the project
Before declaring the migration complete, execute one full test of every ICFR-relevant control in the live SAP environment — access review, SoD conflict scan, transport sample, key reconciliations — and compare results to the pre-migration PeopleSoft control matrix. Gaps found here get remediated while the project team and budget still exist; gaps found later by the external auditor become findings with a remediation plan attached.
Where SOX continuity breaks
- ·SAP composite roles built to mirror PeopleSoft's existing role structure instead of being redesigned from the target SoD matrix, carrying forward the same conflicts under different role names
- ·SoD rule set translated from PeopleSoft to SAP GRC Access Control at a surface level without validating that the new rules actually catch the same real-world conflicts
- ·Change-management evidence gap at cutover — PeopleSoft's Change Assistant record is retired before the SAP transport approval workflow is confirmed to capture equivalent approver and timestamp detail
- ·Row-level security assumptions from PeopleSoft (department or business-unit scoping via Tree security) not fully reproduced in SAP's organizational-level authorization restrictions, discovered only when an access review flags unexpected visibility
- ·Cutover compensating controls left running indefinitely because no one owns the retirement decision once the SAP primary control is confirmed operating
After the cutover
After cutover, run a formal parallel-testing period — typically one to two fiscal close cycles — comparing key controls tested against the legacy PeopleSoft evidence trail, while still retrievable, and the new SAP environment, investigating any variance before PeopleSoft access is fully decommissioned. The first complete control-testing cycle run entirely in SAP becomes the baseline for your external auditor's assessment of whether the migration preserved control effectiveness.
Common questions
No. PeopleSoft's rules are written against permission lists and components, which have no equivalent structure in SAP. The underlying risk logic — which duties must never combine — carries over conceptually, but the rules must be rebuilt against SAP transaction codes and authorization objects and then validated against real access scenarios.
Book an assessment
Get migration-specific SOX control continuity guidance for PeopleSoft to SAP.
Book an Assessment →