ERP Migration Data Governance: How to Protect P2P Controls Through an S/4HANA Cutover

ERP migration data governance is the set of named owners, documented controls, and sign-off evidence that keeps procure-to-pay protected while data moves from a legacy ERP system into S/4HANA. It matters because a cutover does not pause fraud risk — it concentrates it. For the days or weeks when vendor data sits between two systems, the automated checks your accounts payable team depends on are often switched off, bypassed, or not yet configured in the new ERP system.

That window is when fraudsters succeed. Payments fraud remains widespread, with 76% of organizations reporting attempted or actual fraud in 2025, and business email compromise still the leading vector. A shared services organization mid-cutover is an unusually attractive target: approval chains are in flux, temporary manual processes become normalized, and nobody is quite sure who owns the vendor record this week.

This guide takes a governance-led view of the cutover for shared services and GBS teams: who owns existing data, how to sequence a phased approach, how to run parallel validation across legacy and target systems, and what evidence to demand at each cutover gate. If your team is accountable for both operational continuity and risk management, Trustpair’s vendor data management platform for Global Business Services leaders is built around that overlap.

Key Takeaways

• A cutover is a control event, not just a technical one. Every automated P2P control in the legacy system needs a mapped equivalent or a documented compensating control before go-live.
• Name an enterprise data owner for vendor records and a separate process owner for P2P controls before data extraction begins. Unowned vendor master data is the most common root cause of post-cutover payment errors.
• Never migrate dirty data. Roughly 30% of vendor master files contain errors or anomalies, and migration inherits every one of them.
• Cutover gates close on evidence, not confidence: reconciliations, parity reports, and an independent control owner signature, with a rollback plan if thresholds are missed.
• Validate vendor bank details against independent sources, not legacy records. The same data you are trying to verify cannot be its own control.

Why Do P2P Controls Break During an S/4HANA Cutover?

P2P controls break because they are spread across disconnected systems, configurations, and people, while migration programs track data objects rather than control coverage. The vendor record migrates. The three-way match tolerance built on custom code does not.

With SAP ending mainstream maintenance for Business Suite 7 core applications at the end of 2027, and most enterprise resource planning migrations taking 12 to 24 months, many enterprises are compressing timelines. That is where control continuity gets traded for schedule.

The failure modes we see most often:

• Automated controls lose their trigger. A duplicate-invoice check keyed to a legacy vendor ID stops firing once identifiers are normalized.
• Approval hierarchies flatten. Workflow is rebuilt in the new system and delegation rules get simplified “for now.”
• Bank detail controls go manual. Amendments move to email and spreadsheet because neither ERP database is authoritative.
• Segregation of duties erodes. Migration teams get broad access to both environments, rarely time-boxed.
• Nobody owns exceptions. Reconciliation breaks are logged with no owner empowered to block go-live.

Teams that already run a defined global procure-to-pay operating model with a named process owner enter a cutover with a control inventory that simply needs mapping, rather than discovering it mid-programme.

How Do You Build the Business Case for ERP Data Migration?

Quantify what your current P2P pain points cost today, then price the control failure risk the migration itself introduces. Sponsors fund migrations on efficiency and cost savings arguments, then under-fund the data workstream. A control-led case corrects that before extraction starts.

• Document current pain points. Pull 12 months of data on duplicate payments, payment rejections, onboarding cycle time, manual bank verification hours, invoice exception rates, and audit findings on vendor data. These double as your pre-cutover baseline.
• Quantify control failure financially. Combine the probability of an erroneous payment reaching execution, average payment value, volume in the exposure window, and the historically low recovery rate on misdirected funds. Add audit remediation and the cost of standing up compensating controls at short notice.
• Size the data effort separately. Profile record volumes, duplicate rates, and remediation effort per category. Budget at least three pilot cycles — the first always finds mapping defects.
• Align sponsors to outcomes. Get written agreement on a data quality threshold at go-live, a control continuity commitment, a parity standard, and a rollback trigger. Sponsors who pre-approved a rollback trigger are easier to work with when a gate fails.

Who Owns Existing Data in an ERP Migration Governance Model?

Vendor records need one named enterprise data owner; P2P controls need a separate process owner. The split is deliberate — the data owner is accountable for accuracy, the process owner for whether controls actually operate. One person holding both tends to self-certify.

Role	Accountability	Typical holder
Enterprise data owner, vendor master	Accuracy, completeness, approval of all vendor record changes	Head of master data or GBS data lead
P2P process owner	Control design, operation, continuity through cutover	AP or P2P process owner
Data steward, per system	Record maintenance and defect remediation in their source system	Regional or entity steward
Control owner, per control	Attests a specific control operates in the target system	Internal controls or SOX lead
Project manager	Phase gates, evidence bundles, escalation	Programme director

In a multi-entity environment, every source system needs a named steward with explicit authority. Define in writing who can create a vendor record, who approves a bank detail change, which system is authoritative during transition, and how conflicts between business units are resolved. Publish the RACI and keep it in version control.

