Every replatform has two projects running in parallel. There's the technical migration, which is complex but ultimately predictable. And there's the organizational one: keeping tens of people with competing priorities, different levels of technical fluency, and their own agendas aligned for months on end. The second project is where most replatforms actually succeed or fail.
In a previous article, we covered the structural mistakes agencies make with enterprise migrations. This piece zooms in on one of those challenges: stakeholder management. Specifically, how to keep alignment from the earliest conversations all the way through launch, and what to do when that alignment breaks down.
Replatforms Are Political Projects
Most agencies walk into a replatform expecting a clean org chart. There's a product owner on the brand side who gathers requirements, makes decisions, and serves as the single point of contact. The agency talks to that person, that person talks to everyone else, and information flows neatly in both directions.
This almost never reflects reality at enterprise scale.
In practice, the product owner can answer some questions but not others. They know the e-commerce team's priorities, but they don't fully understand how the warehouse processes returns, or why the finance team needs a specific field at checkout, or what the content team's daily workflow actually looks like. They're a generalist in an organization full of specialists, and funneling every conversation through them creates a bottleneck that slows the project down and filters out critical context.
The deeper problem is that this model treats the brand as a monolith, a single entity with a unified set of requirements. Enterprise organizations are collections of teams with their own professional goals, personal motivations, and fears about what the migration means for them:
- The CFO wants to see the cost savings that justified the project.
- The content team wants a CMS that doesn't make their job miserable.
- Marketing wants campaign flexibility without filing dev tickets.
These agendas overlap in some places and directly conflict in others, and every one of them competes for priority within a fixed budget and timeline.
Underneath the professional priorities, there are personal ones that rarely get articulated:
- An operations team might drag their feet on UAT because they're worried the new system will expose inefficiencies in their current process.
- A department head who championed the existing platform may see the migration as an implicit criticism of their original decision.
- A team that has spent years building custom workarounds for the old system's limitations may fear that their institutional knowledge becomes worthless overnight.
These fears are real, they shape behavior, and if you don't account for them, you'll find yourself dealing with resistance that seems irrational on the surface but makes perfect sense once you understand the motivation behind it.
There's also emotional attachment to existing tools and workflows. People build their daily rhythm around specific software and workflows, and they will resist changing them, regardless of whether a better option exists. Those attachments are rational: the team knows the status quo works, they've invested time in learning it, and switching carries real risk for their day-to-day productivity. Dismissing these concerns as resistance to change is a fast way to lose trust.
Mapping these dynamics, both the professional priorities and the personal motivations, is work that starts during discovery and never really stops. As you learn more about the organization, your understanding of who cares about what will evolve. New stakeholders will surface. Priorities will shift. The political map you drew in week one will look different by month three. Keeping it current is part of the job.
Understanding all of this requires something fundamentally different from the traditional agency-client relationship. There can't be gatekeeping on either side. The agency can't hide behind a project manager who shields the team from organizational complexity, and the brand can't funnel everything through a single point of contact who lacks the full picture. The project needs to be deeply embedded, with both teams working side by side, building direct relationships across departments, and developing a nuanced understanding of how the organization actually operates.
This is all very uncomfortable for agencies that prefer clean boundaries. It also happens to be the only way to account for the real complexity of enterprise organizations.
Discovery Is a Mindset, Not a Phase
There's a famous line often attributed to Eisenhower: plans are useless, but planning is everything. The same principle applies to discovery in a replatform. While initial discovery matters (we'll cover that in depth in a separate article), the real value is in establishing a discipline of continuous questioning that persists throughout the entire project.
The beginning of a project is, paradoxically, the moment when you have the least information. You're making a plan based on what stakeholders tell you they need, filtered through what they remember to mention. As the project progresses, you accumulate context that reshapes your understanding of the business.
This means the principles that guide a good discovery workshop should guide every conversation throughout the project. For every requirement that surfaces, ask why it matters and what the business impact actually is. When someone tells you a feature is critical, dig into how often the scenario occurs and what happens if it simply doesn't exist at launch. Many requirements that feel urgent in the abstract turn out to be low-frequency edge cases that can wait.
The other side of continuous discovery is proactive requirement gathering. Stakeholders have full-time jobs outside of your replatform, and getting answers takes longer than you'd expect. Waiting until you actually need a decision to ask for it is a recipe for blocked work. This is also where the embedded model pays off: when you have direct relationships across departments, you can go to the source for answers instead of waiting for information to trickle through a single point of contact.
Getting The Platform in Their Hands Early
One of the most effective stakeholder management techniques has nothing to do with meetings or frameworks. Give people access to the new platform as early as possible.
You can talk about a new platform all you want. You can run workshops, share screenshots, walk through slide decks. None of it compares to the moment an operations team member opens the new admin, performs a task that used to take fifteen minutes, and sees it happen in two clicks. That's when passive tolerance turns into active advocacy. People who were indifferent to the migration start pushing for it to launch sooner.
This is also the single best antidote to the fears and emotional attachments that surface in the opening weeks of a project. Remember the operations team worried that the new system will expose their process gaps? When they can explore the platform at their own pace, on their own terms, they start to see it as a tool they can shape rather than a threat imposed on them. The department head who felt the migration was a referendum on their original platform choice? Watching the new system handle something their old one couldn't softens that defensiveness faster than any reassurance in a meeting. Early access turns abstract anxiety into concrete, answerable questions: How does this work? Can it do this? What happens when I try that?
Early access serves three purposes at once:
- It builds genuine buy-in based on experience rather than promises.
- It functions as training in disguise: stakeholders learn the new system gradually as it takes shape, which means launch day feels like a natural transition rather than a cliff.
- It surfaces feedback when you can still act on it. A workflow issue spotted in month two is a fixable problem. The same issue spotted the week before launch is a crisis.
The same logic extends to validation. QA and UAT should happen continuously throughout the project, not in a single frantic phase before launch. Give stakeholders a staging environment and encourage them to validate work as it's completed, sprint by sprint. This keeps expectations calibrated, catches issues early, and reinforces the feedback loop that makes continuous discovery work. When stakeholders are reviewing working software regularly, they surface requirements and concerns that no amount of upfront planning would have uncovered. A massive UAT crunch at the end is where timelines go to die.
Navigating Conflicts and Trade-Offs
Conflicts during a replatform are inevitable. The question is whether you have a process for resolving them or whether each one becomes an ad hoc political negotiation.
When a decision needs to be made, involve the right people. This sounds obvious, but the common mistake is consulting only the executive who owns the budget. The person who chooses the logistics tool is often not the person who uses it fifty times a day. Gathering input from operational teams, the people who live with the consequences of decisions, prevents the kind of post-launch frustration that comes from choices made in a vacuum.
This matters even more when you consider the personal dynamics at play. A team that already fears their expertise is being devalued by the migration will read exclusion from key decisions as confirmation. Bringing them into the conversation, even when their input doesn't change the outcome, signals that their experience matters. And often, their input does change the outcome, because they know things about daily operations that nobody at the executive level has visibility into.
Use a structured approach to depersonalize the conversation. Document each option with its pros, cons, and business impact so the discussion shifts from competing opinions to a shared view of trade-offs. When you can show that one path reduces operational overhead but requires a longer integration timeline while another ships faster but adds manual work for the operations team, the conversation becomes concrete. Stakeholders can disagree about which trade-off to accept, but at least they're disagreeing about the same facts.
Once a decision is made with input from all relevant parties, apply the principle of disagree and commit. Everyone moves forward together, even those who advocated for a different approach. Relitigating settled decisions is one of the fastest ways to kill momentum.
Don't Lose Sight of the Big Picture
The further you get into a replatform, the easier it is to lose the thread. Sprints fill up, integration issues multiply, and the day-to-day mechanics of the project start to crowd out the original goals. Teams that were once aligned on outcomes start optimizing for outputs: tickets closed, features shipped, milestones hit. This is how projects arrive at launch having delivered everything on the plan and still feel like a disappointment.
The antidote is maintaining a regular cadence of communication with senior stakeholders that operates at a different altitude from your sprint reviews and status updates. Not a report on what got done last week, but an honest conversation about whether the project is still pointed in the right direction. Are the decisions being made at the ground level still consistent with the business goals that justified this migration? Are the trade-offs accumulating in ways that nobody has explicitly acknowledged? These conversations are harder to schedule and easier to skip, which is exactly why they matter.
Senior stakeholders are well-positioned for this. They're removed enough from the day-to-day to hold the original vision clearly, and senior enough to unblock things when the project drifts or gets stuck. But they can only play that role if they have an accurate picture. The instinct in a difficult moment is to manage upward carefully, softening the message to avoid alarm. Resist it. Communicating with senior stakeholders requires a different register: not sprint-level detail, but a clear, honest view of where the project stands, what the risks are, and where you might need their help.
This big-picture framing also gives you a natural framework for handling change when it comes, and it will come. Scope cuts and timeline shifts are easier to evaluate when you can hold them against the original goals rather than just the current plan. Deferring a feature is a reasonable call if it doesn't compromise day-one operations. It's a much harder call if it quietly undermines the business case that got the migration approved in the first place. Keeping that context alive throughout the project is what allows you to make those judgments clearly, and to bring stakeholders along when the answer is uncomfortable.
Your Vendors Are Stakeholders Too
There's one category of stakeholder that often gets overlooked: external vendors. Your SEO agency, your logistics provider, your payment processor, your ERP partner. Each of these has their own agenda, their own timeline, and their own level of investment in your migration's success. Managing them well can accelerate the project in surprising ways. Ignoring them can quietly derail it.
First, understand each vendor's agenda. A vendor whose contract is up for renewal around the same time as your migration has a very different motivation than one with a multi-year agreement in place. A vendor who is being replaced as part of the replatform has little incentive to invest time helping you migrate away from their system. A vendor who sees the migration as an opportunity to upsell you on additional services will be eager to help, but their recommendations may not always be aligned with your best interests. None of this makes vendors adversarial by default, but it does mean you need to approach each relationship with clear eyes about what's driving their behavior.
Second, figure out how each vendor can contribute to the project. This is where the surprising upside lives. Your logistics provider may have already migrated dozens of clients to the new platform and can handle their side of the integration with minimal guidance. Your payment processor might have a dedicated migrations team that can run testing in parallel with your own QA. Your ERP vendor might be able to take on the data mapping work for their integration, freeing up your development team to focus elsewhere. If you don't ask, you won't know. And if you treat vendors as passive participants who just need to flip a switch on launch day, you're leaving significant help on the table.
Third, build vendor dependencies into your project plan with the same rigor you apply to internal workstreams. Vendors have their own release cycles, their own resource constraints, and their own priorities. If your logistics provider needs four weeks to configure their integration and you give them two weeks' notice, that's your problem, not theirs. Map out what each vendor needs to do, when they need to do it, and what information they need from you to get started. At launch time, every actor in the system needs to do their part at the right moment, and the vendors you forgot to coordinate with are the ones most likely to cause a last-minute scramble.
Replatforms Are Won or Lost in the Messy Middle
Stakeholder management doesn't have a dramatic moment where it either works or doesn't. It plays out across hundreds of small interactions that never show up in a project plan and rarely get acknowledged.
The replatforms that land well aren't distinguished by a smarter technical approach or a more detailed requirements document. They're distinguished by the sustained, thankless work of keeping people aligned across months of competing priorities, shifting context, and accumulated tension.
That kind of work requires genuine embeddedness. Not a clean agency-client boundary with a project manager filtering the complexity out, but both teams working close enough to the organization to understand how it actually operates.
Need help keeping your stakeholders aligned through a complex migration? Let's talk.
