In the first few minutes of a kickoff meeting, after the introductions have been made, right as you're getting through the first few milestones of a project scope, it happens. The first objection: "That timeline looks a little tight for us." "We're going to need more people on these meetings." "These planned discovery meetings look like they will eat up too much of my team's bandwidth." These are the opening objections of the archetypes that can derail and delay your migration.

Organizational culture within a business unit, within the larger organization, and even within some departments can determine if your project will be on time and on budget more so than technical requirements and constraints. I want to walk through three archetypes I've encountered repeatedly, what they look like in practice, and how to move them forward.

The Three POCs You Actually Need

M365 tenant-to-tenant migrations typically need no more than three points of contact. The first POC needs to be a leader that knows the organization and has the authority to push people to gather information. The second POC is usually the technical lead. Maybe the head of IT, or in some technical firms, the lead software engineer who happens to lead IT as one of the many hats they wear. The third person, and this is not always the case (we've led many successful migrations with only two POCs), is usually the lead or the head of a critical department of which the other two POCs don't have much visibility. This is almost always either sales or support.

Understanding this baseline matters because the archetypes below all deviate from it in different ways.

The Consensus Seeker

The consensus seeker doesn't want to step on any toes. They want buy-in from everyone before making a decision. But by making the base too broad, or deferring too much, nothing gets done. Sometimes this consensus-seeking attitude comes from real constraints; the leader knows key people may walk if they are not considered. But the outcome for your project is the same.

In its first form, there are the three POCs you need, but the leader has little to no authority and continues to defer to others. The other two either make commitments and later change their minds or take long periods of time to make decisions. In a functional team, the leader would make a decision and that would be final, but in these environments, that does not happen. So the project keeps being delayed by indecisiveness.

In its second form, the POCs have been expanded beyond the original three. What makes this insidious is now it's hard to get schedules aligned. So when a meeting with three of the five makes a decision, the decision can be reversed when one of the two people who were out return. This again delays the migration in a never-ending cycle of decisions and reversals.

As much as you can, whether as a PM, client executive, or engineer, get client buy-in first. Let them know that you have the expertise to see the project through. When that isn't enough, involve leadership above the POC leader as early as possible. Whether that's a vertical president, a COO, or whoever sits high enough in the org chart to make decisions stick, that level of authority will usually push even the most obstinate within the organization to be cooperative.

The Lone Wolf

Lone wolves are a different type of resistant. They're usually small teams that have effectively flown under the radar in a larger organization. By being small and efficient, they have been able to escape many of the rules of corporate hierarchy. Funnily enough, whenever we've encountered this archetype, they have exclusively used Google Workspace, making these all Google Workspace to M365 migrations, which adds another layer of friction.

Their resistance manifests itself by using the size and efficiency of the team as the main constraint. "We are a small team and do not have time to meet with you for discovery." "Our workflow is highly customized and tied to Google Workspace. A migration would be highly disruptive." These are valid objections, but as a migration team hired to do a job, you must overcome them.

Whether these objections are genuine or a deflection does not change the mission. It does somewhat change the approach. As with the consensus seeker, involving leadership above the POC leader as early as possible is the best solution. But all efforts to get buy-in from the team must be made first. Even if they don't agree, they more than any other group must understand that the motivators for this migration go beyond integration and collaboration. There may be compliance, data loss prevention, liability, regulatory, and privacy concerns driving the decision at the C-suite and board level. We always look for ways to reassure the leadership and the users. For the POCs, this happens during kickoff and through discovery. For the users, this happens during the town hall. We are always looking for buy-in that isn't coercive, but as a project team, we are typically bound by a contract and cannot accept every excuse and delay.

The Skeptic

The skeptic is both the easiest and the most difficult archetype. Easy because they are typically not dead set against the migration; they just need to be shown that enough care and planning is going into this migration to minimize disruption for their team. The difficulty is that sometimes this burden of proof can be high, and while engagement is necessary for a good migration, they may take engagement to an extreme and ask a lot of questions about seemingly minor things to allay their fears.

In M365 migrations, this looks like detailed questions about mail flow, requests for dry runs (which are not possible; our migration process is all or nothing at the domain level), and wanting to take the opportunity to restructure SharePoint sites and Teams in the new tenant. That last one is actually a good thing. Skeptics who engage deeply with the migration plan often contribute real improvements to the outcome. But a project team may not be prepared for this level of engagement. If the team cannot answer questions and resolve issues in a timely manner, the skeptic is likely to quickly become frustrated.

We've made it a policy to keep our migration process standardized rather than acquiescing to every request. It's like the restaurant with too many items on the menu where everything is mediocre, versus the curated menu where everything is high quality. Keeping the process tight is what allows us to answer the skeptic's questions confidently, which is ultimately what wins them over. And in most cases, skeptics are competent. If there are no unforeseen technical blockers, those migrations end up being pretty smooth with great collaboration throughout.

Conclusion: Look for the Signs Early

Every archetype in this article is, at its core, resistant to change. You have to demonstrate to them that this change is in their best interests. Remind them of the benefits: increased collaboration, not having to switch between different tenants, being able to work more easily across business units, teams, and different departments. Be honest about disruption, but reassure them that your team has the experience needed to bring the migration to a successful conclusion.

Doing this is not only the best way to bring people to the table, but it shows leadership that you have acted in good faith when you bring them in to push the project along. If you've done the work to earn buy-in and it hasn't been enough, the escalation to leadership isn't adversarial; it's the natural next step, and leadership will see it that way because you've already demonstrated that you tried. Look for the signs of these archetypes early, plan around buy-in, and demonstrate expertise. The culture of the team across the table will determine your timeline more than any technical constraint.