SoD Conflicts in ERP Migrations: Why Post-Migration Detection Is Too Late

Segregation of duties analysis is a well-understood requirement in enterprise access governance. The principle is simple: no single user should have permissions that allow them to both initiate and approve the same business process. An accounts payable clerk who can also approve payments. A procurement officer who can both create and approve purchase orders. These combinations represent control failures that auditors flag and regulators penalize.

In steady-state operations, organizations manage SoD through periodic access reviews, GRC platforms, and role design standards. But during an ERP migration, these controls often break down. The urgency of the migration timeline, the complexity of mapping thousands of users to a new authorization model, and the gap between the old and new role structures create conditions where SoD violations proliferate.

The Timing Problem

Most migration methodologies treat SoD analysis as a validation step that occurs after the role mapping is substantially complete. The mapping team builds the target-state assignments, then runs a conflict analysis to identify violations, then iterates on the design to resolve them.

This sequential approach has a structural problem: by the time SoD violations are detected, the mapping decisions that created them are already embedded in the design. Resolving a conflict often means re-mapping multiple users, which cascades into re-testing, re-validation, and stakeholder re-approval. Each remediation cycle adds weeks to the timeline and significant cost to the project.

In practice, time pressure forces compromises. Some violations get documented as accepted risks with mitigation controls rather than resolved through proper role redesign. These accepted risks accumulate, and the target system goes live with a known set of SoD violations that "will be addressed post-go-live." That post-go-live remediation often never happens, or happens only when an auditor forces the issue.

What Goes Wrong in Migration SoD

Several factors make SoD analysis particularly difficult during migrations.

First, the conflict rules themselves may need to be redefined. SoD rules written for SAP ECC transaction codes don't directly translate to S/4HANA Fiori apps. The underlying authorization objects may have changed, and the business process flows may be different. Migration teams either need to rebuild their conflict ruleset for the target platform or find a way to translate existing rules, both of which require specialized expertise.

Second, the scale of the analysis is prohibitive for manual review. A 5,000-user environment with 200 roles and a ruleset of 100 SoD pairs generates millions of potential conflict combinations. Even with tooling, the review and disposition of flagged violations is time-consuming. Without tooling, it's effectively impossible to do comprehensively.

Third, migration teams are often composed of specialists who understand the technical aspects of role mapping but lack deep GRC expertise. They may not fully appreciate the audit implications of certain role combinations, or they may not have access to the organization's current SoD ruleset and exception documentation.

The Cost of Late Detection

When SoD violations reach production, the remediation cost increases by an order of magnitude compared to catching them during the design phase. In the design phase, fixing a violation means adjusting a mapping in a spreadsheet or tool. In production, it means changing a user's live access, which requires change management approval, communication to the affected user, potential retraining, and regression testing to ensure the change doesn't break their workflows.

Beyond direct remediation costs, production SoD violations create audit exposure. SOX audits, in particular, view SoD violations in production systems as control deficiencies. Material deficiencies can trigger management letter comments, increased audit fees, and in severe cases, restatement risk. The cost of a single audit finding can exceed the cost of the entire security workstream that produced it.

Integrated SoD Analysis: A Different Approach

The alternative is to integrate SoD analysis directly into the mapping process, rather than treating it as a separate downstream activity. In this model, every proposed user-to-role assignment is checked against the conflict ruleset in real time. Before a mapping decision is finalized, the team can see whether it would create a new violation.

This approach has several advantages. It prevents violations from entering the design in the first place, eliminating the need for separate remediation cycles. It gives the mapping team immediate feedback on the compliance implications of their decisions. And it produces a cleaner target-state design that requires less post-go-live adjustment.

The technical requirement is a mapping tool that maintains an active SoD ruleset and evaluates assignments against it continuously. This isn't a new concept in GRC tooling, but it's rarely implemented in the migration-specific context where it's most needed.

Building a Migration-Ready Ruleset

For organizations planning a migration, the practical first step is to establish a target-platform SoD ruleset before the mapping work begins. This means translating existing conflict rules from the source platform's authorization model to the target platform's model, accounting for changes in transaction codes, authorization objects, and business process flows.

This upfront investment in ruleset preparation enables real-time conflict detection during mapping and reduces the risk of discovering fundamental design problems late in the project. It also provides a foundation for ongoing SoD monitoring in the target system after go-live, connecting the migration workstream to the organization's broader access governance program.

The key insight is that SoD analysis isn't a phase of the migration. It's a continuous constraint that should inform every mapping decision from the start.