How Do You Manage the People Side of a Martech Platform Change?

Marketing technology implementations are evaluated on go-live. Did the platform launch on time? Did data migrate correctly? Did integrations connect? These are legitimate questions, but they measure the wrong finish line. The real measure of a martech implementation is whether the people who are supposed to use the platform actually use it, use it correctly, and use it consistently six months after go-live.

That measure is almost entirely a function of how the people side of the change was managed, not how the technology was configured. A platform that is technically sound but organizationally mismanaged will be underused, worked around, or abandoned. The cost of that outcome, in rework, in lost efficiency, and in the organizational credibility of the marketing operations function, is substantial.

The failure patterns are predictable and well-documented in change management literature. Kotter's 8-step model for leading change (published in Leading Change, 1996, and maintained at kotterinc.com) identifies 'not creating a powerful enough guiding coalition' (step 2) and 'under-communicating the vision' (step 4) as the two most common early-stage failure points in organizational change programs. Both map directly to martech rollouts where platform decisions are made by a small group and communicated to end users only at training. Late communication, training that happens after configuration rather than before, no defined adoption checkpoints, and resistance that is ignored rather than diagnosed: these are the same problems in nearly every underperforming martech rollout, and they are all preventable with deliberate planning that begins at project kick-off.

The most consequential decision in martech change management is when communication starts. Teams that announce a platform change at go-live, or even at the start of user training, have already lost weeks of runway that could have been used to build familiarity, surface concerns, and align on process changes.

Communication should begin at the moment the platform decision is made, and it should be structured in layers:

• Leadership alignment first: Marketing leadership must be able to articulate why the platform is changing, what problem it solves, and what success looks like. If leadership cannot answer those questions consistently, the message that reaches end users will be inconsistent and will generate uncertainty rather than confidence. This corresponds to Kotter step 1 (creating urgency) and step 3 (developing a clear vision): both must be resolved at leadership level before any broader communication begins.
• Manager briefing second: The people who manage the end users who will use the platform need a clear picture of how their team's work will change before they are asked to communicate that change downward. Managers who are surprised by a platform change in front of their teams lose credibility at exactly the moment they need it most.
• End-user communication third, and early: End users should hear about the change from their manager, not from a calendar invite to a training session. The message should be specific about which tasks will change, which will stay the same, and what support will be available during the transition.

The Prosci ADKAR model structures this sequence as building Awareness before Desire before Knowledge (ADKAR steps 1 through 3): people need to understand why the change is happening before they can be motivated to engage with it, and they need to be motivated before training will stick. Skipping Awareness and Desire to jump straight to Knowledge, which is what late-communication rollouts do, is the structural reason training-only approaches underperform. PMI's research on change management critical success factors identifies executive sponsorship and early stakeholder engagement as the two factors most consistently associated with project success, which maps directly to the layered communication sequence above.

The single highest-leverage intervention in martech change management is involving end users in process design before the platform is configured. This is the step that most implementations skip, and it is the step whose absence explains most adoption failures.

When users are involved in designing the process the platform will support, several things happen. They develop familiarity with the logic of the tool before they are asked to use it. They surface edge cases and exceptions that the implementation team would otherwise discover at go-live. And they develop a sense of ownership over the outcome that training alone cannot create. Kotter step 5, 'empowering broad-based action,' is specifically about removing barriers that prevent people from acting on the change vision: a process design that users did not participate in is itself a barrier, because it encodes assumptions about how work happens that may not match reality.

Practical involvement does not require extensive time from end users. It requires:

• Process-mapping workshops that include representatives from each user group, not just power users or team leads.
• Review sessions where proposed workflows are walked through in plain language before they are built in the platform.
• A documented feedback mechanism so that concerns raised in workshops are visibly addressed, even if the answer is that the concern cannot be accommodated in the current phase.

The alternative, configuring the platform based on the implementation team's interpretation of requirements and then training users on the result, produces a tool that fits the implementation team's mental model of the process rather than the users' actual work. The gap between those two models is where workarounds are born. Workarounds are the most reliable indicator that process design skipped the people who do the work.

Go-live is a starting point, not a finish line. An adoption plan that ends at go-live leaves the implementation team with no mechanism to detect or respond to the adoption problems that almost always emerge in the first 90 days. The Prosci ADKAR model's final two steps, Ability (step 4) and Reinforcement (step 5), both occur post-go-live: Ability is built through practice and supported use, and Reinforcement requires active management to prevent reversion to old habits. Neither happens without a structured post-go-live plan. Kotter step 7, 'consolidating gains and producing more change,' makes the same point: early wins must be named and reinforced, or momentum stalls.

