Should businesses wait for SAP and Odoo to add AI, or start AI-native now?

"The big vendors will add all this eventually — why not wait?"

It is the most common objection we hear, and it is a reasonable one. Waiting is often the correct strategy in enterprise software. Incumbents have absorbed challenger features for forty years, and plenty of companies who bought the exciting thing in 2015 spent 2018 migrating off it.

So here is the honest analysis, including the cases where waiting is right.

The premise is correct: they will ship AI

Let us concede the strong version. SAP, Oracle, Microsoft and Odoo have enormous engineering capacity, vast data, and every commercial reason to move. They are already shipping copilots, anomaly detection and natural-language reporting. They will ship more, and much of it will be good.

If your question is "will my ERP have AI features in three years?" — yes. Certainly. You do not need to switch vendor for that.

But that is the wrong question.

The structural reason it will be AI on top

Here is what does not change, no matter how much they spend.

An incumbent's data model is simultaneously its moat and its handcuffs. Thousands of customers have built processes, integrations, reports, audit histories and regulatory filings on top of that schema. It is the reason switching costs are high — and the reason it cannot be made fluid.

You cannot ship "the AI now generates your data model at runtime" to an installed base whose entire value proposition is that the data model is stable and certified. It would break every integration and invalidate every audit. It is not a roadmap item. It is an anti-goal.

So the rational strategy — and it is rational, not laziness — is to add AI where it does not threaten the schema: reading, summarising, suggesting, detecting, reporting. All genuinely useful. All on top.

The gap between "AI on top" and "AI underneath" is not a feature gap that closes with R&D spend. It is an architectural commitment, and the incumbents made theirs decades ago, for good reasons, and cannot unmake it without destroying what makes them valuable.

This is the classic innovator's dilemma, and knowing the name does not help you escape it.

When waiting is genuinely right

Not a rhetorical concession — these are real:

Your ERP fits and you are not in pain. If it works, waiting costs you nothing and switching costs you plenty. The AI features arriving in your existing product will be a free upgrade. Take it. Do not let anyone talk you out of a system that works.

Your processes are standard and stable. If the vendor's model is best practice for you, its rigidity is a benefit. You have nothing to gain from a fluid schema.

You just finished an implementation. You have paid the cost and are about to collect the benefit. Abandoning now means paying twice and collecting once. Ride it out.

You are in a heavily regulated industry where certification matters. Certification tends to attach to specific, stable products. A fluid system may genuinely be harder to certify. This is a real constraint, not FUD.

You do not have anyone who can describe your processes. AI-native shifts the bottleneck from consultant availability to internal clarity. If nobody in your business can say precisely how approvals work, you will build a fast, expensive mess. Fix that first — it is worth doing regardless.

If several of those describe you: wait. Genuinely. We would rather tell you that than sell you something you will resent.

What waiting actually costs

For everyone else, three costs, in rising order of seriousness.

The obvious one: you stay in pain. Three more years of the spreadsheet, the WhatsApp approvals, the month-end scramble. Quantifiable if you bother to quantify it, and most people do not.

The subtle one: you keep paying the rigidity tax. Every change request, every "the system can't do that so we'll use a spreadsheet", every workaround that becomes permanent. This cost is invisible because it is never on an invoice — it is diffused into your team's week. It is usually much larger than the software licence.

The serious one: your processes calcify around what your software allows. This is the real damage. Over years, businesses stop asking "how should we do this?" and start asking "what will the system let us do?" You quietly stop doing the distinctive things that made you good, because the software made them expensive. By the time better software arrives, you have forgotten you ever wanted them.

The third cost never shows up in a TCO comparison, and it is the one that actually matters.

The argument that should settle it: reversibility

The wait-or-jump framing assumes a big, risky, expensive decision. That framing is a leftover from the era it describes.

If adopting AI-native meant an eighteen-month migration, waiting would be obviously correct — the option value of waiting exceeds the benefit of moving early. That is standard decision theory and it is why "wait and see" was right for so long.

But that is no longer the shape of the decision. You do not have to migrate your ledger. You do not have to bet the company. You can take one painful process — the one everyone complains about — put it in an AI-native system beside what you already run, and find out in a fortnight whether this is real.

If it works, do the next one. If it does not, you are out a fortnight and a small subscription. You have not migrated anything. Your accounting system has not moved. There is nothing to unwind.

Waiting is the right answer to expensive, irreversible decisions. This one is neither. The correct response to a cheap, reversible experiment is to run it, not to deliberate about it for three years.

If the honest answer is that you are not ready, our fit check will say so — it is built to say no. And the pricing is deliberately structured so a first workflow does not require a business case — talk to us about scoping one.

Why wait-or-jump is a false choice

Yes, the incumbents will add AI. No, it will not be AI-native, for reasons that are structural rather than temporary.

But that is not really the point. The point is that "wait or jump" is a false choice inherited from an era when jumping was expensive. Do one process. Find out. That is not a strategy decision — it is a fortnight.

Common questions

SAP and Odoo will add AI eventually, so why not just wait for them?

They will ship AI, and much of it will be good — but it will be AI on top rather than AI underneath, and that is structural rather than temporary. An incumbent's data model is simultaneously its moat and its handcuffs: thousands of customers have built processes, integrations, reports and audit histories on that schema. Making it fluid at runtime would break every integration and invalidate every audit, so it is not a roadmap item. It is an anti-goal.

When is waiting genuinely the right call?

When your ERP fits and you are not in pain, so switching costs plenty and waiting costs nothing. When your processes are standard and stable, making the vendor's rigidity a benefit. When you have just finished an implementation and are about to collect the return. When you are in a heavily regulated industry where certification attaches to specific, stable products. And when nobody in your business can yet describe your processes precisely — fix that first regardless.

What does waiting actually cost me?

Three things, in rising seriousness. You stay in pain: more years of the spreadsheet, the WhatsApp approvals, the month-end scramble. You keep paying the rigidity tax of change requests and workarounds that become permanent, a cost that never appears on an invoice because it is diffused into your team's week. And your processes calcify around what the software allows, until you stop asking how you should work and only ask what the system will let you do.

How do I test this without committing to a migration?

Take one painful process — the one everyone complains about — put it in an AI-native system beside what you already run, and find out in a fortnight whether it is real. You do not migrate the ledger, your accounting system does not move, and there is nothing to unwind if the answer is no. Waiting is the right response to expensive, irreversible decisions; a cheap, reversible experiment should simply be run.

Related: AI-native ERP vs traditional ERP for the buyer's guide, and what is an AI-native ERP for the architecture.