Rebuilding the Platform 50,000 Businesses Order Through

Situation. A B2B commerce platform carrying $4B+ in annual orders across 50,000 dealer accounts was not failing. But the cost of making it do something new kept getting higher, until the conversation changed from how to make the current platform do more to whether it was still the right platform.

Direction. The organization moved toward a platform refresh after years of incremental work and conversations across the business. The new platform is being delivered in phases, while the eventual transition will move all users at the same time.

Scope. I translated stakeholder conversations into the RFP requirements, evaluated four enterprise system integrators, sat on the council that selected the implementation partner, and own the product program going forward.

What changed. Years of incremental platform work became a defined product direction, a selected implementation partner, and an active product program. The replatform is in progress.

The situation

I’ve been working on this platform for years.

For most of that time, the job was pretty straightforward: keep it running, improve it, fix what needed fixing, and keep finding ways to make it work for the business.

And it worked.

The platform supports $4B+ in annual B2B orders across 50,000 dealer accounts. It wasn’t failing. Orders were going through. Dealers were using it. The business was operating.

But over time, the cost of making the platform do something new kept getting higher.

Some changes required workarounds. Some business rules had to be handled in multiple places. Data and content weren’t always as easy to govern as they should have been. Things that looked simple from the outside could become complicated once they ran into the realities of the existing platform.

Those problems weren’t new. They had accumulated over years.

Eventually, the conversation changed from “How do we make the current platform do this?” to “Is this still the right platform for where the business is going?”

That conversation didn’t happen in one meeting or because of one metric.

It came from a lot of conversations across the business.

Defining what comes next

By the time the platform refresh came to me, there was already broad agreement that we needed to look at what came next.

What we didn’t have yet was a clear definition of what “next” actually meant.

Different stakeholders had different priorities. Sales had one set of concerns. Customer service had another. The business had capabilities it wanted to add. Technology had constraints to consider. And I had years of experience with the platform itself.

My job was to take all of that information and turn it into something we could actually use.

I met with stakeholders across the business, worked through the requirements, challenged some of the assumptions, and translated the conversations into the requirements for the RFP.

That distinction matters.

The RFP wasn’t a list of everything everyone wanted.

It was an attempt to define what the business actually needed from the next platform and give potential partners enough context to tell us how they would get us there.

We had to separate the things the business genuinely needed from the things that were simply limitations of the existing platform.

We also had to be honest about what was worth carrying forward.

A replatform is an opportunity to change things.

It is also very easy to use a replatform as an excuse to rebuild everything.

Those aren’t the same thing.

Choosing the partner

We evaluated four enterprise system integrators.

I was part of the council that evaluated the responses and ultimately selected the implementation partner.

The decision wasn’t simply whether a partner could implement the technology.

We were choosing a partner for a live B2B commerce platform with 50,000 dealer accounts, years of accumulated business rules, established integrations, internal teams, and a business that still had to operate while the replacement was being built.

That context mattered.

The partner needed to understand both the platform we were building and the business we couldn’t stop running while we built it.

Building the new platform

The program is being delivered in phases.

That doesn’t mean dealers are being migrated in phases. All users will ultimately move to the new platform at the same time.

The phased approach is about how we build and prepare the platform before that transition.

That distinction matters because it changes what the phases are for.

Figure 1. The phases describe how the platform is built and validated before go-live, not how users arrive on it. All users transition at a single cutover.

We’re not using early dealer cohorts to test the migration. We’re using the phases to build capabilities, work through dependencies, validate the system, and get the organization ready for the eventual cutover.

It also means we have to make decisions about what belongs before go-live and what can come after it.

The configured-order workflow is one example.

It is an important capability, but it doesn’t have to hold the entire replatform behind it. I sequenced that work behind go-live rather than make it a prerequisite for the initial launch.

It isn’t being dropped.

It is being sequenced.

That is a very different thing.

What I own now

The RFP and vendor selection were important milestones, but they weren’t the end of my involvement.

I’m the product owner for the program moving forward.

That means I’m now responsible for helping turn the direction we established into the actual product.

The questions are different now.

What needs to be built before go-live? What can come after? Where should we preserve existing behavior, and where should we take the opportunity to change it? Which requirements are truly necessary, and which ones exist because that’s how the old platform happened to work?

All of those decisions have to account for the dealer experience, the business, the technology, the implementation partner, and the reality that the existing platform continues to support the business while the replacement is being built.

That’s the part of the work I’m most interested in.

The replatform is still in progress, so I’m not going to manufacture an outcome that doesn’t exist yet.

What exists today is a defined product direction, an RFP that turned that direction into something actionable, a selected implementation partner, and a product program that I now own.

That’s where the interesting part of the work starts.

What I learned from keeping the lights on

Working on an old platform for years changes how you approach a replatform.

You know where the problems are, but you also know why some of them exist.

You know which pieces are genuinely painful and which ones are just different from how you would design them today.

You also know that the business has adapted to the system.

That is why I don’t think the right approach is to treat the old platform as the problem and the new platform as the answer.

The old platform got the business here.

The job now is to build what comes next without forgetting that the existing business still has to work tomorrow.

That means being deliberate about what we change, what we carry forward, and what we leave behind.

The replatform isn’t the interesting part by itself.

The interesting part is figuring out what the business actually needs next, then turning that into a product that can support it.

Keep the orders moving.