Epicor to SAP Migration: SOX Compliance Guide
Epicor-to-SAP migrations usually follow growth — a manufacturer that outgrew Epicor Kinetic's multi-entity, multi-currency, or global consolidation capabilities, often after acquisition activity pushed the business past what a mid-market ERP was designed to run. Moving to S/4HANA or ECC brings real gains in consolidation and global statutory reporting, but it also means trading Epicor's comparatively lightweight security-group model for SAP's much more granular, and much more complex, authorization-object system. That complexity cuts both ways for SOX: SAP lets you build finer-grained controls than Epicor could support, but it also creates far more surface area for authorization objects to compose into unintended access conflicts. The migration project plan and the SOX control re-mapping plan need to be the same document, reviewed by internal audit, not two documents that get reconciled after go-live.
Before you start
- ·Current Epicor security group and menu security documentation, with each group's function mapped to the business process it supports
- ·Epicor SoD rule set (native or third-party) exported in a form that can be translated to SAP's authorization-object structure
- ·A named SAP security architect with explicit accountability for building the target role design against the SoD rule set, not just against provisioning convenience
- ·Internal audit sign-off gate built into the SAP role-design and build process, before go-live, not as a post-implementation audit finding
- ·External auditor briefed on the migration scope and timeline before interim testing is scheduled
Migration steps
Translate Epicor security groups into SAP authorization-object requirements
Epicor secures access largely through security groups tied to menu items and site restrictions — a coarser model than SAP's authorization objects, which compose transaction codes with field-level values like company code, plant, and document type. Going from Epicor to SAP is an opportunity to build more precise controls than the legacy system supported, but only if someone deliberately designs that precision rather than replicating Epicor's coarser groupings inside SAP roles by default, which produces PFCG roles broader than they need to be.
Design and test the SoD rule set against SAP's authorization-object combinations before go-live
SAP's composability — a user inheriting conflicting capability from two individually reasonable roles built by different teams — is the most common source of undetected SoD conflicts in new SAP environments. Run the SoD rule set (ideally using SAP GRC Access Control if it's part of the target architecture, or an equivalent third-party tool) against every proposed role combination before a single production user is provisioned. Retrofitting SoD analysis after go-live means remediating live access instead of preventing the conflict.
Rebuild Epicor approval workflows as SAP release strategies and workflow
Epicor's approval and workflow engine controls — PO approval routing, credit hold logic, journal entry review — need to be rebuilt using SAP release strategies (for purchasing documents) and workflow (SWI1/SWI5, for journal entries and other document types). Each rebuilt control needs sign-off from its control owner confirming the SAP version enforces the same threshold and routing logic as the Epicor version it replaces, documented before cutover, not inferred from a successful test transaction.
Preserve evidence continuity across the cutover boundary
Define, before cutover, how each SOX-relevant control will be evidenced for the weeks that straddle the transition — which system's approval trail applies to a transaction that started in Epicor and closed in SAP. Export and archive Epicor security-group reports, workflow logs, and SoD analysis output in a format that remains queryable after the Epicor environment is decommissioned; don't plan on reopening a retired system to pull evidence during the next audit cycle.
Establish compensating controls while SAP GRC (if used) and automated controls are tuned
If the SAP build includes GRC Access Control and Process Control, expect a calibration period before continuous control monitoring rules are fully tuned against live transaction volume. For the interval between go-live and rule-set stabilization, use manual compensating controls — additional payment-batch review, manual SoD spot-checks — with a defined end date rather than an open-ended manual process that never gets retired.
Stand up and test SAP-specific ITGCs for transport-based change management
SAP's transport request system (STMS) is a new ITGC relative to Epicor's change-management process, and it needs its own control design — specifically, whether transport import requires a second approver, since SAP does not enforce that by default. Walk a sample configuration change through the full transport path (creation, approval, import to production) before the first quarter-end close on SAP, capturing the same evidence categories your auditors expect.
Independently reconcile migrated balances before they underpin the first SAP-native close
Tie the opening trial balance, open AP/AR, and inventory valuation loaded into SAP back to the last Epicor-generated trial balance, with an accounting sign-off on any variance. This reconciliation should be independent of the migration/implementation team's own load-confirmation testing.
Where SOX continuity breaks
- ·Building SAP roles as direct copies of Epicor's coarser security groups, which under-uses SAP's granularity and can actually widen access compared to the Epicor baseline.
- ·Delaying SoD rule-set testing until after go-live because 'the roles look reasonable' — SAP's authorization-object composability makes conflicts far less visible on inspection than Epicor's simpler model.
- ·Not budgeting for SAP GRC (or an equivalent third-party SoD tool) as part of the migration cost, then discovering post-go-live that manual SoD monitoring at SAP's scale isn't sustainable.
- ·Leaving transport import without a second-approver gate configured, assuming SAP's automatic change logging is itself a sufficient control.
- ·Losing access to Epicor's SoD and workflow reporting once the license lapses, before the transition-year audit evidence has been fully archived.
After the cutover
Once SAP GRC rule sets (or the equivalent third-party tooling) are fully tuned and the first close cycle completes without exception, retire the interim compensating controls and incorporate the new SAP transport and provisioning ITGCs into the standing audit test plan.
Common questions
Not automatically. SAP's authorization-object model can support more granular controls than Epicor's security groups, but that granularity only becomes a stronger control environment if someone deliberately designs roles to use it. Naively replicating Epicor's coarser access patterns inside SAP forfeits the advantage and can introduce new SoD risk from SAP's role composability.
Book an assessment
Get migration-specific SOX control continuity guidance for Epicor to SAP.
Book an Assessment →