A practical adoption plan has four components:

1. A champion network: Identify two or three users in each team or region who will receive deeper training, have a direct line to the implementation team for issue escalation, and serve as the first point of contact for peers who have questions. Champions are not a substitute for good training; they are the human layer that catches the questions training did not answer.
2. Role-specific training paths: A single training session for all users is almost never appropriate. A campaign manager, a content coordinator, and a marketing analyst use the same platform differently. Training should be structured around the specific tasks each role performs, not around the platform's full feature set.
3. Defined adoption indicators: Before go-live, agree on what adoption looks like at 30, 60, and 90 days. This might include login frequency, task completion rates within the platform, or the volume of support tickets related to workarounds. The specific indicators matter less than the act of defining them: without a baseline expectation, there is no early signal that adoption is lagging.
4. A structured review at each checkpoint: At 30, 60, and 90 days, review the adoption indicators with marketing leadership. If adoption is below expectation, diagnose the root cause before assuming the platform is the problem. In most cases, the root cause is one of three things: the process was not as stable as assumed, training did not reach all user groups, or a specific team has a legitimate workflow exception that was not accommodated in the initial configuration.

Resistance to a new martech platform is information. It is almost never simply obstruction, and treating it as such is one of the most reliable ways to harden it into permanent non-adoption.

The most common sources of resistance in martech implementations are:

• Process uncertainty: Users do not understand how their specific tasks will work in the new platform. This is a communication and training gap, not a technology problem. The fix is task-level clarity, not more general training.
• Role impact anxiety: Users are concerned that the platform will change their role in ways that have not been clearly explained. This is a management and communication gap. The fix is a direct, specific conversation about what will change and what will not, led by the user's manager rather than by the implementation team.
• Legitimate workflow exceptions: A user or team has a genuine process requirement that the platform as configured does not support. This is a design gap that should be surfaced and addressed, not dismissed. Dismissing a legitimate exception produces a workaround that persists indefinitely.
• Loss of familiar tools: Users are attached to the process or tool being replaced, not because it was better, but because it was known. This is a transition-management challenge that responds to time, supported practice, and visible wins in the new platform, not to pressure or mandate.

Diagnosing resistance means asking specific questions: Which teams are not adopting? What tasks are they avoiding in the platform? What are they doing instead? The answers almost always point to one of the categories above, and each category has a specific response. Overriding resistance without diagnosis produces compliance theater: users log into the platform to satisfy a requirement and do their actual work somewhere else.

This article addresses the people and process dimensions of martech platform change management. It does not cover:

• Platform selection: The criteria for choosing a martech platform are a separate topic. This article assumes a platform decision has been made and focuses on what happens next.
• Technical implementation: Data migration, integration architecture, and configuration decisions are outside the scope of this framework.
• Organizational restructuring: When a martech change requires significant changes to team structure or reporting lines, the change-management complexity increases substantially. That scenario warrants a more extensive treatment than this article provides.
• Regulated industries: Marketing operations in sectors with specific compliance requirements for data handling, consent management, or audit trails will need to layer those requirements onto any change-management plan. This framework does not address sector-specific compliance obligations in full.

Disclosed interest: Rarovera advises marketing operations teams on people, process, and platform alignment. Change management for martech implementations is a core part of that work. If your team is preparing for a platform change and wants a structured outside perspective on the people side, that is the kind of engagement we take on.

Every martech implementation has a detailed project plan for the technology. The teams that succeed also have a detailed plan for the people. Those plans are not the same document, and they are not the same kind of work, but they need to run in parallel from kick-off to the 90-day post-go-live review.

The framework in this article draws on established change management practice: the Prosci ADKAR model's five-step sequence (Awareness, Desire, Knowledge, Ability, Reinforcement), Kotter's 8-step model for leading change, and PMI's evidence on executive sponsorship and early stakeholder engagement. None of these frameworks are new, but all three are consistently underapplied in martech rollouts, where the technology timeline dominates and the people timeline is treated as a subset of training.

Start communication early, at the moment the platform decision is made. Involve users in process design before configuration begins. Build an adoption plan with defined 30-, 60-, and 90-day checkpoints. Diagnose resistance rather than override it. These practices are the difference between a martech implementation that delivers sustained value and one that requires a costly reset six months after go-live.