IFS to SAP Migration: SOX Compliance Guide
IFS-to-SAP migrations usually happen for one of two reasons: a private-equity owner standardizing a portfolio company onto the group's SAP instance, or a manufacturer that has outgrown IFS Cloud's scale and wants SAP S/4HANA's broader finance and supply-chain footprint. Either way, the SOX story is different from a same-tier ERP swap. IFS's security model is built around permission sets and projects tied loosely to its functional modules, with change tracking that is thinner than what most external auditors expect from a public-company control environment. SAP S/4HANA gives you a more rigorous authorization-object model, and that rigor is exactly what trips teams up: controls that were informally enforced in IFS — a manager 'always' reviewing something, a workflow step nobody bothered to lock down — now have to be explicitly designed into SAP roles or they don't exist. This guide covers the SOX-continuity sequence for that cutover, not the general functional and data-migration plan your systems integrator already owns.
Before you start
- ·Current-state IFS control inventory: every ICFR-relevant control (purchase approval, journal entry, inventory adjustment, master data change) mapped to its IFS permission set or workflow rule and its evidence source
- ·SoD conflict list built manually from IFS permission sets, since most IFS installations do not have a dedicated automated SoD-analysis tool comparable to SAP GRC
- ·SAP role design workshop with Internal Audit or a control-design resource present, not just a functional consultant translating IFS screens into SAP transaction codes
- ·Data migration scope agreed for master data with control implications — vendor banking details, customer credit limits, chart-of-accounts mappings — since these are common targets for fraud and need extra scrutiny during conversion
- ·Cutover calendar reviewed with the external auditor, including which fiscal period's control testing will span both systems
Migration steps
Document IFS controls as they actually operate, not as policy says they should
IFS deployments, especially in mid-market manufacturing and project-based businesses, often drift from their original control design over years of permission-set edits made by whoever was available at the time. Before mapping anything to SAP, interview control owners and pull actual permission-set assignments to confirm what access exists today, not what the original implementation documented. This baseline is what protects you when the auditor asks how you know a control existed in the legacy system before cutover.
Translate IFS permission sets into SAP authorization objects deliberately
IFS permission sets tend to be broader and more role-generic than SAP's transaction-and-object model expects. Do not build one SAP role per IFS permission set — that just imports IFS's looser boundaries into a system capable of much tighter ones. Instead, break each IFS permission set down into the individual duties it actually grants, then rebuild SAP roles around SOX-relevant duty separation: who can create a vendor versus who can approve a payment to one, who can post a journal entry versus who can release it.
Build (or acquire) SoD analysis for the new SAP environment before go-live
If IFS never had automated SoD tooling, this migration is often the first time the organization gets one — typically SAP GRC Access Control or a comparable third-party SoD scanner. Run the full SoD ruleset against the designed SAP roles before any account is provisioned in production, and route every conflict to a documented business decision: redesign the role, or accept the conflict with a named compensating control. Treat this as a project milestone with a sign-off, not a background IT task.
Re-provision users against the new role catalog, gated by the SoD check
Provisioning teams under go-live pressure will try to replicate each user's IFS access '1:1' in SAP to avoid support tickets. Resist this — IFS access rarely maps cleanly, and replicating it defeats the SoD redesign work from the previous step. Require every new SAP account to pass the SoD gate before activation, with exceptions requiring the same sign-off as any other conflict.
Map change-management evidence to SAP's transport process
IFS configuration changes are often tracked informally — a change log spreadsheet, a ticketing system not tightly coupled to the actual configuration change. SAP's transport system (STMS) gives you a structured, timestamped, approver-linked change record, but only if your transport landscape and approval workflow are configured to require it. Confirm transport approval gates are active in the target SAP landscape before go-live, and map every prior IFS change-management control to its SAP transport equivalent explicitly in the control matrix.
Address the reporting and reconciliation gap during parallel run
IFS's financial and inventory reports often feed manual reconciliation routines that finance teams have tuned over years. SAP's native reports produce different totals structures and different drill-down paths, and reconciliation controls built around IFS output will not simply transfer. Rebuild and test each reconciliation control against SAP's actual output during parallel run, not after go-live, and document any interim manual workaround as a time-bound compensating control.
Run one full ICFR control test cycle inside SAP before closing the project
Before declaring the migration complete, test every control in the matrix — access review, SoD scan, change sample, key reconciliation — inside the live SAP environment, and compare the results directly against the IFS-era control matrix. This is the evidence that lets you tell the auditor the control environment survived the platform change, rather than asking them to take it on faith.
Where SOX continuity breaks
- ·SAP roles built as literal translations of IFS permission sets, carrying forward access that was never actually reviewed for SoD conflicts in IFS
- ·No automated SoD tool ever existed in IFS, so the organization has no baseline conflict inventory to compare the new SAP ruleset against — conflicts get 'discovered' for the first time post-cutover instead of resolved before it
- ·Reconciliation controls tuned to IFS report formats break silently in SAP because nobody re-validated the underlying data against the old report before switching finance teams over to the new one
- ·Transport approval gates left in default/permissive configuration in the new SAP landscape, so the promised improvement in change-management evidence never actually materializes
- ·Vendor banking and customer credit-limit master data migrated without a dedicated review step, creating a fraud-relevant blind spot precisely at the moment access controls are being rebuilt
After the cutover
After cutover, run at least one full fiscal close inside SAP with enhanced monitoring on the highest-risk controls — journal entry approval, vendor master changes, SoD exceptions — before retiring IFS access entirely. Use that close as the baseline evidence set for the next external audit cycle, and formally retire any compensating controls once the equivalent SAP control is confirmed operating.
Common questions
Not natively at the same depth. Most IFS deployments manage SoD manually through spreadsheet-based conflict matrices reviewed periodically, rather than an automated rules engine scanning live access. If your organization has never run automated SoD analysis, budget time in the SAP project for building that ruleset from scratch rather than assuming there's an existing baseline to migrate.
Book an assessment
Get migration-specific SOX control continuity guidance for IFS to SAP.
Book an Assessment →