PeopleSoft to SAP S/4HANA Migration — GDPR Compliance Guide

A platform migration is not a neutral event under GDPR. Moving personal data from PeopleSoft 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

	PeopleSoft (source)	SAP S/4HANA (target)
Vendor	Oracle Corporation	SAP SE
Deployment	On-premise, Private Cloud	Cloud (RISE), On-premise, Hybrid
Budget range	$400,000–$4,000,000	$500,000–$5,000,000
Implementation	12–36 months	12–36 months
Native GDPR module	✓ Yes	✓ Yes
Compliance modules	SOX, HIPAA, GDPR	SOX, HIPAA, GDPR, ASC 606
Integration approach	PeopleSoft Integration Broker; REST/SOAP; OIC adapters	SAP Integration Suite (iFlow); pre-built connectors for Salesforce/Workday; REST/OData APIs

Sources: https://www.oracle.com/applications/peoplesoft/ · https://www.sap.com/products/erp/s4hana.html

The GDPR compliance gap this migration creates

Both PeopleSoft 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 PeopleSoft to SAP S/4HANA

The common drivers — not all apply in every case:

• Cost: PeopleSoft budget range is $400,000–$4,000,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 On-premise, Private Cloud to Cloud (RISE), On-premise, Hybrid — a cloud modernisation, with data residency implications.
• 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 PeopleSoft.

Step 5 — Dual-processing window management

During the migration, personal data will exist in both systems. The ROPA must reflect this. Access controls in PeopleSoft should be progressively restricted as data is moved to SAP S/4HANA. Define the decommission date for PeopleSoft 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 PeopleSoft. 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 PeopleSoft until SAP S/4HANA is verified as receiving consent events.

Step 8 — Post-migration: decommission and ROPA update

Once PeopleSoft is decommissioned and verified as containing no residual personal data, remove it from the ROPA and terminate the processor agreement with Oracle 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. PeopleSoft 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.