SAP S/4HANA migration is now a live agenda item for most large Australian organisations running SAP ECC. SAP's mainstream maintenance deadline for ECC 6.0 has pushed IT leaders to accelerate decisions that many had quietly deferred for years. The shift is significant: S/4HANA is not simply an upgrade. It is a complete re-platforming, with a new in-memory data model, a redesigned user interface, and a cloud-first deployment philosophy that touches almost every corner of enterprise operations.
Why Australian organisations are under pressure to move
SAP's decision to end mainstream maintenance for ECC 6.0 by 2027 (with extended maintenance options carrying a price premium) has concentrated minds. For Australian enterprises, the calculus is complicated by a few local factors. Many large organisations in resources, retail, and financial services run heavily customised ECC landscapes accumulated over more than a decade of implementation work. Those customisations do not simply port across. They need to be assessed, rationalised, and in many cases rebuilt as clean-core S/4HANA extensions.
The cost and complexity of this work is frequently underestimated. Consulting partners operating in the Australian market commonly report that discovery and business process harmonisation consume a larger share of project budget than the technical migration itself. Governance around the business case also tends to slip: IT teams scope the technical lift, but the organisational change management required to shift finance, procurement, and supply chain teams onto new workflows is a separate, substantial cost that is rarely fully funded at the outset.
Greenfield, brownfield, or selective data transition
The first strategic decision is migration approach, and it shapes everything downstream. Australian SAP customers typically have three paths available:
- Greenfield: A fresh S/4HANA implementation, starting with a clean system and migrating data without carrying legacy configuration. Best for organisations willing to re-engineer processes, but the most disruptive in the short term.
- Brownfield: An in-place system conversion that carries existing configuration, data, and customisations across to S/4HANA. Faster and lower disruption, but legacy technical debt comes with it.
- Selective data transition (formerly called shell conversion): A hybrid approach that allows organisations to carry selected data and objects while re-engineering specific process areas. Increasingly popular but more complex to scope and govern.
For organisations with heavily customised landscapes, the brownfield path often looks attractive on a timeline basis but delivers a constrained outcome. Customisations that were workarounds for ECC limitations sometimes need to stay in place simply to preserve the original business logic, which undermines the clean-core principle that S/4HANA is designed around. SAP's RISE with SAP commercial model, which packages the software, infrastructure, and services as a subscription, has added another dimension to these decisions for Australian customers weighing cloud versus private cloud deployment.
Where Australian SAP projects commonly stall
Most SAP S/4HANA projects that run into serious trouble in Australia share a recognisable pattern. The discovery phase is under-resourced and the business case is built on high-level estimates rather than a detailed process inventory. Data quality issues that were tolerable in ECC become blockers in S/4HANA because the simplified data model is less forgiving. Master data governance, in particular, tends to surface problems that teams assumed were minor.
Integration complexity is the other consistent pressure point. Large Australian enterprises typically run S/4HANA alongside a portfolio of other enterprise platforms. The connections between SAP and adjacent systems, such as ServiceNow or other workflow platforms, need careful design when the SAP data model changes underneath them. Testing cycles that were sized for a simpler integration landscape frequently blow out when teams discover undocumented point-to-point connections built outside the official integration layer.
Resourcing is a persistent challenge in the Australian market specifically. Experienced SAP S/4HANA consultants, particularly those with deep functional knowledge in areas like financial accounting and materials management, are in short supply domestically. Demand from large concurrent public sector and resource sector programmes has absorbed much of the available talent pool, which drives rates up and extends lead times for skilled staff.
Cloud deployment and data residency
Australian data residency requirements add a layer of complexity that organisations in other markets do not always face. Depending on the sector, there may be regulatory or contractual obligations to keep data within Australian borders. SAP's hyperscaler hosting partnerships (AWS, Azure, and GCP all support RISE with SAP deployments) have Australian-region options, but the specific data residency commitments vary by service tier and contract structure. IT leaders should not assume that a RISE with SAP contract automatically satisfies Australian data residency obligations: the detail is in the sub-processor agreements and the data processing addenda, and those need to be reviewed against the organisation's specific requirements.
For teams navigating these questions, it is worth reading broadly about Australian data residency rules before finalising the hosting model, since Privacy Act reform and sector-specific requirements are still evolving and can affect what a compliant deployment looks like in practice.
Practical advice for teams planning a migration
A few practices tend to separate projects that land well from those that stall:
- Invest in a fit-gap analysis before committing to a path. A proper process inventory and custom code assessment, using SAP's own tooling such as the Readiness Check and the Custom Code Migration Worklist, takes time but prevents far more expensive surprises downstream.
- Separate the technical migration from the transformation agenda. Many organisations conflate the two. The migration is an IT programme; the transformation is a business programme. They need different sponsors, different governance, and different success metrics.
- Plan for data migration as a first-class workload. Data quality remediation, business partner harmonisation, and historical data archiving are not tasks to defer until the end of the project. They are often the longest-running threads.
- Lock in your integration architecture early. The move from classical ALE/IDOC integration to SAP Integration Suite and API-based connectivity needs to be designed with the new data model in mind, not retrofitted after go-live.
- Think hard about partner selection. In a tight talent market, the difference between a partner with genuine S/4HANA delivery experience in Australia and one that is learning on your project is significant. Reference checks from comparable local deployments are worth the time.
What to expect from the business case
The business case for SAP S/4HANA migration is rarely driven by a single compelling return on investment calculation. More often, it is a combination of factors: avoiding the cost and risk of extended maintenance, enabling process efficiency that is simply not possible in ECC, and positioning the organisation for AI and analytics capabilities that SAP is increasingly building into the S/4HANA core. SAP's Joule AI assistant and the broader Business AI programme are being woven into S/4HANA workflows in ways that require the underlying platform to be current.
Australian organisations comparing their options across the enterprise platform landscape should also consider how S/4HANA sits alongside other platforms in the stack. For teams running both ERP and CRM decisions in parallel, a read of the Salesforce vs Microsoft Dynamics 365 comparison is useful context for understanding how front-office and back-office platform choices interact.
The migration timeline for a large Australian enterprise typically runs between 18 months and three years from initial scoping to go-live, depending on complexity and organisational bandwidth. That is a long time for both technology and business conditions to shift. Building regular reassessment points into the programme governance is not a sign of indecision; it is a practical response to a project that will outlast several planning cycles. Teams that treat S/4HANA migration as a defined endpoint tend to struggle more than those that treat it as the beginning of a more agile, cloud-connected operating model.