Rebuilding your buying group's management system without a big bang

Almost every buying group we talk to is running on a management tool nobody would choose today. It works — sort of. It also blocks every new idea, and the vendor is either unresponsive or gone. The question is never whether to replace it. The question is how to replace it without stopping the group's operations for a year.

Why the big bang keeps failing

The instinctive plan is to specify everything, build for eighteen months and switch over one Monday morning. It fails for three reasons that have nothing to do with technology. The specification ages faster than the build. The members never see anything until the end, so nobody corrects the misunderstandings early. And the cutover concentrates every risk — data migration, training, edge cases, the annual cycle — into a single weekend.

Buying groups have a fourth problem: the calendar is not negotiable. Supplier agreements renew on a fixed date, revenue declarations land in fixed windows, year-end rebates are computed once a year and members notice immediately if the number is wrong. A big-bang cutover that slips by two months does not slip by two months — it slips by a full annual cycle.

Sequence by process, not by module

The alternative is to cut the system along process lines and replace one complete process at a time. A process is a slice a user recognises: "declaring my quarterly revenue", "applying to join", "finding last year's agreement". A module is an internal abstraction: "the document layer", "the auth service". Users cannot validate a module. They can validate a process on the first day it goes live.

In practice the order that works most often is:

1. The read-only side first — document management and search. Lowest risk, immediate perceived value, and it forces the data cleanup you need later anyway.
2. The member and supplier portal. It replaces the email round-trips that eat your permanent team's week.
3. Supplier approval workflows, timed to start one cycle before the annual renewal.
4. Revenue declarations, launched at the beginning of a declaration window, never in the middle.
5. The rebate engine last, because it is the one calculation where being wrong is expensive and public.

Run the two systems side by side on purpose

Every replacement project has a period where both systems are live. Teams treat it as an embarrassment to minimise. Treat it instead as the acceptance mechanism: for one full cycle, the new rebate engine and the old spreadsheets compute the same numbers, and you compare them line by line. Divergences are not failures — they are the moment you discover the rule nobody had written down.

Data migration is a project, not a task

Fifteen years of agreements, scanned documents, member records and historical revenue figures do not move cleanly. Duplicate suppliers, companies that changed name twice, rebate tiers that were applied by hand for one member in 2019 — all of it surfaces during migration. Budget for it explicitly, run it early on a copy, and give a named person on the group's side the authority to arbitrate. That authority matters more than any technical decision.

What to demand from whoever builds it

• A fixed price and a fixed scope per batch, not an open-ended day rate.
• A demo at the end of every sprint, on your data, in front of your permanent team.
• Formal acceptance at every milestone — signed, with a defined list of what was tested.
• The source code and the documentation, handed over. Reversibility is what stops the next vendor lock-in.
• A named project team in the contract, so you know who is actually doing the work.

How long it really takes

For a group of fifty to eighty member companies, the first process goes live in six to ten weeks, and the full replacement lands over nine to fifteen months depending on how many annual cycles you need to cross. That sounds slower than a big bang. It is not — it is the same duration with the value arriving from week eight instead of month eighteen, and with the risk spread across ten small go-lives instead of one large one.

The measure of success is unglamorous: at no point during the transition does anyone in the group have to say "we can't do that this year, we're changing systems".