SAP to IFS Migration: SOX Compliance Guide
SAP-to-IFS migrations happen most often in asset-intensive, project-based, or field-service-heavy industries — manufacturing, energy, aerospace and defense, utilities — where IFS Cloud's strength in enterprise asset management, project accounting, and service management is the deciding factor over SAP's broader but less specialized functionality. This is a genuine platform replacement for the entity in scope, and it carries the same control-continuity exposure as any SAP-to-competitor ERP migration: SAP's authorization-object model, transport-based change tracking, and GRC Access Control SoD rules do not exist in IFS. IFS Cloud's security is built on its own permission-set and authority-check model with project and work-order-level access controls that reflect its asset- and project-centric design, and its change-tracking and SoD capabilities are generally less mature than SAP GRC's, meaning this migration typically requires real control redesign rather than a like-for-like mapping — particularly for controls tied to project accounting and capital asset controls that IFS structures differently than SAP does.
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, with particular attention to project accounting and fixed-asset controls given IFS's project-centric data model
- ·SoD conflict inventory from SAP GRC Access Control, or a manual matrix, signed off by the SoD risk owner, not IT security alone
- ·IFS Cloud permission-set and authority-check design workshop completed with Internal Audit or a control-design resource present, since IFS's access model is structured around projects, work orders, and asset hierarchies rather than SAP's transaction-code authorization objects
- ·Target-state control matrix drafted: each SAP control mapped to its IFS equivalent, with gaps flagged explicitly where IFS's project- and asset-centric structure doesn't have a direct analog to a transaction-code-based SAP control
- ·Cutover and parallel-run calendar agreed with the external auditor, including which fiscal period's testing will span both systems and how project-in-flight controls will be handled across the cutover boundary
Migration steps
Freeze and export the SAP control baseline
Before IFS configuration begins, capture a complete snapshot of the current SAP control environment: PFCG role assignments, GRC Access Control rule set and risk IDs, transport logs for the trailing 12 months, and the SOX control matrix mapped to evidence artifacts, with specific attention to project system (PS) and fixed-asset (FI-AA) controls that will need careful re-mapping into IFS's project- and asset-centric structure. Store this outside SAP itself as the reconciliation point for the IFS design.
Re-map controls to their IFS equivalent, paying special attention to project and asset controls
Work through the control matrix line by line. Access controls built on SAP authorization objects need to be reproduced through IFS's permission sets and authority checks, which are structured around projects, work orders, and asset hierarchies rather than transaction codes — a SAP control restricting who can post to a specific cost center may need to become an IFS control restricting who can charge time or cost to a specific project or work order, which is a genuinely different access model, not just a renamed equivalent.
Rebuild the SoD rule set against IFS's permission-set structure
IFS's native SoD capability is generally less mature than SAP GRC Access Control's automated conflict monitoring. Decide early whether IFS-native permission-set analysis is sufficient for this environment's risk profile or whether a third-party SoD tool with IFS support is needed, then rebuild the underlying conflict logic — which duties must never combine — against IFS's actual permission and authority-check structure rather than assuming a translated rule set will catch the same conflicts.
Design IFS roles from the target SoD matrix, not by mirroring SAP's authorization structure
SAP composite roles built up over years often carry latent conflicts; carrying that shape into IFS permission sets just re-implements the same problem under a different structure. Build IFS roles from the SoD matrix outward, particularly focused on project- and work-order-level access where IFS's data model diverges most from SAP's, checking every role combination against the matrix before finalizing the catalog.
Gate cutover provisioning on a documented SoD check, with special handling for in-flight projects
Cutover provisioning under deadline pressure defaults to 'give them what they had in SAP.' Require every account created during cutover to pass a documented SoD check against the finalized IFS role catalog before it goes live. For projects or work orders active at the cutover boundary, document explicitly how access and approval authority transfer, since a project manager's authorization in SAP PS doesn't automatically translate to equivalent authority in IFS's project structure.
Document cutover-period compensating controls
For the weeks spanning parallel run and go-live, some IFS-native controls — asset depreciation reconciliation, project cost control reports, work-order approval workflows — 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 IFS control is confirmed operating effectively.
Run a full control test cycle in IFS before closing the project
Before declaring the migration complete, execute one full test of every ICFR-relevant control in the live IFS environment — access review, SoD conflict scan, change-management sample, project and asset-control reconciliations — and compare results to the pre-migration SAP control matrix. Gaps found here get remediated while the project team and budget still exist; gaps found by the external auditor later become findings with a remediation plan attached.
Where SOX continuity breaks
- ·IFS permission sets built to mirror SAP's broad composite roles instead of being redesigned around IFS's project- and asset-centric access model, carrying forward the same conflicts under a different structure
- ·Project accounting and fixed-asset controls re-mapped too literally from SAP's transaction-code model, missing that IFS structures authority around projects and work orders rather than cost centers and transaction types
- ·IFS's native SoD capability assumed to match SAP GRC's rigor without an honest gap assessment, leaving real conflicts undetected
- ·In-flight projects and work orders crossing the cutover boundary left with unclear or unauthorized access because project-manager authority in SAP PS wasn't explicitly re-established in IFS before go-live
- ·Change-management evidence gap at cutover — SAP's transport log is retired before IFS's configuration and change audit trail is confirmed to capture equivalent approver and timestamp detail
After the cutover
After cutover, run a formal parallel-testing period — typically one to two fiscal close cycles — comparing key controls against the legacy SAP evidence trail, while still retrievable, and the new IFS environment, with particular focus on project and asset controls given how differently IFS structures that data. The first complete control-testing cycle run entirely in IFS becomes the baseline your external auditor uses to assess whether the migration preserved control effectiveness.
Common questions
Generally not at the same level of automated maturity. IFS Cloud's permission-set and authority-check model supports functional access restriction, but its native conflict-detection and mitigation-control workflow is less developed than SAP GRC. Many organizations moving from SAP to IFS supplement native capability with a third-party SoD tool, particularly for larger or more complex environments.
Book an assessment
Get migration-specific SOX control continuity guidance for SAP to IFS.
Book an Assessment →