The ERP in a replatform: four things that actually break

There is a silence in the industry around this combination. Plenty gets written about switching ecommerce platform, and plenty gets written about integrating an ERP. Almost nothing gets written about what happens when you do both at once — which is exactly what a replatform in a B2B business is.

Here is what it looks like when it breaks.

The ERP is not an integration. It is the truth.

In a pure B2C store the ERP is a recipient. The order is created in the shop and sent there. If the connection goes down for an hour, orders queue and then send.

In a B2B business the relationship is reversed. The customer’s agreed price, credit limit, discount ladder and payment terms live in the ERP, and the shop has to ask before it can display anything at all. If the connection goes down, the logged-in customer cannot see their price. The shop is not slow — it is unusable.

That difference is what makes a B2B replatform a different animal from a B2C one, and it rarely shows up in a requirements document.

Four things that actually break

The article numbers do not match. The ERP has one article identity, the old shop has another, and somewhere there is a spreadsheet translating between them. That spreadsheet is usually undocumented and often incomplete.

The pricing logic lives in two places. The base price comes from the ERP, but the discount was built into the shop because that was quicker at the time. After the switch that logic has to live in one place, and somebody has to decide which.

Stock levels are cached and nobody remembers how often. It worked as long as the same people looked after it. After a switch, every assumption about refresh frequency becomes visible, in the form of overselling.

The customer number is the bridge between two worlds. A logged-in B2B customer is an account in the shop and a customer in the ERP, and they have to line up with no gaps. It is the one mapping that absolutely cannot go wrong, because going wrong means somebody sees somebody else’s prices.

What makes it manageable

The order of operations. The integration should be verified before the data migration, not after.

The usual instinct is the opposite: move the products first, because that feels like the foundation, and connect the ERP last because it is hardest. That means migrating 12,000 articles against an article identity you have not yet confirmed. If the error surfaces afterwards, all of it has to be done again.

Do it in this order instead:

• confirm article identity between ERP and new platform, on a dozen articles
• confirm the customer-number mapping, on a dozen customers, with price lists
• decide where the pricing logic lives — one place, write it down
• then run the data migration, and run it several times

The first two steps take days and save months.

We have built connections to Business Central, Navision, Visma and Fortnox and describe how they work under integrations. If your ERP is not on the list, there is an open API to build against.