Stop ripping out the system of record.

Every six months, an ops leader at an established company gets pitched a deck that opens with some version of: your system of record is the reason you can't move fast. Replace it, the deck says. Modernize. Become AI-native. The slide that closes the meeting always has an arrow pointing from your current ERP to a logo that costs more, looks newer, and has been built by people who have never sat in your finance month-end.

We've watched this play out enough times to know how it ends. The migration is announced in Q1. The first delay slips it into next year. The second delay reframes it as “phased.” Two years in, half the operation runs on the new system, half is still on the old one, the integration that was supposed to bridge them was descoped, and the AI initiative that was the whole reason for the migration hasn't shipped a thing.

The problem isn't that the ERP is bad. The problem is that the ERP is load-bearing.

What the system of record actually does

The platform on the slide, SAP, NetSuite, Oracle, Salesforce, QuickBooks, take your pick, is rarely the asset. The asset is the fifteen years of process embedded in it: the customizations the third controller added to handle multi-entity revenue recognition, the workflow the shipping team built to handle the one client whose POs come in upside down, the regulatory accreditation that took eight months to get and references the exact data model that exists. The platform is the visible part. The system of record is the platform plus that institutional sediment.

You can buy a new platform. You cannot buy the sediment. You re-create it, if you're lucky, badly, over years. That re-creation is the line item that never makes it into the business case.

The migration math

Public benchmarks for ERP migrations are not flattering. Average duration: 18 to 36 months for a meaningful operation. Average overrun: roughly 30% on time, more on cost. Programs that don't fully complete: somewhere around half, depending on whose data you trust. These are the projects with executive sponsorship, dedicated SI partners, and a year of planning. The ones that go quietly are the ones nobody writes case studies about.

The math problem is that the value of the migration only realizes after it's done, while the cost compounds throughout. Two years of distracted ops leaders. Two years of frozen process improvement. Two years of “we'll do that on the new system.” The opportunity cost is enormous, and most of it doesn't hit any P&L line you can name.

The math problem with the layer approach, building AI on top of the system that's already there, is much smaller. Twelve to twenty-four weeks. Reversible. The system of record stays the system of record. The AI is additive, not corrective.

What “layer” actually means

In practice it means three things:

• Read from the system of record. Pull the canonical state, transactions, accounts, opportunities, inventory, whatever the entity is, through the API the platform supports. Don't maintain a parallel copy you have to reconcile. The SoR is the source of truth; the AI sees what it sees.
• Write back through approved paths. When the AI proposes a decision and a human approves it, the resulting action goes back into the SoR through the same channels a human would use, the API, the standard transaction codes, the audit trail. No back doors. No shadow tables. The platform's controls keep working.
• Stand up the intelligence outside. The model orchestration, retrieval, scoring, drafting, queueing, all that lives in the layer, not in the SoR. The platform is treated as a database with strong opinions; the layer is where the AI work happens.

Done this way, the system of record stays exactly as load-bearing as it was. Your auditors don't panic. Your existing integrations don't break. The fifteen years of sediment keep doing their job. And the AI gets to do new work on top.

Three places this is non-obvious

The case for layering is intuitive in the abstract. It gets argued against in three specific ways.

“Our ERP can't do that.” It probably can. The objection usually means “the way we've configured the ERP doesn't expose that.” That's a configuration problem, not a platform problem. We've yet to encounter an enterprise ERP that physically cannot accept structured input from an outside service, given an integration partner who knows what they're doing.

“The vendor pitched us their AI module.” The platform vendor's AI module is rarely the best AI for any specific job, it's a hedge. It will trail the open ecosystem on every dimension that matters: model selection, retrieval quality, evaluation rigor, the ability to swap models when a better one ships. Buying the platform's AI is buying a one-vendor lock-in on top of the lock-in you already have. Layering preserves your option to keep changing the model behind the layer as the ecosystem moves.

“We'll never be AI-native this way.” “AI-native” is a marketing word. The operations that actually use AI well are not the ones that re-platformed; they're the ones that put AI on the existing rails and made it earn its keep month after month. The buyers we respect are not chasing native. They're chasing throughput and accuracy on workflows that already make money.

When the answer is to rip it out anyway

We're not absolutists. There are cases where replacing the system of record is correct:

• The platform is on a vendor end-of-life path with no upgrade option.
• It's genuinely incompatible with a regulatory regime you're entering, not inconveniently, structurally.
• An M&A roll-up forces consolidation, and the political sponsorship is real.
• You're early-stage; the sediment doesn't exist yet; the migration cost is small.

In those cases, replace. Then layer AI on the new platform once it's stable. What we resist is the inverse pitch: replace so that AI becomes possible. AI is already possible. The platform isn't the constraint. The sponsorship usually is.

What we actually do

Every engagement we run starts with a stack inventory. We map what the operation runs on, what reads from what, what writes to what, where the human review surfaces are, where the regulatory boundaries sit. We don't propose to touch any of that. The intelligence we build sits on top, reads through the official channels, writes back through the official channels, and is reversible by design. If we walk away tomorrow, the operation runs the way it ran the day before we showed up.

That constraint shapes the work. It's harder, you can't hand-wave away an inconvenient field by adding a column. You have to actually understand the system you're building over. But it's also why the engagements complete. There's no version of the project that fails because the migration ran late.

The buyer's question, again

When a vendor pitches you replacement to enable AI, ask: what's the AI thing you can't do today on the platform you have? Make them be specific. Most of the time the answer is something the layer approach handles in a quarter, not the migration approach handles in two years.

The system of record is the most expensive thing in your stack to replace and the cheapest thing in your stack to build over. Build over.