SAP to Dynamics 365 Migration: SOX Compliance Guide
SAP and Dynamics 365 Finance & Operations take genuinely different approaches to SOX control enforcement, which makes this migration more than a technical cutover. SAP's authorization objects and PFCG roles give way to Dynamics 365's duty/privilege/permission/role hierarchy, and SAP's separately licensed GRC Access Control gives way to a segregation-of-duties rules engine that's native to the platform. The upside is real — Dynamics 365's SoD engine ships without an extra license — but native doesn't mean pre-configured for your risk universe, and the two platforms' change-management evidence trails work differently enough that a control relying on SAP transport logs needs a genuinely new evidence source in Dynamics 365, including Microsoft Purview for anything that touches Power Platform. This guide covers the sequence for carrying SOX control coverage across that cutover, not the general ERP data-migration steps.
Before you start
- ·Current-state SAP control matrix documented, including every ICFR-relevant control's owner, testing frequency, and evidence source
- ·SoD conflict inventory pulled from SAP GRC Access Control (or a manual matrix) and signed off by the SoD risk owner
- ·Dynamics 365 security workshop completed with Internal Audit or a control-design resource present, building the duty/privilege/role hierarchy from the target SoD matrix rather than from existing SAP role names
- ·Target-system control matrix drafted mapping each SAP control to its Dynamics 365 equivalent, explicitly flagging controls with no direct platform equivalent
- ·Decision made on Power Platform governance scope — which Power Apps and Power Automate flows will touch financially relevant Dataverse tables, and how their activity will be captured for evidence purposes
Migration steps
Freeze and export the SAP control baseline
Capture a complete snapshot of the SAP control environment before Dynamics 365 configuration starts: PFCG role assignments, the GRC Access Control rule set with open exceptions, transport logs for the trailing 12 months, and the SOX control matrix with its evidence mapping. This is the reference for reconciling the Dynamics 365 design later and the artifact that shows an auditor nothing was lost in the platform switch.
Re-map controls to Dynamics 365's duty/privilege/permission/role model
Translate SAP authorization objects into Dynamics 365 duties and privileges control by control. A SAP control built on field-level restriction — payment release limited to a single company code, for instance — needs to be reconstructed using Dynamics 365's legal-entity and role-based restrictions, which don't offer the same field-level granularity SAP's authorization objects do; some controls may need an additional manual or configured restriction to close that gap. For change management, replace the transport-log evidence source with Dynamics 365's database-level change tracking on financially relevant tables, and separately scope Microsoft Purview coverage for any Power Platform activity touching those same tables.
Build the SoD rules engine configuration from the target risk matrix, not from Microsoft's default roles
Dynamics 365's out-of-box security roles are designed for functional coverage, not SOX conflict avoidance, and they carry real duty-level overlaps if assigned as-is. Configure the native SoD rules engine using the organization's actual conflict matrix as the starting point, not the default role catalog — and do not assume the rules engine catches conflicts the day it's turned on. It only enforces what it's been configured to check.
Re-provision access role by role against the configured SoD rules engine
Run cutover provisioning through the newly built Dynamics 365 role catalog, checking every assignment against the SoD rules engine before granting access. The common failure under go-live pressure is granting users a role bundle that approximates their prior SAP access rather than one derived from the SoD-clean role design — this reintroduces the exact conflicts the redesign was meant to eliminate. Make the SoD check a hard gate in provisioning, with conflicts routed to a documented compensating-control decision.
Extend change-management evidence to Microsoft Purview before go-live
If any part of the financial process touches Power Platform — a Power App capturing approvals, a Power Automate flow writing to Dataverse — that activity sits outside Dynamics 365's native change tracking entirely. Confirm Purview is capturing administrative and Power Platform activity, including changes to environment variables, connection references, and DLP policies, before treating the change-management control as covered. This is the most commonly missed evidence source in SAP-to-Dynamics migrations.
Document compensating controls for the cutover window
Expect some controls to run below full strength immediately after go-live — the SoD rules engine typically needs at least one operating cycle of tuning, and Purview coverage of Power Platform activity needs validation that it's actually capturing what's configured. Identify affected controls, the compensating control, its owner, and the retirement criteria once the primary control is confirmed operating in production.
Run a full control test cycle in Dynamics 365 before closing the migration
Before declaring the project complete, test every ICFR-relevant control in the live environment — access review, SoD rules engine scan, change-tracking sample including Purview coverage, key reconciliations — and reconcile against the pre-migration SAP control matrix. Findings here are a project fix; the same findings surfaced by an external auditor later become a documented control deficiency.
Where SOX continuity breaks
- ·Dynamics 365 security roles assigned from Microsoft's out-of-box templates without reviewing duty-level overlap, inheriting whatever SoD conflicts the default role design contains
- ·Change-management evidence scoped to F&O's native table-level tracking only, leaving Power Platform-originated configuration changes — a real and growing SOX blind spot — outside the evidence pipeline
- ·SAP's field-level authorization granularity assumed to carry over automatically, when Dynamics 365's duty/privilege model may need an additional configured restriction to match the same control intent
- ·SoD rules engine treated as self-configuring because it's native to the platform, when it only catches conflicts it has been explicitly set up to check
- ·Compensating controls for the cutover window left running indefinitely because no one owns the criteria for retiring them once Dynamics 365 controls are confirmed effective
After the cutover
After cutover, run a parallel-testing period — typically at least one fiscal close cycle — testing key controls against both the retained SAP evidence and the new Dynamics 365 and Purview evidence trails, investigating any variance before SAP access is fully retired. The first full control-testing cycle run entirely in Dynamics 365, with Purview coverage confirmed, becomes the baseline for assessing whether control effectiveness held through the migration.
Common questions
For core SoD detection, generally yes — the rules engine is included in the platform license and doesn't require a separate GRC purchase the way SAP GRC Access Control does. Organizations still often want a dedicated audit-management tool for engagement tracking and broader compliance workflow, but that's a separate need from SoD conflict detection itself.
Book an assessment
Get migration-specific SOX control continuity guidance for SAP to Dynamics 365.
Book an Assessment →