Why Rip-and-Replace Is the Wrong Question in the AI Era
“Should we rip and replace SAP?” was a defensible question in 2015. In 2026 it is a category error. The right question assumes the underlying system is no longer the bottleneck — and asks where Agents need to operate instead.
I have lost count of how many CIO conversations have started with some version of “our SAP is on its last legs and we need to rip and replace.” The question is so well-rehearsed that the answer is usually already half-formed before the conversation begins. The board has been told the SAP estate is end-of-life. The CFO has been shown a five-year migration cost. The transformation partner has a methodology and a deck. The momentum is towards a multi-year programme that will replace the underlying system.
And then I ask: “What problem are you actually trying to solve?”
The honest answer, almost every time, is some variant of: cycle times are too long, error rates are too high, the operations team is constantly fire-fighting, leadership cannot get a real-time view of cash, the close takes too long, and the auditors are unhappy. The SAP system, as it happens, is not particularly involved in any of these problems. It is doing what SAP has always done. The problems are in the layer above it — the people, the spreadsheets, the email, the manual reconciliations, the swivel-chair work that holds the operations together.
None of those problems are solved by replacing the SAP. They are solved by deploying agents to do the work that humans currently do above SAP. And once you see that, “should we rip and replace SAP?” becomes a question that does not actually correspond to anything you need to decide.
The history of rip-and-replace
It is worth tracing how the question became so dominant. Rip-and-replace was a defensible strategy in the era when ERP itself was the bottleneck. From roughly 2005 to 2015, an organisation running a 1990s-era custom ERP, a green-screen mainframe application, or a heavily customised legacy SAP installation genuinely could not do the operations work the business needed. The system itself blocked the work.
The remedy was to replace the system. The new ERP delivered better data integrity, better reporting, better integration, and a recruitable technology stack. The migration cost was justified because the alternative was operational paralysis. Generations of consultants built methodologies around this argument. SAP, Oracle, Salesforce, Microsoft Dynamics, NetSuite, Workday all sold themselves as the natural rip-and-replace target for the previous generation.
That argument worked while the underlying system was the bottleneck. It does not work now.
What changed
Two things changed in the last three years and the implications have not yet fully landed in modernisation strategy.
1. The bottleneck moved
For most enterprises running a reasonably modern SAP, Oracle, or Salesforce, the underlying system is no longer where the time goes. The time goes in the operations layer above the system — the email triage, the document processing, the manual reconciliations, the exception handling, the report consolidation. Replacing the underlying system does not touch this layer. Deploying an agent workforce on top of the existing system does.
2. Agents made the operations layer addressable
Until very recently, the operations layer above the ERP was structurally human. There was no software primitive that could read an email, extract a structured booking, decide whether to confirm or escalate, and post the result back to SAP. Now there is. AI agents do exactly that, in production, today. The class of work that used to require human glue can now be delegated to agents that operate under governed authority and full audit.
Together, these two changes invalidate the rip-and-replace question. The bottleneck is in a different place than the question assumes; the remedy is a workforce, not a platform.
The category error
The reason rip-and-replace is now a category error rather than just a wrong answer is that the question presupposes a model of where value is created that no longer holds.
The question implicitly says: the bottleneck is the underlying system; therefore the remedy is to replace the underlying system; therefore the modernisation programme is a system-replacement programme. Each step in that chain was correct in 2015. None of them are correct now.
Treating “should we rip and replace?” as the modernisation question is therefore not just an answer in the wrong direction. It is an answer to a question the enterprise no longer needs to ask. Resources spent answering it are subtracted from the resources available for the question that actually matters.
The right question
The right question, in 2026, is structurally different. It assumes that the underlying system is no longer the primary bottleneck (in most cases), and it asks where the workforce gap actually is.
That question has different sub-questions and different answers than rip-and-replace. The sub-questions are: which workflows have measurable cycle times that agents could compress? Which decisions are currently made by humans that could be delegated to agents under governed authority? Where is the integration tax highest, and would a non-invasive agent layer remove it? The answers come from the operations team, the finance team, and the line-of-business leaders — not from the IT roadmap.
What modernisation without migration looks like
Most enterprises today should be running a modernisation-without-migration programme as their primary modernisation activity. The shape of the programme is consistent across cases.
Step 1: Map the operations layer
List the workflows that consume meaningful human effort above the existing ERP. Enquiry-to-Cash. Procure-to-Pay. Order-to-Fulfilment. Month-end close. Compliance reporting. Customer service triage. For each one, capture the current cycle time, error rate, and headcount. This is the inventory of the workforce gap.
Step 2: Identify the integration surface
For each workflow, identify which systems the agents will need to read from and write to. SAP. Salesforce. Snowflake. The document repository. The email channel. iHub connectors handle the integration; AI-driven schema-drift healing keeps them stable. The integration surface is the deployment plan.
Step 3: Deploy one agent on one workflow
Pick the workflow with the highest ROI and the cleanest substrate. Deploy a single agent against it. Measure cycle time, error rate, and headcount before and after. The first agent in production is the proof point that the rest of the programme is built around.
Step 4: Expand the workforce
Once the first agent is in production, expand to the next workflow, and the next. Each agent is a configuration exercise, not a code project. The integration surface is reusable. The Decision Trace primitives, the Service Roles, the Pairing Rules — all are platform-level capabilities that scale across the workforce.
Note what is not in this programme. There is no migration of the underlying ERP. There is no retraining of the workforce on a new system. There is no five-year capex programme with deferred ROI. The existing system stays. The new workforce arrives. Modernisation happens in the operations layer where the bottleneck actually is.
When rip-and-replace is still right
There are still cases where rip-and-replace is the right answer. They are narrower than most modernisation business cases assume.
- The underlying system is genuinely end-of-life. Vendor support has ended. Security patches are no longer issued. The platform cannot run on supported infrastructure. This is a small fraction of the cases that present as rip-and-replace candidates.
- The underlying system was never appropriate. An enterprise has a homegrown application from twenty years ago that was never built to be a System of Record. The data integrity is poor. The audit trail does not exist. There is no path forward for the system itself. This is the Path A case from the previous post in this series.
- The vertical never had a modern operating system. Freight is the canonical example. There was no industry-standard ERP for the freight forwarding vertical. Generating one and deploying agents on top was the right move. This is also Path A.
- A regulator or compliance regime has mandated replacement. Some industries have specific obligations that the legacy system structurally cannot meet. This is a small number of cases and the constraint is external.
Implications for the modernisation budget
The financial implication of asking the right question is significant. A traditional rip-and-replace ERP migration is, in capex terms, the largest non-physical investment most enterprises make. Modernisation-without-migration is a fraction of that, in opex rather than capex, with measurable ROI in quarters rather than years.
This is not a marginal cost difference. It is a structural one. CFOs who have run rip-and-replace programmes are visibly cautious about funding the next one. CFOs who have run modernisation-without-migration are visibly evangelising it internally. The CFO conversation shifts from “what will the migration cost?” to “what is the unit economics of agent-driven work, and how fast does it pay back?”
That is the conversation the rest of this series will return to. Post 9 (the CFO Case) walks the unit economics in detail. Post 10 (Governance) walks how boards and regulators should read the new approach.
Closing
The phrase “rip and replace” comes from a real history. It served a real purpose for a real period of time. That period is over.
The question CIOs should be asking in 2026 is not “should we rip and replace?” It is “where do agents need to operate, and what is the fastest, lowest-risk way to give them a system to act on?” The first question buys a five-year programme that may or may not produce operational improvements. The second buys an agent workforce in production within a quarter, on the system you already have.
The remaining seven posts in this series make the case operationally. The next post walks Path B in the SAP context — what non-invasive layering looks like architecturally and what the first 90 days of deployment include. If you are running an SAP estate and reading this, that is the post that translates this argument into your specific reality.
Stop asking the wrong question. Start the right programme.
VoltusWave is the AI Agent Workforce Platform. Modernisation without migration: layer Agents on your existing SAP, Oracle, or Salesforce non-invasively via iHub. Production agents live across freight, logistics, and enterprise operations. First agent in production within weeks.