A practical framework for one of the hardest decisions in ERP transformation.
Large ERP programs are built on a simple assumption that rarely remains true for long. The technology selected at the beginning of the project will be materially the same technology deployed at go-live.
That assumption no longer holds.
Cloud ERP platforms evolve continuously. Oracle, SAP, Workday, and other enterprise software providers publish product readiness documentation, roadmap updates, and release guidance throughout the year, regularly introducing capabilities that were not available when the business case was approved, the solution was designed, or development began.
Rather than implementing against a static product, organizations are implementing against a platform that continues to evolve throughout the life of the program. Today’s projects are no longer moving toward a fixed destination. The destination itself is changing while the organization is still building the road.
The following scenario is illustrative of situations organizations increasingly encounter during cloud ERP implementations and is not based on any single client, implementation, or program.
Consider a program nine months into implementation. Business requirements have been validated. Solution design has been approved. Development is progressing. Then the vendor publishes its next release roadmap. Among the announced capabilities is a new standard feature that performs much of what the project team has spent months designing as a custom solution.
Should leadership continue building the customization? Stop development and wait for the standard capability? Or redesign the solution, preserving only what genuinely differentiates the business?
None of these options is painless. Each optimizes a different objective, whether protecting schedule, preserving future architecture, or maximizing long-term business value, while carrying its own financial, governance, and delivery implications. This is not poor planning. It is the consequence of implementing enterprise technology in an environment where the software continues to mature throughout the life of the project.
When the Ground Shifts
The first reaction is almost always driven by momentum. Project teams have spent months designing, configuring, and developing. Executive sponsors have committed to delivery dates. Changing direction feels like failure.
It is not. It is disciplined governance.
One side of the steering committee argues for staying the course. The customization is already underway, resources are committed, and the new standard capability is not yet available. The opposing view is equally compelling. If the platform will soon deliver comparable functionality as standard, why continue investing in something that may need to be retired almost immediately after go-live?
Both positions are rational. Neither should become the decision until leadership understands the facts.
The first responsibility is not to choose a path. It is to perform an objective assessment of the new reality. Before evaluating alternatives, leadership should answer five fundamental questions.
- How much of the customization is genuinely becoming obsolete?
- What is the true cost of continuing, including future testing, documentation, and long-term support?
- What is the operational impact of changing direction on business teams, trainers, and change management leads?
- How long is the expected gap before the standard capability arrives?
- Which option creates the greatest long-term business value?
After two decades in ERP and finance transformation, with global project experience, the pattern is consistent. The organizations that navigated this moment well did not have better instincts. They had better information.
Three Paths, Three Very Different Futures
Once the assessment is complete, the decision space becomes clearer. Not easy. Clearer.
Based on McKinsey ERP cost benchmarks, most large enterprises spend between $100 million and $1 billion to migrate their ERP systems. At that level of investment, the cost of choosing the wrong path at a mid-flight inflection point is not abstract.
The Path of Least Resistance and Its Hidden Price
Continuing as designed is the most common choice. The implementation schedule remains intact, business stakeholders avoid another round of design discussions, and the organization preserves the momentum that large transformation programs work so hard to establish.
The challenge often emerges months later. Once the vendor releases the equivalent standard capability, the organization faces another transformation effort. The customization must be evaluated, retired, replaced, tested, and redeployed. Users require additional training. Support teams inherit functionality that was always intended to be temporary but has now become part of the production environment.
The Hardest Conversation in the Steering Committee Room
Stopping the customization and waiting for the standard feature is often the most difficult path. Months of effort have already been invested. Asking an executive sponsor to halt that work can feel like asking them to acknowledge failure.
It is not failure. One of the most common forces affecting large transformation programs is the sunk cost effect. Leadership becomes reluctant to change direction because of what has already been invested rather than because continuing creates the greatest future value.
The relevant question is not how much has already been spent. It is whether, knowing what is known today, the organization would still make the same investment.
When the overlap between the planned customization and the upcoming standard functionality is substantial, absorbing today’s cost may prevent years of unnecessary maintenance, testing, upgrade complexity, and technical debt. Stopping should never be viewed as abandoning work. It should be viewed as protecting the future architecture of the solution.
Get Our Free Weekly Newsletter
The Surgical Option Programs Often Miss
Between continuing and stopping lies a third alternative that is frequently overlooked.
Rather than treating the decision as all or nothing, leadership can ask a different question: what is the minimum capability required to support the business until the standard feature becomes available?
The team develops only the functionality necessary to support business operations at go-live. Everything else is deliberately deferred. When executed well, the implementation remains aligned with critical business objectives, investment in functionality with a known expiration date is limited, and future migration to the standard capability becomes significantly less disruptive because the interim solution was intentionally designed to be replaced.
Three Organizations, Three Decisions, Three Outcomes.
The following scenarios are illustrative examples based on recurring patterns observed across multiple large-scale ERP transformation programs. They are not based on any single client, implementation, or organization.
Scenario One: The Organization That Continued
The organization that continued completed the customization and went live on the original timeline. What distinguished this organization was what happened next. Before the implementation team was released, leadership approved a post-go-live roadmap to evaluate, retire, and replace the customization with the vendor’s standard capability once it matured.
Funding was identified before the project closed. Ownership was assigned while implementation knowledge was still available. The eventual transition was deliberate rather than reactive, and the cost was contained because the planning started before go-live, not after.
Scenario Two: The Organization That Stopped
The organization that stopped found that its assessment identified the upcoming standard capability addressed nearly all of the original business requirements. Leadership chose to stop.
The decision was unpopular. Several months of work were written off and the timeline moved by several weeks. From a short-term reporting perspective, it looked like a setback. From a long-term business perspective, it became one of the most valuable governance decisions made during the program.
Scenario Three: The Organization That Took the Hybrid Path
The organization that took the hybrid path challenged the project team to identify the minimum functionality required to support operations at go-live. Everything else was deliberately deferred.
When the vendor released the new functionality two update cycles later, the transition was straightforward. The interim solution had been designed to disappear. There was no debate about ownership, no disagreement over custom code, no surprise funding request.
Sponsor Industry‑Grade Research
The Decision Is the Hard Part
Although these organizations reached different conclusions, they shared one characteristic that mattered more than the decision itself. None of them reacted impulsively. Each resisted the pressure to decide quickly, paused long enough to understand what had actually changed, and committed to a direction only after the facts were clear.
Steering committees naturally feel pressure to preserve momentum. The cost of slowing down is immediately visible. The cost of making the wrong strategic decision rarely is. That imbalance can unintentionally reward speed over judgment.
This is not a challenge unique to Oracle. It is not unique to SAP. It is not unique to Workday. Continuous delivery has fundamentally changed how enterprise applications evolve. Organizations should expect these inflection points rather than treat them as unexpected exceptions.
According to Gartner, by 2027, more than 70% of recently implemented ERP initiatives are expected to fall short of their original business goals. Gartner frames the risk around technology-centric approaches that ignore stakeholder engagement and fail to align ERP initiatives with strategic business goals.
Ultimately, the quality of these decisions depends less on technology than on governance. Organizations that evaluate these inflection points through structured executive decision-making consistently preserve more long-term business value than those driven primarily by schedule pressure.
Success depends less on which decision is made than on how the decision is made. Perhaps the better question is this: if your ERP platform changed tomorrow, would your governance model know how to respond?
The steering committees that consistently answer that question well are not simply delivering ERP implementations. They are building organizations that can adapt as quickly as the technology in which they invest.
Editor’s Note: What This Means for ERP Insiders
Cloud ERP projects need release governance. Scheduled feature releases and roadmap updates can change the business case for custom development while an implementation is already underway. ERP leaders should review vendor roadmaps as part of steering committee governance, not as a separate product-management exercise.
Customizations need a mid-flight value check. When a new standard capability overlaps with work already in progress, the right question is not whether the team should protect sunk cost or preserve the timeline. Leaders need a structured delta assessment that compares functional overlap, total cost of ownership, timeline impact, user disruption, and long-term business value.
The hybrid path can protect both go-live and future architecture. Some programs will need to continue, and others should stop. But many should consider a minimum viable interim solution that supports critical operations at go-live while limiting investment in functionality already likely to be replaced.
Platform change turns governance speed into a transformation capability. Steering committees that wait too long to respond to roadmap changes can lock unnecessary complexity into the production environment. ERP teams need clear ownership, escalation paths, and decision criteria so they can adapt without letting schedule pressure make the decision for them.
