SAP to PeopleSoft Migration: SOX Compliance Guide
SAP-to-PeopleSoft migrations happen most often in higher education, public sector, and healthcare systems that already run PeopleSoft HCM and want to consolidate financials onto the same platform, or in organizations standardizing on Oracle's PeopleSoft line after an acquisition. Whatever the driver, the SOX exposure is the same: SAP's PFCG role model, GRC Access Control SoD rules, and transport-based change log do not exist in PeopleSoft. PeopleSoft's security is built on permission lists, roles, and row-level security through PeopleSoft Query and Tree security, its change record lives in PeopleSoft Change Assistant and the underlying database audit tables, and SoD analysis typically runs through PeopleSoft's own Risk Matrix tooling or a third-party GRC layer bolted on top. Every control your auditor has tested against SAP for years needs a documented Peoplesoft equivalent before go-live, not a promise that IT will 'figure out the mapping' during hypercare. This guide covers the control-continuity sequence, not the generic data-conversion plan your systems integrator already has.
Before you start
- ·Current-state SAP 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 SAP GRC Access Control, or a manual matrix, signed off by the SoD risk owner — not IT security alone
- ·PeopleSoft permission list and role design workshop completed with Internal Audit or a control-design resource present, not just the PeopleSoft technical team
- ·Target-state control matrix drafted: each SAP control mapped to its PeopleSoft equivalent, with any control that has no direct PeopleSoft analog flagged explicitly
- ·Cutover and parallel-run calendar agreed with the external auditor, including which fiscal period's control testing will span both systems
Migration steps
Freeze and export the SAP control baseline
Capture a complete snapshot of the current SAP control environment before any PeopleSoft configuration begins: PFCG role assignments and composite role structures, GRC Access Control rule set with risk IDs, transport logs for the trailing 12 months, and the SOX control matrix mapping each control to its evidence artifact. Store this baseline outside SAP itself. It is the reference point you reconcile the PeopleSoft design against, and the artifact your auditor will expect when asking how you verified nothing was lost in translation.
Translate each control into its PeopleSoft equivalent, not its nearest-sounding analog
Work the control matrix line by line. Access controls built on SAP authorization objects and company-code restrictions need to be reproduced through PeopleSoft permission lists, roles, and row-level security (often via PeopleSoft Tree security for department or business-unit scoping) — these constructs do not map one-to-one, and a single SAP field-level restriction may require several stacked PeopleSoft security definitions to reproduce. Change-management evidence that lived in SAP's transport log needs a PeopleSoft equivalent: Change Assistant logs plus database-level audit tables for configuration changes, confirmed to capture requester, approver, and timestamp with the same rigor.
Rebuild the SoD rule set against PeopleSoft's permission-list structure
PeopleSoft does not use SAP transaction codes, so an imported SAP SoD rule set is meaningless without a full rebuild. Identify or configure a PeopleSoft-compatible SoD tool — PeopleSoft's own Risk Matrix functionality or a third-party GRC product with PeopleSoft support — and rebuild each conflict rule against PeopleSoft menu items, components, and permission lists. Validate the rebuilt rule set catches the same real-world conflicts the SAP rules caught; a naive keyword-based translation routinely misses conflicts because PeopleSoft's permission structure groups functions differently than SAP's authorization objects do.
Design PeopleSoft roles from the target SoD matrix outward
Do not build PeopleSoft roles by copying the shape of SAP composite roles — those accreted over years of incremental access grants and often already contain latent conflicts. Start from the SoD matrix: define which duties can never combine in a single user's access, then construct permission lists and roles that structurally prevent that combination. This is slower up front than a like-for-like mapping exercise, but it is the only approach that doesn't just re-implement existing SAP conflicts under new PeopleSoft role names.
Gate cutover provisioning on a documented SoD check
During cutover, provisioning teams under deadline pressure default to giving each user 'the PeopleSoft access that matches what they had in SAP.' This is how conflicts resurface. Require every access grant during cutover to pass a documented SoD check against the new PeopleSoft rule set before the account goes live, with any conflict routed to a compensating-control decision — not discovered three weeks later during the first control test.
Document cutover-period compensating controls
For the weeks spanning parallel run and go-live, some automated controls won't be validated in production yet — PeopleSoft-native reconciliation reports may not have a full cycle of data, and some interface controls may not have been exercised against a live transaction volume. Document which controls are affected, the compensating control covering the gap (typically an enhanced manual review or secondary approval), the owner, and the retirement date once the primary control is confirmed operating in PeopleSoft.
Run a full control test cycle in PeopleSoft before closing the project
Before declaring the migration complete, execute one full test of every ICFR-relevant control in the live PeopleSoft environment — access review, SoD conflict scan, change-management sample, key reconciliations — and compare the results to the pre-migration SAP control matrix. Gaps caught here get fixed while the project team and budget still exist. Gaps caught by the external auditor after project closeout become findings with a remediation plan and your name on it.
Where SOX continuity breaks
- ·PeopleSoft permission lists built to mirror SAP's broad composite roles instead of being redesigned from the target SoD matrix, carrying forward the same access conflicts under new names
- ·SoD rule set imported or approximated from SAP without a real rebuild against PeopleSoft's permission-list and component structure, producing false negatives that miss genuine conflicts
- ·Change-management evidence gap at cutover — SAP's transport log is retired before PeopleSoft's Change Assistant and audit-table logging are confirmed to capture the same approver and timestamp detail
- ·Cutover compensating controls never formally retired once the PeopleSoft primary control is confirmed working, leaving a manual workaround running in production indefinitely
- ·Row-level security in PeopleSoft (Tree security, department-level scoping) misconfigured so that a control assumed to restrict access by business unit does not actually restrict it, discovered only when an access review flags unexpected visibility
After the cutover
After cutover, run a formal parallel-testing period — typically one to two fiscal close cycles — where key controls are tested against both the legacy SAP evidence trail, while still retrievable, and the new PeopleSoft environment, investigating any variance before SAP access is fully decommissioned. The first complete control-testing cycle run entirely in PeopleSoft becomes the baseline your external auditor uses to judge whether the migration preserved control effectiveness.
Common questions
PeopleSoft includes Risk Matrix functionality for defining and testing SoD conflicts, but it is not a direct feature parity with SAP GRC Access Control. Many organizations pair PeopleSoft with a third-party GRC tool for more mature conflict analysis and remediation workflow, particularly if the SAP environment relied heavily on GRC's automated monitoring and mitigation controls.
Book an assessment
Get migration-specific SOX control continuity guidance for SAP to PeopleSoft.
Book an Assessment →