Should we implement SAP GRC as part of this migration or manage SoD manually?

Most organizations moving to SAP's authorization-object model from a comparatively lighter Infor access model find manual SoD review unsustainable at scale. Budget SAP GRC Access Control (or an equivalent third-party tool) into the migration project rather than treating it as a later purchase.

How do we handle audit evidence for controls that operated partly in Infor and partly in SAP during the same fiscal year?

Archive Infor's security, workflow, and SoD reports in queryable form before decommissioning, and be explicit in your control narratives about which system evidenced the control for each period within the transition year. Auditors will expect to see both, tied together by the transaction population, not one and an assumption about the other.

Is a second approver required on SAP transport imports?

Not by default. SAP logs transport activity automatically but doesn't enforce a second-approver gate out of the box — that has to be configured through transport authorization restrictions if your control design requires segregation between the person who creates a transport and the person who imports it to production.

migrate infor to sap sox compliance

Infor to SAP Migration: SOX Compliance Guide

Infor-to-SAP migrations tend to happen when an organization needs a global consolidation and reporting footprint that its Infor CloudSuite deployment — often industry-specific and strong at plant or division level — was never designed to provide across many entities and currencies. This is common after acquisition, IPO readiness work, or a parent company standardizing subsidiaries onto a single ERP. The SOX challenge is that Infor's security architecture (which itself varies by product — CloudSuite Industrial, LN, M3 each differ) has to be translated into SAP's authorization-object model, and that translation is a control re-design exercise, not a data-migration exercise. Every control your auditors currently test against Infor evidence needs a rebuilt, re-tested SAP equivalent before it can be relied on for the next reporting period.

Book an Assessment →

Prerequisites

Before you start

·Documented Infor security/role structure and workflow (ION or product-native) mapped to the business processes each supports, for the specific Infor product in scope
·Infor SoD rule set or equivalent access-review documentation, in a form that can be translated to SAP authorization objects
·A named SAP security architect accountable for the target role design, working from the SoD rule set rather than from provisioning convenience
·Internal audit sign-off gate on the SAP role design and build, exercised before go-live rather than surfaced as a post-implementation finding
·External auditor notified of the migration timeline and scope before interim fieldwork is scheduled

Process

Migration steps

Translate Infor's security and workflow model into SAP authorization-object requirements

Because Infor's access control varies meaningfully by product line, the first task is documenting exactly how the source system enforces access today — role, security class, and site restrictions in the specific Infor product — before mapping each to the SAP authorization objects and PFCG role structure that reproduce the same boundary. Do not assume a generic 'Infor to SAP' template applies; the crosswalk has to be built against the actual source configuration.

Run SoD analysis against the proposed SAP role design before any production provisioning

SAP's authorization objects are composable, meaning a user can inherit conflicting access from two individually reasonable roles designed by different teams — a failure mode that's less likely to occur invisibly in Infor's typically coarser role model. Run your accepted SoD conflict definitions (via SAP GRC Access Control if it's part of the build, or an equivalent third-party tool) against every proposed role combination before go-live, with internal audit sign-off on the result.

Rebuild Infor workflow-driven approvals as SAP release strategies and workflow

Approval logic enforced through Infor's ION workflows or product-native approval engine — PO thresholds, journal entry review, payment release — needs to be rebuilt in SAP using release strategies and workflow (SWI1/SWI5). Get written confirmation from each control owner that the rebuilt SAP version enforces the same threshold and routing as the original, before that control is relied on for a live close.

Maintain evidence continuity through the cutover period

Decide before cutover how controls will be evidenced for transactions that straddle the transition — which system's logs and approval trail apply. Export and archive Infor security, workflow, and SoD analysis reports in queryable form before Infor access is decommissioned; the transition-year audit period will require evidence from both systems, and a decommissioned Infor environment can't be queried retroactively.

Define compensating controls while SAP's automated and GRC controls are tuned

Expect a stabilization period — typically a full quarter close cycle — before SAP GRC rule sets (if in scope) and other automated controls (duplicate payment detection, three-way match tolerances) are fully calibrated against live volume. Use documented, time-bound manual compensating controls for that window, with sign-off required to retire them once automated controls are confirmed operating as designed.

Establish and test SAP-specific ITGCs for transport-based change management

SAP's transport request process (STMS) replaces whatever change-promotion path Infor used, and it's a new ITGC that needs explicit control design — particularly whether a second approver is required at transport import, since SAP doesn't enforce that by default. Walk a sample change through the full path before the first quarter-end close on SAP, capturing request, approval, and independent-review evidence.

Reconcile migrated balances independently before they support the first SAP close

Tie the opening trial balance and other migrated financial-statement-relevant balances back to the last Infor-generated trial balance, with accounting sign-off on variances, independent of the migration team's own load-confirmation process.

Pitfalls

Where SOX continuity breaks

·Treating the SAP role build as a like-for-like port of Infor security groups instead of a deliberate re-design that accounts for SAP's finer-grained but more composable authorization model.
·Underestimating the SoD tooling gap — moving from a lighter Infor access model to SAP's authorization-object complexity without budgeting for SAP GRC or an equivalent third-party tool.
·Losing Infor product-specific security and workflow documentation before the transition-year audit period is fully archived, especially where the Infor product itself (LN, M3, CloudSuite Industrial) has idiosyncratic reporting.
·Skipping a second-approver control on SAP transport import, assuming automatic change logging alone satisfies the change-management ITGC.
·Running the first SAP close without a defined, time-bound compensating-control plan, so normal go-live calibration issues get reported as control deficiencies.

Next Step

After the cutover

After SAP's automated controls and (if applicable) GRC rule sets are confirmed stable through one full close, retire the compensating controls on their scheduled date and add the SAP transport and provisioning ITGCs to the standing internal audit test plan.

FAQ

Common questions

Yes, meaningfully. CloudSuite Industrial, LN, and M3 have different security and workflow architectures, so the crosswalk to SAP authorization objects has to be built against the specific source system in scope — there's no single generic Infor-to-SAP mapping.

Next step

Book an assessment

Get migration-specific SOX control continuity guidance for Infor to SAP.

Book an Assessment →