The vendor question is the wrong question
A replatform conversation usually starts the same way. A new CMO or CDO joins the company. They audit the current state. They discover the brand is running on a CMS that is two major versions behind, an analytics stack that does not reconcile with the data warehouse, and three personalization tools that do not talk to each other. They reach the obvious conclusion: replatform.
The next six months get spent on vendor evaluation. Five-platform shortlist. Capability matrix. RFP. Reference calls. Final selection. Signature. Eighteen months later, the new platform is in production and the brand has a new set of problems: a slightly different version of the integration sprawl, a slightly different version of the data inconsistency, a slightly different version of the personalization fragmentation.
The vendor changed. The problems rhymed. The replatform did not fix the thing the new CMO joined to fix.
Why the same problems come back
The pattern is consistent enough across engagements to call out plainly. Most enterprise digital teams are organized by channel — email, web, mobile, paid, social — with each channel team owning its tooling, its calendar, and its KPIs. The integration sprawl, the data inconsistency, the personalization fragmentation: all three are downstream of this org structure. Each channel team makes locally rational choices that compound into a globally incoherent stack.
A replatform does not change the org structure. The same channel teams continue to own the same boundaries after the migration. They make new locally rational choices about the new platform. Eighteen months later, the new platform is fragmented in the same way the old one was, because the structural force that produced fragmentation never went away.
This is not a hypothetical pattern. Our team has watched it play out across four or five major replatform engagements that we either ran or were called in to remediate after the fact. The brands that escaped the pattern did one specific thing during the replatform: they redesigned the operating model in parallel with the platform migration. The brands that reproduced the pattern did not.
What the operating-model redesign actually involves
Redesigning the operating model alongside the replatform is not the same as restructuring the org chart. The org chart can stay roughly the same. What needs to change is how decisions get made about the new stack.
Concretely, three things have to be true on the other side of the migration. First, there has to be a team that owns the substrate — the data layer, the integration layer, the orchestration patterns — as a product rather than as a service. Second, the channel teams have to be willing to give up some of their tooling autonomy in exchange for a coherent substrate to build on. Third, the senior digital leader has to back the structural change repeatedly through at least the first 18 months, because the channel teams will try to reassert the old pattern whenever there is friction.
None of these three is technical. All three are political. Which is why replatforms that focus on the vendor decision keep failing — the technical work is the easier half of the problem, and treating it as the whole problem guarantees the harder half does not get done.
The replatform that succeeds is the one where nobody on the engagement is allowed to call it a technology project.
The questions to ask before signing the vendor contract
If your organization is heading into a replatform conversation, the questions to ask before the vendor decision are not the questions on the standard RFP. The vendor will answer "can you do X" with "yes" for almost any X. The harder questions are the ones the vendor cannot answer.
Ask: who is going to own the substrate on the other side of this migration? Not which vendor will provide it — that is the easy question. Who, by name, on your team, is going to be accountable for whether the data layer remains coherent in 18 months. If you cannot name that person today, the replatform will reproduce the old fragmentation in their absence.
Ask: which of our current channel teams are going to give up some autonomy as a condition of this work? If the answer is "none of them," the replatform is going to fail. Each channel team will continue to make locally rational choices and the new platform will become a new version of the old problem.
Ask: what does month 18 look like if this works? A good answer describes the operating cadence, the substrate ownership, the team structure. A weak answer describes the platform capabilities. If the answer is mostly about the platform, the replatform is being framed as a technology project, and the structural work that determines success is not going to happen.
None of these questions makes the vendor decision irrelevant. The vendor decision still matters. But it is the second question to answer, not the first. If your team is in the middle of a replatform conversation right now, we are happy to walk this with you.