Replacing a B2B Ordering System? Five Cost Lines the License Quote Never Shows

The number on the quote is a subscription fee. It is real, it is negotiable, and in most mid-size and enterprise replacements it accounts for a minority of what the project consumes over the first eighteen months. Finance signs off on the license because the license is the thing with a number attached. Everything else arrives later, in pieces, charged to departments that never saw the business case.

If you are the person who has to defend the total afterward, the work happens now, before the first demo. What follows is what to gather and measure so the conversations you have with vendors are about your situation rather than their slide deck.

The assumption: the platform replaces the platform

The common reading of a system replacement is a swap. Old thing out, new thing in, users log into a different URL on Monday. That framing survives right up until someone asks which system owns the customer-specific price.

In a larger organization, an ordering system is rarely a single application. It is a settlement point between the ERP, the product information source, the CRM, a tax engine, one or more warehouse systems, a punchout arrangement with three national accounts, and a set of spreadsheets that a regional sales manager has maintained for nine years. The platform is the visible surface. The cost sits in the connections underneath it, and in the fact that nobody has a current, agreed map of them.

So the first thing to produce is that map. Not an architecture diagram from the last project. A list of every system that reads from or writes to the current ordering platform, who owns each one, what the interface is (API, nightly file, someone exporting a CSV), and how often it breaks. Two weeks of interviews will get you most of it. Do it before you shortlist, because it changes which vendors are plausible.

Where the money actually goes

Across replacements of this size, the spend outside the license clusters in five places:

• Data remediation. Product records, customer hierarchies, price lists, contract terms. Nobody discovers the true state of this data until it has to move. Duplicate customer records that were harmless in the old system become two different contract prices in the new one.
• Integration build and test. Usually the largest single line. Each connection needs building, then testing against real edge cases: partial shipments, credits, returns against an order placed in the old system.
• Pricing and entitlement logic. The rules governing who sees what and pays what are often encoded in the old platform, in the ERP, and in a person's head, inconsistently. Reconciling them is a business decision project wearing a technical costume.
• Parallel running. Two systems live, two sets of reconciliations, for a period that is almost always longer than planned.
• Internal hours. Product managers, sales ops, customer service leads, finance. Rarely budgeted, always spent, and drawn from people who still have their day jobs.

You do not need vendor pricing to size most of these. You need counts. How many active SKUs, how many with customer-specific pricing, how many customer accounts with a hierarchy more than two levels deep, how many integrations, how many orders a month arrive by a channel other than the web (phone, email, EDI, a rep's tablet). Those counts drive every estimate you will be given, and if you do not bring them, the vendor will assume something convenient.

The lens that changes the math at scale

Larger organizations pay for a category smaller ones do not: coordination. Every additional business unit, region, or brand adds a stakeholder with veto power over a data model decision. Every additional country adds tax treatment, language, and a set of terms someone negotiated separately.

This is why enterprise selection processes reward specificity. When you evaluate a b2b ecommerce platform against a distributed sales organization, the question is not whether it supports customer-specific pricing but whether it supports yours: the volume tiers, the rebate structures, the rep-placed order that has to inherit the right contract, the account that buys through three purchasing entities and expects one statement.

Bring those cases in writing to the demo. Ask each vendor to configure two of them live. The gap between what is supported and what is supported without professional services is where the second invoice lives.

What to fix before you buy, not after

Some costs are cheaper to absorb on the current system. Customer master cleanup is one. Retiring price lists nobody has used since 2019 is another. So is documenting the rules that only exist as tribal knowledge, which is free apart from calendar time and which reduces the scope of everything downstream.

Security and access review belongs in this window too. The National Institute of Standards and Technology is responsible for the cybersecurity and data standards frameworks that enterprise procurement teams increasingly write into vendor requirements, and it is easier to establish your own access model before migration than to inherit one and audit it afterward.

Building the number you will actually defend

Present the board a total that includes license, implementation, integration, data work, internal hours at a loaded rate, parallel running, and a contingency you can name a reason for. Then present the offsetting side: order entry hours removed from customer service, error credits avoided, self-service adoption you can measure.

A total built that way survives month nine, when the integration scope grows and someone asks why. You will have already told them.

The organizations that come out of these projects well are not the ones that negotiated the sharpest license. They are the ones that walked into the first vendor meeting knowing their own counts, their own rules, and which of their problems the software was never going to solve.