SAP S/4HANA Migration Testing: AU Playbook

Australia has one of the highest concentrations of SAP installations per capita in the world. Mining, banking, utilities, government, and manufacturing sectors have run SAP ECC for decades — and the SAP end-of-mainstream-maintenance deadline for ECC has compressed migration timelines that were previously comfortable. Most large Australian enterprises are now in active S/4HANA migration programmes. Many are finding that the testing phase is where their project assumptions unravel.

SAP S/4HANA migrations fail for a predictable set of reasons. The technology risk is manageable with the right approach. The organisational and testing risk is where most programmes discover their critical path too late. This guide covers the complete testing framework — from ABAP custom code assessment through UAT and cutover testing — with specific attention to the integration and data quality scenarios most commonly underestimated in Australian enterprise programmes.

Why SAP S/4HANA Migrations Fail — and Why Testing Is the Root Cause

• Custom code volume underestimated — most Australian SAP ECC systems have accumulated decades of ABAP custom code. The SAP Readiness Check identifies incompatible objects, but many organisations discover the actual volume is 3–5 times higher than estimated at project initiation. Each incompatible object requires remediation and retesting.
• Integration complexity underestimated — SAP ECC in a large Australian enterprise typically integrates with 50–200 other systems: Salesforce, Workday, ELMO, Aurion (common in government payroll), state government reporting systems, mining operational platforms (Maptek, Deswik), and banking treasury systems. S/4HANA data model changes break integrations that were working in ECC.
• Data quality not tested early enough — S/4HANA has stricter data validation than ECC. Duplicate vendors, incomplete material master records, and malformed posting documents accepted by ECC will fail S/4HANA validation. Data migration testing must run in parallel with system testing, not after it.
• Performance not validated against real workloads — S/4HANA HANA in-memory database is faster for analytical queries, but transaction processing and batch job performance depend on system sizing, network architecture, and custom code volume. Organisations that skip load testing discover performance problems in production.
• UAT mobilisation too late and too narrow — business users are typically engaged at UAT stage, months after configuration was built. At this point, configuration changes are expensive. UAT that does not cover the full breadth of business processes produces a go-live the business does not trust.

The Five Testing Phases of a SAP S/4HANA Migration Programme

• Phase 1 — Readiness and Custom Code Assessment: Run the SAP Readiness Check and Custom Code Migration Worklist. Classify all ABAP objects: compatible as-is, requires remediation, can be retired, or requires functional redesign. Build the remediation backlog and testing effort estimate. This phase determines the true scope.
• Phase 2 — Unit and Component Testing: As each configuration area is built, validate through structured unit testing against the approved process design. Each process step, field mapping, and business rule should have a corresponding test case. Build the regression test suite progressively.
• Phase 3 — Integration Testing: Validate all interfaces between S/4HANA and connected systems — inbound and outbound, real-time and batch. Every integration working in ECC must be retested against S/4HANA because API structure, IDoc formats, and field mappings may have changed.
• Phase 4 — Performance and Volume Testing: Validate S/4HANA under realistic concurrent user load and batch volumes. Concurrent user load testing aligned to peak business periods, batch job performance for overnight and month-end processing, and data volume testing at 80–100% of production data volumes.
• Phase 5 — User Acceptance Testing and Cutover Testing: Business-led UAT validating that all agreed business processes work end-to-end. Followed by two to three full cutover dress rehearsals — timed to confirm the cutover can be completed within the allowed downtime window.

Integration Testing: SAP and the Australian Enterprise Technology Stack

• CRM and sales platforms — Salesforce is the dominant CRM in Australian enterprise. The SAP–Salesforce integration must be fully retested against S/4HANA's changed Business Partner model, which replaces the ECC Customer and Vendor master records
• HR and payroll systems — Workday and SuccessFactors for HR; Aurion (widely used in Australian government), Frontier Software Chris21, and Micropay for payroll. Employee master data integrations and cost centre allocations must be validated end-to-end
• Government reporting systems — Single Touch Payroll (ATO), SuperStream, state government procurement portals, and ASIC reporting interfaces all feed from SAP in many Australian organisations. Regulatory reporting interfaces must be tested against real ATO and state government test environments
• Sector-specific operational systems — mining organisations integrate SAP with fleet management (Komatsu KOMTRAX, Caterpillar Vital Remote Services) and mine planning software. Utilities connect SAP to SCADA and energy trading platforms. Each integration is customised and requires dedicated testing
• Banking and treasury platforms — multi-bank connectivity, FX dealing platforms, and treasury management systems connected to SAP Finance must be validated under S/4HANA's simplified finance data model

ABAP Custom Code Assessment and Remediation Testing

• SAP Custom Code Migration Worklist — the starting point for any ABAP remediation programme. Produces a prioritised list of all custom objects using deprecated S/4HANA tables or APIs, classified by remediation effort
• Static analysis and impact assessment — beyond SAP tooling, static code analysis identifies complex interdependencies between custom objects, Z-tables that replicate standard data, and custom reports built on ABAP SQL that queries tables S/4HANA has restructured
• Functional regression testing of remediated objects — each remediated ABAP object must be functionally tested to verify it produces the same business output as the ECC original, using production-representative data
• Performance testing of custom code on HANA — ABAP code performant on ECC Oracle or SQL Server may behave differently on HANA columnar in-memory store. Custom SQL relying on indexing patterns that do not exist in HANA may require significant refactoring

User Acceptance Testing for SAP S/4HANA: Mobilising the Business

• Process coverage mapping — before UAT begins, document every business process that relies on SAP and map each to test scenarios that will validate it. Processes not covered by a test scenario are risks accepted by the business — this must be an explicit decision, not an oversight
• Business tester training and tooling — business users need structured test cases they can execute without deep SAP knowledge and a simple defect reporting mechanism. Test management tooling purpose-built for UAT — such as QMFactory, PinnacleQM's quality governance platform implemented by KiwiQA — significantly reduces the effort required to manage large-scale business user testing
• Defect triage and resolution governance — SAP UAT produces a large volume of defects, issues, and change requests. A governance process distinguishing true defects, change requests, and training issues is essential to managing UAT velocity
• Regression testing between UAT cycles — configuration changes made to resolve UAT defects can break functionality that previously passed. A structured regression programme between UAT cycles prevents fixing Cycle 2 defects from breaking Cycle 1 scenarios