Microsoft to SAP Migration: SOX Compliance Guide
Moving from Dynamics 365 to SAP (typically S/4HANA) is a shift from a federated governance model to a single-vendor one. In Dynamics, identity sits in Entra ID, transactional access sits in Dynamics security roles, and segregation-of-duties enforcement usually sits in a third-party tool or a custom Power Platform build, because Dynamics has no native GRC engine equivalent to SAP's. SAP consolidates most of that into one system: authorization objects, transport-based change management, and (if licensed) SAP GRC Access Control and Process Control all live inside or directly against the ERP itself. That consolidation is a genuine control improvement in most cases, but it also means your prior control narrative — "Entra handles identity, Dynamics handles roles, [Tool X] handles SoD" — has to be rewritten almost entirely rather than mapped piece by piece. Auditors evaluating a Dynamics-to-SAP cutover will want to see that the new authorization object model is at least as granular as what it replaced, and that transport-based change control is properly gated before it's relied on as an automatic control.
Before you start
- ·Full inventory of Dynamics 365 security roles, duties, and privileges in SOX scope, decomposed to the actual business functions each grants — the source material for building SAP authorization objects and PFCG roles.
- ·Decision made and documented on SAP GRC licensing (Access Control, Process Control, or both) before role design starts, since building PFCG roles without a target GRC ruleset in mind leads to rework.
- ·Current Entra ID group structure and conditional access policy documented, so SAP's authentication integration (SAML/SSO) preserves the identity governance controls already in place rather than creating a parallel, weaker path.
- ·Transport landscape (development, quality, production) and transport approval workflow defined before the first configuration change is made, not retrofitted after go-live.
- ·Named control owner for every SOX-relevant Dynamics/Power Platform control, accountable for confirming the SAP-side equivalent exists and has been tested before cutover.
Migration steps
Translate Dynamics duties and privileges into SAP authorization objects and PFCG roles
SAP's authorization model is more granular than Dynamics' duty/privilege structure, which is an opportunity, not just a translation exercise. For each Dynamics security role in scope, identify the specific transactions, field-level restrictions, and organizational scoping (company code, plant) it should map to in SAP. Because SAP allows finer control than Dynamics did, resist the urge to build broad PFCG roles that replicate Dynamics' coarser bundling — this defeats the purpose of the more granular model and can reintroduce SoD risk you're specifically trying to reduce by moving platforms.
Build the SAP GRC (or custom) SoD ruleset fresh against the new authorization object model
Whatever SoD tool enforced conflict detection in the Dynamics environment — a third-party product or custom Power Platform logic — does not carry forward. If you're licensing SAP GRC Access Control, its rule set must be built and tuned against your specific PFCG role design; SAP's out-of-box ruleset is a starting template, not a finished product. Run the new ruleset against every proposed user role assignment before go-live and reconcile the conflicts found against your prior Dynamics-era violation history to confirm nothing material was lost in translation.
Re-provision access using current job function, aligned to SAP's organizational structure
Do not migrate Dynamics role assignments directly. Rebuild each user's SAP access from current job responsibility and manager attestation, explicitly mapped against SAP's organizational units (company code, plant, purchasing organization) which likely don't align one-to-one with how Dynamics scoped legal entities or business units. This is also the point to decide how SAP authentication integrates with your existing Entra ID tenant — via SAML SSO is standard — so identity governance controls already built around Entra don't have to be duplicated inside SAP.
Establish the transport landscape and change-approval workflow before the first production change
SAP's transport request mechanism (STMS) will become your primary change-management evidence source, replacing whatever combination of Azure DevOps pipelines and LCS environment logs covered this in Dynamics. Configure the development-quality-production landscape and require documented approval before transport import into production from day one — retrofitting approval gates after go-live leaves a gap in your change evidence for the earliest and often highest-risk configuration period.
Rebuild automated financial controls as SAP configuration and validate against prior test scripts
Approval hierarchies, three-way match tolerances, and document type restrictions that were Dynamics workflow or Power Automate logic need to be rebuilt as SAP release strategies, tolerance keys, and document type configuration. Test each rebuilt control against the same test scripts and expected exception population used under Dynamics before relying on it for a live SOX assertion — SAP's release strategy logic in particular behaves differently around delegation and multi-level approval than Dynamics workflow did.
Run a shadow-period close capturing evidence from both systems
For at least one full close cycle, keep Dynamics-side evidence capture running alongside the new SAP controls, even after SAP goes live as system of record. This gives you a fallback if an SAP-side control fails its first live test and gives your external auditor a bridge period to observe the SAP environment before it becomes the sole evidence source for a quarterly or annual assertion.
Retire Dynamics-era SoD tooling and update the control matrix
Once SAP GRC (or the equivalent SoD process) has operated successfully through a full close cycle, formally document the retirement of the prior Dynamics SoD tool and Power Platform controls, with an explicit date and rationale, and update the RCM and walkthrough narratives to reference the new SAP authorization model and transport-based change control. Auditors will specifically ask how the SAP GRC ruleset was validated against the Dynamics-era violation history — keep that reconciliation on file.
Where SOX continuity breaks
- ·Building broad PFCG roles that replicate Dynamics' coarser duty bundling instead of using SAP's finer authorization object granularity — this squanders the main control benefit of the migration and can carry forward SoD risk unnecessarily.
- ·Deferring the SAP GRC ruleset build until after go-live because "we'll tune it once we see real usage" — this leaves the first close cycle running without validated SoD enforcement, which is exactly the period auditors scrutinize hardest.
- ·Underestimating the transport landscape setup timeline — teams that treat STMS configuration as a technical afterthought often go live without an enforced approval gate on production imports, creating a change-control gap from day one.
- ·Assuming SAML SSO integration with Entra ID automatically preserves conditional access policy enforcement inside SAP — SAP's authentication layer and Entra's conditional access policies need to be explicitly tested together, not assumed compatible.
- ·Losing institutional knowledge of Dynamics-era SoD violations that were previously mitigated with compensating controls — if that mitigation history isn't carried into the SAP GRC ruleset design, the same conflicts can resurface unmitigated.
After the cutover
Schedule a 90-day post-cutover review of the transport approval log specifically, since early-stage SAP environments often see configuration changes rushed through without full approval documentation while teams are still learning the transport process.
Common questions
No. SAP GRC Access Control requires a ruleset built against SAP's authorization object model, which has no structural equivalent in most Dynamics SoD tools. The conflict logic has to be rebuilt from business-function definitions, not migrated as configuration.
Book an assessment
Get migration-specific SOX control continuity guidance for Microsoft to SAP.
Book an Assessment →