The first sign that ERP and ecommerce are too tightly coupled is rarely a technical error. It is a queue of held orders, a customer being promised the impossible, or a support team spending the morning explaining why stock was “available” in one system and not in another.
The key question is not whether systems can be integrated, but what part of the business must keep working when the integration fails.
That is the core thesis: for a company selling online and operating with stock, dispatch, pricing and returns, integration is not the goal. It is a means. And like any means, it can either simplify work or turn every exception into a shared crisis.
The real symptom is dependency, not the error itself
Most ERP and ecommerce discussions start in the wrong place: connector, API, middleware, plugin. But the real operational decision appears when there is an exception: a special rate, a partial order, a stock reservation, a refund, a B2B sale with custom conditions.
That is where you see whether the company has built a rule architecture or just a cable between systems.
Signs of excessive dependency:
- a small sync issue blocks entire orders;
- sales does not know where to correct prices or discounts;
- customer service needs two screens to answer one issue;
- operations does not know which frontend changes affect back office;
- every exception ends with “we’ll fix it manually and deal with it later”.
When that happens, integration stops being an advantage and becomes operational debt.
When separation makes sense
Separation does not mean disconnecting everything. It means admitting that not all data should carry the same kind of truth. In ecommerce, the customer promise needs speed; in ERP, operational accounting needs consistency; in the warehouse, execution needs stable instructions.
Separation makes sense when:
- the catalog changes frequently and the back office should not block those updates;
- several sales channels follow different rules;
- real stock depends on locations, reservations or partial picking;
- ecommerce needs to evolve without every change going through a long ERP validation cycle;
- ERP is strong in internal operations but should not decide the full digital experience.
A common case: a distributor with an online store, phone orders and internal sales. For months it lives with a “total” integration. Everything looks fine until a campaign spikes traffic, a critical item runs out and the system tries to reserve inventory already committed elsewhere. The visible symptom is a lost sale. The deeper problem is that no team decided who owns the delivery promise when two channels compete for the same stock.
The company that handles this better is not the one that “integrates better”, but the one that clearly decides which system is the source of truth for each rule.
The uncomfortable decision: accept partial duplication
Here is the part many leaders dislike: sometimes partial or temporary duplication is worth accepting. Not because duplication is ideal, but because forcing everything into one model too early makes every commercial change depend on the slowest system.
That has a real cost:
- stricter data governance;
- more care about which attribute lives where;
- more reconciliation;
- less temptation to “just fix it later in bulk”.
But the cost of avoiding it can be worse: an operation where every exception becomes an integration incident.
The bad choice is not having two systems. The bad choice is not documenting what happens when they disagree. If the price changes in ecommerce but not in ERP, who fixes it? If stock is reserved in a campaign and a return arrives, which state wins? If an order arrives incomplete, which team unblocks it and by what rule?
Those are not technical questions. They are operational governance questions.
What to measure before deciding
Before redesigning the integration, observe the real operation for a few weeks. You do not need a giant audit. Start by identifying concrete signals:
- how many incidents come from exceptions, not from major failures;
- how long a held order takes to return to normal flow;
- which commercial changes force ERP changes;
- how many manual corrections happen and how often they repeat;
- which system loses credibility when a discrepancy appears.
If ecommerce has become a storefront that cannot change without ERP approval, commercial speed slows down. If ERP bends to every online channel whim, internal operations lose stability. Neither extreme is good news.
The mature decision is usually less glamorous than the original promise: separate where speed matters, integrate where consistency matters, and define explicit rules for the grey areas.
That clarity reduces friction, but it also forces accountability. For leadership, that is worth more than a beautiful but fragile integration.
At Codefuente, that is usually where we start: not with the connector, but with the rules that must survive when the system does not cooperate. If your company is debating whether to unify or separate, the useful question is not which technology looks cleaner, but which operation you need to protect when something fails.