PeopleSoft to Oracle Migration: SOX Compliance Guide
This is the common direction of Oracle-to-Oracle modernization: organizations running legacy on-premises PeopleSoft moving to Oracle Fusion Cloud as PeopleSoft support and upgrade cadence increasingly favor Fusion, or as the organization wants cloud deployment, modern reporting, and Fusion's more granular security model. Because both are Oracle products, there's a real temptation to treat this as a technical upgrade rather than a full control migration — it is not. PeopleSoft's permission-list-and-role security model and Fusion Cloud's duty-role, data-security-policy architecture are built on fundamentally different logic, and PeopleSoft's change-tracking and SoD tooling (where it exists at all — many PeopleSoft shops run SoD manually) do not translate directly into Fusion's Risk Management Cloud or Advanced Access Controls. Every ICFR-relevant control needs explicit re-mapping, the same as any cross-platform migration. This guide covers that sequence for a PeopleSoft-to-Fusion move.
Before you start
- ·Current-state PeopleSoft control matrix: every ICFR-relevant control documented with its permission-list/role mechanism, SoD dependency (manual or tool-based), and evidence source
- ·Honest inventory of whether PeopleSoft SoD was ever automated — many long-running PeopleSoft deployments manage SoD manually or through periodic access review rather than continuous rule-based scanning, and that gap needs to be closed in the target design, not carried forward
- ·Oracle Fusion Cloud role design workshop completed with Internal Audit present, working from the PeopleSoft control matrix, not a generic Fusion implementation template
- ·Data migration scope reviewed for control-relevant master data — vendor banking details, approval hierarchies, chart-of-accounts mappings — given how long PeopleSoft instances typically run before this kind of modernization, which increases the chance of undocumented drift
- ·Cutover calendar agreed with the external auditor, including which fiscal period's control testing spans both systems
Migration steps
Document PeopleSoft controls as they actually operate today
Legacy PeopleSoft instances often accumulate years of permission-list edits, one-off access grants, and process workarounds that drift from the original control design. Before mapping anything to Fusion, confirm current-state access and control operation directly against the live system and control owner interviews, not against original implementation documentation that may be a decade or more out of date.
Map PeopleSoft permission lists and roles to Fusion duty roles and data security policies explicitly
These are architecturally distinct models — do not assume shared vendor ownership means a straightforward technical translation. A PeopleSoft control built on a specific permission-list restriction may require a combination of Fusion duty roles and data security policies to reproduce the same boundary. Go control by control, confirming the Fusion equivalent actually enforces the same restriction, not just a functionally similar one.
Build or formalize the SoD ruleset for Fusion, closing any gap that existed in PeopleSoft
If SoD in PeopleSoft was managed manually or through periodic review rather than automated scanning, this migration is the opportunity to close that gap using Oracle Risk Management Cloud or Advanced Access Controls. Build the ruleset from the actual duty-separation requirements of the business, not by trying to reverse-engineer rules from a PeopleSoft access model that was never designed with automated SoD scanning in mind.
Design Fusion roles around the target SoD matrix, not around legacy PeopleSoft role names
PeopleSoft roles that accreted over many years of individual access requests often bundle duties broadly. Carrying that shape into Fusion just re-implements old conflicts under new role names. Build Fusion duty role assignments from the SoD matrix outward — which combinations of access must never coexist — rather than starting from what a user's PeopleSoft access looked like.
Re-provision access role by role against the new Fusion SoD ruleset
Under cutover pressure, provisioning teams default to 'match what they had in PeopleSoft.' Because this is an Oracle-to-Oracle move, that instinct is even stronger here and even more likely to be wrong, since the two systems' access models don't correspond directly. Gate every account activation against a documented SoD check before it goes live.
Establish evidence continuity across the cutover boundary
Confirm PeopleSoft evidence (approval logs, change-management records, reconciliation reports) remains retrievable after decommissioning or archival, and confirm Fusion evidence generation is actually confirmed working in production — not just configured — before PeopleSoft access is cut off. Given how long these legacy systems typically run, plan for a longer evidence retention window than a newer-system migration might require.
Run a full control test cycle in Fusion before declaring the migration complete
Test every ICFR-relevant control in the live Fusion environment and compare results against the pre-migration PeopleSoft control matrix. This test is the check against the 'it's just an Oracle upgrade' assumption that tends to under-scope this migration's control-continuity risk.
Where SOX continuity breaks
- ·Migration treated as a technical cloud upgrade rather than a full control migration because both systems are Oracle products, leading to under-scoped SoD and access re-mapping work
- ·PeopleSoft's historically manual SoD process (where it existed at all) never actually formalized into an automated Fusion ruleset, just carried forward as an ongoing manual review that doesn't scale with Fusion's added configuration complexity
- ·Fusion duty roles built as literal translations of legacy PeopleSoft roles that had accreted broad access over many years, reintroducing old conflicts under new role names
- ·Master data drift accumulated over years of PeopleSoft operation — undocumented vendor or approval-hierarchy changes — migrated into Fusion without a dedicated review, carrying legacy data-quality issues into the new environment
- ·Evidence retention window underestimated for a legacy system that's been running long enough to have open audit periods or litigation holds spanning further back than a typical migration plan accounts for
After the cutover
Once cutover completes, run a formal parallel-testing period — typically one to two fiscal close cycles — with key controls tested in both the legacy PeopleSoft evidence trail (where still retrievable) and the new Fusion environment, investigating any variance before PeopleSoft access is fully decommissioned. The first full control-testing cycle conducted entirely in Fusion becomes the baseline your external auditor uses to assess whether the modernization preserved control effectiveness.
Common questions
No. The security architectures are fundamentally different — PeopleSoft's permission-list-and-role model versus Fusion's duty-role and data-security-policy model — so access, SoD, and change-management controls all require the same full re-mapping a cross-vendor migration would need. Treating it as a light technical upgrade is the most common way this migration under-delivers on control continuity.
Book an assessment
Get migration-specific SOX control continuity guidance for PeopleSoft to Oracle.
Book an Assessment →