SAP Data Migration UAT: How to Test Migrated Data Before Go-Live

Data migration is one of the highest-risk elements of any SAP go-live. Migrated records that look correct in an isolated data quality check can still fail when the system applies business rules — a vendor master loaded without the correct payment method will cause the payment run to skip that vendor silently.

The failure mode is consistent: migration teams validate data at load time, confirm that records were inserted without errors, and sign off on migration readiness. Then on go-live day, a procurement manager runs the payment proposal and notices that forty vendors produced no payment items. The data was technically present. It was functionally broken.

Why load validation is not the same as data migration UAT

Load validation checks that records were inserted into SAP without database errors. It does not check whether those records behave correctly when SAP applies its business logic. The gap between those two outcomes is where most data migration defects live.

• —A vendor record loads successfully but is missing a payment method — the payment run skips it with no alert
• —A customer record loads with correct basic data but incorrect pricing conditions — the first live order produces the wrong price
• —An open purchase order is migrated with the correct header data but a storage location that does not exist in the target system — goods receipt posting fails
• —GL balances are carried forward with the correct amounts but incorrect cost centre attributions — period-end reporting is wrong from day one

None of these defects produce a load error. All of them produce a business failure. UAT catches them by running migrated data through the same end-to-end business process scenarios that production users will execute on go-live day.

What SAP data migration UAT needs to cover

Vendor and customer master data

Master data UAT goes beyond confirming that records exist. For vendor master data, testers should run the complete procure-to-pay cycle: raise a purchase requisition against the migrated vendor, convert to a purchase order, post a goods receipt, verify three-way match, and confirm the vendor payment item appears in the payment proposal with the correct bank details and payment method. If any step fails, the migration defect is identified before go-live rather than in the first live payment run.

For customer master data, the equivalent is the order-to-cash cycle: raise a sales order against the migrated customer, check that pricing conditions are applied correctly, ship and invoice, and confirm the open item appears in accounts receivable with the correct payment terms and due date. Pricing condition migration is a particularly common defect source — condition records that were valid in the legacy system may not map correctly to the target pricing procedure.

Open item carry-forward

Open items — purchase orders with outstanding goods receipts, sales orders with outstanding deliveries, open GL items — are among the most complex data objects to migrate because they represent in-flight business transactions rather than static master data. UAT for open item carry-forward should confirm:

• —Outstanding goods receipts can be posted against migrated purchase orders without error
• —Migrated sales orders can be delivered and invoiced through the standard order-to-cash flow
• —Open GL items appear correctly in the vendor and customer ageing reports and match the source system balances
• —Open purchase orders retain correct pricing, quantity tolerances, and delivery schedule lines
• —Partially fulfilled orders — where goods receipt or delivery has happened for some lines but not others — carry forward both the completed and outstanding quantities correctly

Finance and controlling balances

Finance balance migration is where incorrect mapping has the longest tail. A GL balance migrated to the wrong cost centre or profit centre will distort every report that includes that balance — and the error compounds as subsequent postings are made to the same cost object. UAT should validate:

• —GL balances by cost centre match the source system's trial balance at the agreed cutover date
• —Profit centre attributions are consistent with the organisational structure in the target system
• —Tax balances reconcile to the source system's tax reports — particularly important for jurisdictions with monthly VAT filing obligations
• —Intercompany balances are consistent across all entities — intercompany open items that don't net to zero create reconciliation issues from the first period close

ABAP migration program edge cases

ABAP migration programs are typically developed and tested against clean, well-structured source data. Production data is not clean. UAT should deliberately test the edge cases that appear in real extracts:

• —Special characters in name and address fields — particularly for records sourced from non-Latin character sets
• —Partial records where optional fields are blank — the program must handle missing data without defaulting to incorrect values
• —Duplicate detection for records that appear in multiple source systems with slight naming variations
• —Records that fall outside the mapping rules — orphaned entries, discontinued codes, or legacy data that has no direct equivalent in the target system
• —Volume handling — migration programs that perform correctly on a 1,000-record test extract may time out or produce locking issues on the full production extract

Testing cross-system consistency

SAP rarely operates in isolation. Employee data in S/4HANA HCM is replicated to or from SuccessFactors. Sales data feeds BW for analytics. Customer records may be synchronised with Salesforce or a peripheral CRM. Data migration UAT must confirm that records are consistent across all integrated systems after migration, not just correct within SAP.

The most common cross-system inconsistency: a record is migrated correctly into SAP, but the replication mechanism that keeps the peripheral system in sync is not triggered for historical records — only for new transactions. The result is a SAP that has migrated data the peripheral system has never seen, creating a divergence that grows with every transaction until it is corrected manually.

Cutover rehearsal: validating operational readiness

Data migration UAT validates that migrated records are correct. Cutover rehearsal validates that the migration can be executed within the go-live window and that operations can begin immediately after cutover completes.

A cutover rehearsal should be a complete timed run of the go-live sequence:

• —Legacy system freeze — confirming that the source system is correctly locked to prevent further transactions
• —Final extract and migration program execution — against production-representative volumes, timed to confirm the window is achievable
• —Interface switch-over — redirecting integration flows from legacy to SAP
• —Opening balance and open item load — the final delta migration from the legacy cutover date
• —First live transactions — purchase order, goods receipt, sales order, and GL posting executed by the relevant business users to confirm the system is operational

Organisations that skip cutover rehearsal frequently discover on go-live weekend that the migration takes longer than the allocated window, or that the first live transactions fail because the cutover sequence left the system in an inconsistent state. A rehearsal run identifies these issues when there is still time to resolve them.

“Migrated data that loaded without errors is not migrated data that works. The only way to know your migration is ready is to run it through the same business processes your users will run on go-live day.”

When to run data migration UAT in the project timeline

Data migration UAT should run in parallel with functional UAT from the start of the UAT cycle — not as a sequential workstream that begins after functional sign-off. The most common mistake is treating data migration as a technical workstream separate from UAT, with its own sign-off criteria based on load reports rather than business process execution.

The consequence is predictable: functional UAT completes on schedule using manually created test data, data migration runs late and discovers quality issues that require source system corrections and migration program rework, and the go-live date slips while the two workstreams are reconciled.

Loading migration extracts into the UAT environment at the start of the UAT cycle serves a second purpose: it forces functional testers to use migrated data rather than manually created records. A functional test that passes with manually created data and fails with migrated data has identified a data quality issue that would have reached production undetected.