Here is a situation I have seen on at least four engagements in the last three years.

A merchant is running an existing commerce platform. The platform has problems. Stability issues, integration failures, performance degradation. The merchant is also paying a partner to run discovery for the next platform. The replatform is the strategic bet. The existing platform is the thing keeping revenue flowing.

Both workstreams need the same people. The merchant’s head of engineering. The senior developer who understands the OMS integration. The operations lead who knows which promotions break the cart. These people have the institutional knowledge that discovery requires. They also have pagers that go off when the current platform throws errors.

The plan assumes both workstreams run in parallel. They do not.

What actually happens is this. Discovery gets scheduled. Workshops appear on calendars. The partner prepares questions about integration architecture, data flows, business rules, and edge cases. Then, on the morning of the workshop, the merchant’s senior developer is pulled into an incident on the current platform. The workshop gets rescheduled. It happens again the following week. And again.

Discovery is being scheduled around incident response. Discovery slips because the incidents do.

Nobody flags this as a project risk at the outset, because it does not look like a risk. It looks like a scheduling conflict. But scheduling conflicts that recur on a weekly basis are not conflicts. They are a structural pattern. The pattern says: this organization does not have enough people to run two workstreams simultaneously, and the one that keeps the lights on will always win.

This is rational behavior from the merchant. You cannot let the existing platform fail while you design its replacement. Revenue today beats architecture tomorrow. Every time a senior engineer chooses incident response over a discovery workshop, they are making the correct short-term decision.

The problem is that nobody adjusts the discovery timeline to reflect this reality. The original plan said discovery would take eight weeks. At week twelve, discovery is 60% complete. The partner is burning through their discovery budget waiting for access to the people who hold the answers. The merchant is frustrated that discovery is “taking too long.” Both sides are right, and neither side named the actual constraint.

I have seen three ways this plays out.

The first is that discovery gets compressed. The partner, running out of budget, condenses the remaining workshops into a single intense week. The merchant’s team attends, exhausted and distracted, and provides answers that are good enough but not thorough. The gaps show up in the build phase as assumptions that were wrong. Rework follows.

The second is that discovery gets extended, with a change order. This is the honest path. It is also the path that damages the relationship, because the merchant feels they are paying more for something that should have been predictable. They are right. It was predictable. Nobody predicted it.

The third, and rarest, is that the partner scopes the discovery plan from the beginning with the assumption that the merchant’s team has limited availability. This means longer elapsed time, fewer workshops per week, and asynchronous information gathering that does not depend on synchronous access to key people. It means pricing discovery for the real calendar, not the ideal one.

The third option requires the partner to say something uncomfortable during the sales cycle: “Your team is going to be busy keeping your current platform alive. That means discovery will take longer than you want it to. We are pricing for that reality.”

That sentence loses deals. It sounds like the partner is hedging. It sounds pessimistic. The merchant wants to hear that the partner can move fast. The competing proposal says eight weeks. Saying twelve sounds like a weakness.

But the partner who says twelve and delivers in twelve is in a stronger position than the partner who says eight, delivers in fourteen, and submits a change order at week ten.

The underlying issue is that most commerce replatforming plans treat discovery as an isolated workstream. It is not. Discovery runs on top of the merchant’s existing operations. When those operations are unstable, discovery inherits the instability. The plan needs to account for this, or the plan is fiction.

If you are scoping a replatform engagement and the merchant’s current platform has known stability issues, ask one question before you finalize the discovery timeline: how many hours per week can your key technical staff actually dedicate to this work, given what they are dealing with today?

The answer will be lower than anyone wants. Price for the answer, not the wish.