Make ownership measurable rather than nominal: the vendor master data governance KPIs covering accuracy, SLAs, and auditability you will run after go-live should be the same metrics you use as gate criteria during the programme.

What Are the Phases of an ERP Data Migration Process?

A phased approach runs through six stages, each with explicit entry and exit criteria. Phases that overlap without criteria are how unvalidated data reaches production.

1. Assess. Profile every source system and object. Exit: documented volumes, quality baseline, known defect categories.
2. Extract. Pull financial data and vendor records under controlled conditions. Exit: completeness validated per source, file hashes logged.
3. Cleanse. Prepare data by deduplicating, standardizing, and retiring records. Exit: agreed quality KPIs met.
4. Map. Define field-level transformations into S/4HANA structures. Exit: mapping specification signed by data and process owners.
5. Test. Run iterative pilot loads and reconcile. Exit: defect thresholds met across consecutive pilots.
6. Cutover. Execute the production load with gate sign-offs. Exit: parity confirmed, monitoring active.

Allocate dedicated capacity rather than borrowing AP analysts part-time. They deprioritize migration work the moment month-end arrives — precisely when quality slips.

How Do You Extract Data Without Disrupting Live Operations?

Use defined cut-off windows plus incremental delta runs, so live operations continue while extracted datasets stay reconcilable. A single full extract taken weeks before go-live will be stale, and stale vendor data is a control risk in itself.

• Document the exact timestamp of each extract and freeze vendor changes during the window, or route them through a logged exception queue.
• Schedule delta runs between the baseline extract and cutover so in-flight changes are not silently lost.
• Log a checksum for every extraction file. This proves to auditors that what loaded into S/4HANA is what left the legacy system, unaltered.
• Reconcile record counts and control totals per source, per object, for every run. Count-only reconciliation is insufficient for financial data.

How Do You Cleanse and Standardize Vendor Data Before Migration?

Handle data cleanup before migration, never after. Loading unclean records inherits every existing problem and adds transformation complexity on top. Around 30% of vendor master files contain errors and anomalies, so assume remediation at scale.

• Profile for duplicates. Run detection across name variants, tax identifiers, addresses, and bank accounts. Two records for one supplier with different bank details is the classic condition in which a fraudulent account hides for months.
• Standardize fields. Normalize country codes, postal formats, and tax identifier structures. Validate TIN and EIN formats for US suppliers; standardize VAT and local registration formats for cross-border suppliers.
• Normalize identifiers. Move to one format across the estate and keep a legacy-to-target crosswalk, or open purchase order reconciliation becomes manual.
• Retire obsolete records. Apply a documented policy — no transactions in 24 months and no active contract — with data owner approval. Block rather than delete to preserve performance history while removing the record from payment selection.

Cleansing data at this scale is where artificial intelligence and automated duplicate detection earn their place, because rules-based matching alone misses name and address variants. Decide tooling in parallel, not mid-programme: see our comparison of how to choose the best vendor data cleansing solution and our ERP data migration challenges and mitigation roadmap.

How Do You Map Legacy Data Into S/4HANA and Validate It?

Map every field with a documented, version-controlled transformation rule, validated on samples before any full load. Undocumented mapping is the defect category that surfaces latest and costs most.

• Produce a field-level specification covering source field, target field, data type, mandatory status, default values, and handling of unmapped legacy fields — including anything driven by custom code.
• Write each rule in business language as well as technical logic, so the process owner can validate intent rather than syntax.
• Store specifications in a repository with change history. When a pilot produces unexpected results, you need to know which version caused it.
• Pay particular attention to control-relevant fields: payment terms, payment method, bank details, blocking indicators, withholding tax codes, and approval attributes. A field that looks cosmetic can be the trigger for an automated check.

Quality assurance then runs through repeated pilot loads. Use a subset spanning entity types, currencies, countries, and supplier categories — not the first 1,000 records. Reconcile AP open items, aging buckets, open purchase orders, and vendor counts by status against legacy reports. Maintain one defect log with severity, root cause, named owner, and target date, and set acceptance thresholds in advance: zero critical defects across two consecutive pilots. Thresholds negotiated after a failed pilot are not thresholds.

Which P2P Controls Must Survive the Cutover?

Every control that prevents or detects a misdirected, duplicate, or unauthorized payment must survive, either like-for-like or as a documented compensating control. Build the inventory before the mapping phase closes.

Cover at minimum: vendor creation approval, bank detail change verification, duplicate vendor and duplicate invoice detection, three-way match tolerances, payment run approval and release, segregation of duties between vendor maintenance and payment release, payment file integrity checks, and sanctions screening.

For each control, record where it operates today, where it will operate after cutover, who owns it, whether it is automated or manual, and its status during transition. Where an automated control cannot be live at go-live, document the compensating control explicitly — what it is, who performs it, how often, what evidence it produces, and when automation will be restored. An undocumented gap is an accepted risk nobody accepted, and it will fail both internal compliance requirements and external regulatory requirements.

Risk mitigation here depends on independence. Validating bank details against the legacy record only confirms that two copies of possibly wrong data agree. Teams with a standardized vendor onboarding process across countries restore control coverage faster than those rebuilding country by country.

