Microsoft Dynamics 365 to SAP S/4HANA Migration — GDPR Compliance Guide

A platform migration is not a neutral event under GDPR. Moving personal data from Microsoft Dynamics 365 to SAP S/4HANA constitutes a change in data processor (or processing arrangement), triggers an update to the ROPA, may constitute a cross-border transfer if the two systems operate in different jurisdictions, and creates a window during which personal data exists in both systems simultaneously.

This guide covers the GDPR-specific obligations that arise during this migration, in the sequence they must be addressed.

Platform profiles

	Microsoft Dynamics 365 (source)	SAP S/4HANA (target)
Vendor	Microsoft Corporation	SAP SE
Deployment	Cloud (SaaS)	Cloud (RISE), On-premise, Hybrid
Budget range	$80,000–$1,500,000	$500,000–$5,000,000
Implementation	4–18 months	12–36 months
Native GDPR module	✓ Yes	✓ Yes
Compliance modules	SOX, HIPAA, GDPR, ASC 606	SOX, HIPAA, GDPR, ASC 606
Integration approach	Azure Integration Services; Power Automate; 300+ pre-built connectors	SAP Integration Suite (iFlow); pre-built connectors for Salesforce/Workday; REST/OData APIs

Sources: https://dynamics.microsoft.com/en-us/erp/ · https://www.sap.com/products/erp/s4hana.html

The GDPR compliance gap this migration creates

Both Microsoft Dynamics 365 and SAP S/4HANA include native GDPR modules, so the compliance gap is structural rather than functional: during the migration window, personal data exists in both systems simultaneously. The ROPA must reflect this dual-processing arrangement, and consent must be valid for processing in both systems until the old system is decommissioned.

Why teams migrate from Microsoft Dynamics 365 to SAP S/4HANA

The common drivers — not all apply in every case:

• Cost: Microsoft Dynamics 365 budget range is $80,000–$1,500,000; SAP S/4HANA is $500,000–$5,000,000. The target platform carries higher typical costs; the migration is driven by capability requirements rather than cost reduction.
• Capability: Deep manufacturing and supply chain; mature compliance tooling; global multi-entity support
• Deployment model: Moving from Cloud (SaaS) to Cloud (RISE), On-premise, Hybrid.
• Vendor consolidation: Reducing the number of platforms in the estate simplifies the processor agreement portfolio and reduces ROPA complexity.

GDPR migration sequence

Address these steps in order. Steps out of sequence create compliance gaps that are expensive to close retroactively.

Step 1 — Pre-migration: update the ROPA

Before any personal data is transferred, update the ROPA to reflect the new processing arrangement. Add SAP S/4HANA as a processor (or update the controller entry if your organisation is the controller). Document the lawful basis for transferring data to SAP S/4HANA's infrastructure.

Step 2 — Data residency confirmation

SAP S/4HANA is deployed as: Cloud (RISE), On-premise, Hybrid. Confirm that the target tenant is configured for EU data residency before any personal data is transferred. This is not automatic — it is a provisioning choice that must be made explicit.

Step 3 — Processor agreement with SAP SE

Article 28 requires a written agreement with every processor before personal data is transferred to them. Execute the Data Processing Agreement (DPA) with SAP SE before the migration begins. Review the sub-processor list in the DPA — any sub-processor operating in a non-adequate country requires a transfer mechanism (Standard Contractual Clauses plus a Transfer Impact Assessment).

Step 4 — Consent record migration

Consent records must transfer with their full context: the original consent text, timestamp, purpose, channel, and notice version. A migration that transfers contact records without their consent history leaves the new system with contact data and no documented lawful basis. Verify that SAP S/4HANA's data model can receive consent records in the format exported from Microsoft Dynamics 365.

Step 5 — Dual-processing window management

During the migration, personal data will exist in both systems. The ROPA must reflect this. Access controls in Microsoft Dynamics 365 should be progressively restricted as data is moved to SAP S/4HANA. Define the decommission date for Microsoft Dynamics 365 at the start of the project — a source system that is never fully decommissioned creates an ongoing ROPA entry and an ongoing processor agreement obligation.

Step 6 — DSAR and erasure workflow cutover

Determine the point at which DSAR requests should be fulfilled from SAP S/4HANA rather than Microsoft Dynamics 365. During the dual-processing window, DSARs may need to query both systems. The cutover date must be documented and communicated to the team handling DSAR intake.

Step 7 — Privacy platform integration update

Both platforms have native GDPR modules — update the privacy platform's connections to point to SAP S/4HANA once the migration is complete. Do not disconnect Microsoft Dynamics 365 until SAP S/4HANA is verified as receiving consent events.

Step 8 — Post-migration: decommission and ROPA update

Once Microsoft Dynamics 365 is decommissioned and verified as containing no residual personal data, remove it from the ROPA and terminate the processor agreement with Microsoft Corporation. Retain the agreement documentation for the standard retention period (typically 6 years) in case of future audit.

The hard part

The most common GDPR failure in this migration is consent record orphaning — contact records transferred to SAP S/4HANA without their associated consent history. This happens when the data migration focuses on operational data (orders, cases, transactions) and treats consent as a field rather than a related record with its own schema.

The second most common failure is the dual-processing window extending indefinitely. Microsoft Dynamics 365 is never fully decommissioned because some process still depends on it. The ROPA entry and processor agreement remain open. The data minimisation obligation — which requires that personal data is not retained longer than necessary — is violated for every contact that exists in both systems after the migration should have been complete.