Five years. Roughly $580 million. The Clorox Company’s SAP S/4HANA transformation stands out not only for scale, but for how early design, benchmarking, and execution decisions shaped outcomes well beyond go-live.
The program shows what SAP S/4HANA transformations require in practice. When Chau Banks, Clorox’s Chief Information and Digital Officer, describes the program, her language is strategic and long-term — focused on building enduring capability.
But Clorox’s approach lands differently today, as the 2027 end of mainstream maintenance for SAP ECC approaches. Timelines are compressing. Scope is narrowing. Process redesign, in some cases, is being deferred in favor of migrations that can be completed quickly.
Organizations still looking for a clear path forward cannot replicate the Clorox program. Five years and $580 million are just not applicable, or transferable, for most. What is transferable is a set of design decisions that shape how an SAP S/4HANA program performs under real conditions — from initial framing through stabilization after go-live.
The Clorox program provides a reference point for ERP leaders evaluating how transformation design and execution decisions translate into operational outcomes.
1. Frame Transformations as an Enterprise Reinvention
Before Clorox made a planning decision about deployment, Banks and the leadership team determined what the program was. The answer, enterprise reinvention rather than system migration, became the frame through which subsequent tradeoffs were interpreted. When short-term volatility arrived, that frame ensured it was not misread as program failure.
Robert Holland, Vice President and Research Director at SAPinsider, identifies this as one of the most consequential — and most commonly neglected — decisions in SAP S/4HANA programs. He is direct about what works: “Those working with boards are far more successful when making the move about modernization of the business and the impact of doing so versus not doing so.” ROI framing invites scrutiny of short-term disruption. Modernization framing provides a more durable way to interpret it.
Scrutiny often follows poorly framed performance reporting during the transition. Susan Galberaith, Vice President & Research Analyst at SAPinsider, cites research from SAPinsider’s forthcoming Finance Excellence in the Age of AI, which shows that 61% of boards and executive teams expect real-time financial reporting and analysis, while only 25% of organizations have achieved the integration required to support it.
During a migration, gaps between expectation and reality show up as timing shifts, inconsistent outputs, and reporting variance. Without a clear frame, they are interpreted as deterioration. Framing determines how the program is understood when results begin to move.
2. Plan Transformations Around Realistic Benchmarks
Clorox and accenture used process mining, stakeholder input, and industry benchmarking to build the program plan — then recalibrated those benchmarks against Clorox’s specific product breadth, manufacturing diversity, and supply chain complexity.
Johan Opperman, Managing Director at accenture, worked with the Clorox team to anchor each deployment wave in operational constraints, including seasonality cycles, product availability windows, and supply network dependencies.
Holland notes that organizations often underestimate both timeline and scope. SAPinsider research from the ERP Migration and Transformation 2026 study highlights five areas that must be built into transition plans: code remediation, security and authorizations, data cleansing, third-party integration, and internal education.
“All these factors must be built into the transition plan, which must remain flexible in case some steps take longer, for the move to be successful,” Holland said.
It’s a requirement that becomes harder to meet as the 2027 deadline approaches. Organizations compress or skip the steps that make the transition executable. But the work does not disappear. It transfers. Everything not addressed before go-live becomes a post-deployment workstream that is more expensive, more disruptive, and harder to coordinate.
3. Make Design Decisions With Adoption in Mind
Pascal Montilus, Clorox’s Chief Supply Chain Officer, entered the program expecting it to be primarily technical. He later defined it as equally dependent on frontline people and end-user adoption, based on his operational experience.
The shift in his thinking reflects how adoption works in practice. Banks describes how Clorox implemented a change network embedded across the organization, supported by two-way communication and structured training. Go-live was treated as the start of stabilization — an approach that shifts focus to sustained adoption after go-live.
Galberaith says this reflects her research: “Organizations that successfully embed new ways of working during SAP S/4HANA programs treat the transformation as an organizational capability challenge, not a technology project.”
In finance functions, often the first to experience the transition, she identifies competing priorities and change complexity as the primary barriers to adoption. The limiting factors are bandwidth, change management capacity, and whether teams can consistently execute redesigned workflows. Leaders who anchor the program on new ways of working build organizational muscle memory and sustainable data foundations.
Jehangir Khan, Research Director for Data, AI, and Automation at SAPinsider, points to where data structures complicate even well-designed adoption plans.
“Hybrid landscapes, inconsistent master data, and disconnected SAP and non-SAP applications break end-to-end process continuity.” He explains that SAP S/4HANA systems often perform as designed, but struggle to perform as expected when the digital core is modernized while surrounding data, integrations, and operational processes remain fragmented.
Khan says those gaps are most prevalent when migrations focus on technical conversion rather than operational data governance, event-driven integration, and process orchestration. Under those conditions, adoption breaks down. Users revert to workarounds because they cannot trust the data the system produces.
4. Plan Cutover as a Financial Event in Transformations
Clorox’s approach to cutover was built on a commercial insight: the moment of system transition is also a moment of financial disruption that must be planned for.
Montilus describes a pre-built inventory strategy with retail partners, a deliberate pull-forward of shipments ahead of the cutover window, and a planned acceptance of quarterly financial distortion: “In essence, as per plan, the slowdown in sales in Q1 was equivalent to the gain we saw in Q4 during the pre-build.” The distortion was an engineered outcome that management understood and explained in advance.
This dovetails with a pattern Holland has identified in his research. He says the most successful transitions involve business teams and stakeholders from the start. “While this commitment is significant, aligning with business teams enables the type of actions Clorox took to alleviate potential issues during cutover.”
When that cross-functional alignment is missing, Holland warns that IT-led migrations produce different outcomes. “Making the move to SAP S/4HANA primarily IT-driven not only runs the risk of business teams being unprepared for switchover, but may also result in business teams being unreceptive to and unengaged with new systems.”
These challenges are particularly acute in finance environments. Galberaith cites SAPinsider research that shows that many finance teams attempt to manage SAP S/4HANA consolidation alongside new close functions following investment. She says the critical controls — pre-close reconciliation checkpoints, tightly governed period-lock procedures, and clear escalation paths for exception volumes — require more advance planning and coordination than commonly anticipated.
Cutover is where commercial planning, finance controls, and organizational readiness converge. Treating it as a technical milestone, with a communications plan attached, is one of the most common sources of avoidable disruption.
5. Prioritize Real Operating Performance Over Go-Live Completion
Opperman describes how Clorox tracked stabilization across two dimensions.
On the system side: steady order flow, predictable plant and warehouse execution, and declining high-severity incidents. On the people side: users completing critical work without reverting to workarounds, faster time-to-resolution, and consistent process adherence. Both mattered. A well-functioning system that is bypassed is not stable.
Galberaith defines stabilization in finance and tax as process adherence and data trustworthiness. The clearest indicators appear in close and record-to-report workflows, where period-end execution becomes predictable and runs without manual effort.
“Upstream, however, is where the real ‘tell’ lies,” says Galberaith.
She notes that stabilization is not complete until master data and journal entry processes are consistent. In practice, those upstream activities lag. In tax, consistent chart-of-accounts mapping and reconciliation across SAP are the key indicators. When those processes produce clean outputs without exception backlogs, stabilization begins to hold.
Khan translates this into operational terms. Stability shows up as reduced spreadsheet workarounds, consistent master data, predictable interfaces and batch jobs, fewer reconciliation issues, stable process cycle times, and declining data-related tickets.
He warns that without sufficient operational and data-level monitoring, organizations remain stuck in extended hypercare. Integration and master data issues persist, governance remains weak, and business users continue to rely on project teams.
Khan says, “A successful transition from hypercare to a run-and-improve model is characterized by stable end-to-end process performance, clear data ownership, predictable integrations, and a steady decline in incidents — enabling a shift from reactive issue resolution to proactive optimization.”
With SAP customers working toward the 2027 transition timelines, these trade-offs are becoming more visible across large-scale S/4HANA programs.
The Cost of Compression Ahead of 2027
The SAP community is compressing timelines at exactly the moment evidence shows how shortcuts in framing, planning, adoption design, cutover management, and governance create compounding post-deployment costs.
While the Clorox program is not a model most organizations can follow, the design decisions it made visible are not limited to large, long-term programs. They determine whether any program produces the outcomes leadership expects.
Holland puts the cost plainly: “Not focusing on topics like removing unused customizations or re-engineering processes to meet current needs ahead of the transition leaves much work to do after deployment, and taking these steps post-deployment can be both more expensive and more time-consuming.”
The work does not disappear when a deadline is met. It transfers — from the program budget into operational overhead, and from the project team into a support backlog.
What follows depends on which decisions are protected and which are deferred. Banks offers advice that holds whether the program runs five years or 18 months: “Communicate openly with all stakeholders, remain patient and focused on the long-term vision, and ensure that operational changes are closely aligned with strategic goals.”
The advice applies regardless of program scale. It centers on coherence — what holds a program together from the beginning, and what makes the disruption worthwhile.
The Clorox program shows that SAP S/4HANA transformation requires more than system migration. Outcomes are shaped early, tested during deployment, and confirmed under real operating conditions. Go-live is just one marker in the transition. Performance across finance, supply chain, and operations determines the outcome.
What This Means for ERP Insiders
Compression reshapes where risk lives. Shorter timelines do not reduce transformation risk. They relocate it into post-go-live operations, where it becomes harder to isolate, more expensive to resolve, and more disruptive to business continuity.
Stability depends on decisions made before go-live. Post-go-live performance reflects pre-go-live choices. Organizations that delay governance, data ownership, and process discipline do not defer complexity—they embed it into daily execution.
Transformation value is determined after deployment. Go-live marks technical completion. But programs only deliver value when redesigned processes, data integrity, and user behavior align under real operating conditions, often after deployment.
SAPinsider first published this article on April 16, 2026.