How Do You Run Parallel Validation and Sequence a Multi-ERP Cutover?

Run the same reports in both systems over the same period and measure parity against pre-agreed metrics, then gate cutover on those metrics. Parallel running without defined thresholds generates reassurance rather than assurance.

• Define parity numerically: vendor record count by status, AP open item total and count, aging distribution by bucket, open purchase order value and count, payment run totals by method and currency.
• Run reports concurrently, ideally daily for financial objects. Reports at different cut-offs cannot be compared, and most “parity failures” are timing artifacts.
• Use one defect log shared with the pilot phase, and escalate unresolved mismatches to the control owner, not just the technical team. A parity break is a control signal.

Most enterprises then run a hybrid estate for months. Document, by entity and process, what stays on legacy platforms and for how long — ambiguity produces duplicate vendor creation across systems. For every interface, specify direction, frequency, authoritative source, and the reconciliation that proves it worked. Stagger cutovers by sub-estate, avoiding month-end, quarter-end, and peak payment runs, and keep cross-system risk on the programme board agenda.

Multi-ERP vendor management is where headcount assumptions break, because each additional estate multiplies manual reconciliation across procurement data and supply chain processes. Teams that cope are usually those already able to scale vendor controls without adding headcount.

What Evidence Should Each Cutover Gate Require?

Each gate requires an evidence bundle, not a verbal confirmation. Gates without evidence requirements are just scheduling checkpoints.

Gate	Criteria	Required evidence
Data quality	Cleansing KPIs met; zero critical duplicates	Profiling report, duplicate resolution log, data owner sign-off
Mapping	All fields mapped and business-validated	Signed specification, sample validation results
Pilot	Thresholds met in two consecutive loads	Reconciliation reports, defect log extract
Parity	Parity metrics met across the parallel window	Side-by-side parity reports, exception register
Control	All P2P controls mapped or compensated	Control inventory with per-control attestations
Go-live	All prior gates closed; rollback tested	Consolidated evidence bundle, executive sign-off

Treat every reconciliation as a permanent artifact — timestamped, preparer and reviewer named, archived. Control owners must sign their own controls and must not report into the migration programme. Define each rollback plan before the gate is attempted, including decision owner, trigger thresholds, and handling of in-flight transactions.

What Are the Most Common ERP Migration Mistakes?

Mistake	Consequence	Countermeasure
Under-resourced cleansing	Dirty data migrates; defects surface post go-live	Ring-fenced capacity with its own budget line
Undocumented data ownership	Nobody can approve or block changes	Published RACI with named individuals, not teams
Pilots skipped to save time	Mapping defects found in production	Two consecutive passing pilots before go-live
Mappings assumed, not validated	Control-relevant fields silently wrong	Mandatory business sign-off on samples
Controls lapse during cutover	Open window for fraud and duplicate payments	Control inventory with compensating controls
Bank details checked against legacy	Fraudulent accounts carried forward	Independent verification against banking sources

How Do You Manage Change and Resource the Programme?

Change management determines whether controls survive in practice, because continuity depends on people following new processes under pressure.

• Map impacted groups: AP, procurement, treasury, internal controls, IT, regional finance, and major suppliers each have different exposure.
• Run P2P workshops before mapping is frozen, so your internal team surfaces edge cases while changes are cheap. Workshops after mapping are briefings.
• Deliver user training on the new processes, not just new screens — particularly bank detail change procedures, which are where fraud enters.
• Publish weekly status updates covering gate status, parity metrics, and open critical defects, with a named executive escalation path.

On resourcing: appoint a programme data owner with regional deputies, name cross functional leads from each affected business unit, and appoint a control owner per control. Where capacity is short, an independent consultant or contract workers can carry cleansing and reconciliation effort, but control ownership and sign-off must stay with permanent staff. Evaluate Trustpair for automated vendor bank account validation across 190 countries with continuous monitoring and native ERP connectivity — the capability that matters through a cutover is validation against external banking sources rather than the records you are migrating, with a full audit trail per assessment. Alongside it, standardize reconciliation templates and logging conventions up front so gate evidence is comparable across waves.

Quick ERP Migration Checklist for P2P Controls

Work through this in the final two weeks. Every item closes with evidence.

1. Confirm vendor ownership assignments are published and acknowledged.
2. Validate vendor bank details against independent evidence, prioritizing high-value and recently changed accounts.
3. Reconcile open purchase orders across systems, by value and count.
4. Validate AP aging parity across all buckets, not just the total.
5. Confirm every P2P control is mapped or formally compensated.
6. Secure documented sign-off per gate from an independent control owner.
7. Verify the rollback plan is tested and the decision owner is available.
8. Enable 30 days of enhanced performance monitoring covering bank detail changes, new vendor creation, duplicate payment alerts, and payment rejections.

Standardize five reconciliation templates to support this: vendor master counts by status and entity; AP open items by entity and currency with aging breakdown; open purchase orders by entity and category; payment run totals by method, currency, and bank account for the first three runs; and a bank detail validation register capturing vendor, account, source, date, result, and validator.