Advocating for a migration your team resists

Understanding the Resistance

When a team resists a migration, the instinct is to assume they're being conservative or status-quo-biased. Sometimes that's true. More often, they're responding to real signals:

• They've seen migrations promised as "6 weeks" that took 18 months.
• They're carrying enough existing work that adding a migration feels irresponsible.
• They don't trust the underlying business case.
• They're the ones who'll own the new system, and they worry about learning curve.
• The last migration caused an outage and they're not over it.

Before you advocate, understand which of these is driving the resistance. Different root causes require different responses.

Objection Archetypes and Responses

Objection 1: "We've tried migrations before and they never finish"

This is the most common and most legitimate objection. The response isn't "this time will be different" — that's what was promised last time.

The response is scope control and incrementalism:

"You're right that we've had migrations stall before. 
 Two things that were different in those: they were scoped as big-bang 
 and had no working stopping points. I'm proposing we scope this as 
 a strangler fig — the old system keeps running, we migrate one feature 
 at a time, and if we need to pause at any point we have a stable state.
 The migration is never 'all or nothing.'"

Demonstrate that you've designed for the failure mode they've experienced.

Objection 2: "We have too much on our plate already"

This objection is really about priority, not the migration itself. The response is to make the opportunity cost explicit:

"I hear this, and I want to be direct about the cost of deferring. 
 Every quarter we stay on the current system, we spend approximately 
 [X engineer-days/sprint] working around its limitations. 
 The migration costs Y sprints upfront but saves Z sprints/quarter 
 on an ongoing basis. The break-even is [timeline]."

"We don't have time" is more persuasive when the status quo is also costing time. Quantify both.

Objection 3: "The new system isn't mature enough"

This is a real concern with legitimate answers in both directions. The response is a PoC:

"Let's spend one sprint on a PoC targeting our most complex use case. 
 If the PoC reveals showstoppers, we have our answer and we defer. 
 If it works, we have concrete evidence that de-risks the decision."

Proposing evidence-gathering is almost always more persuasive than proposing a decision.

Objection 4: "We'll be on the hook for a new system we don't know"

This is a learning-curve concern. The response is knowledge-building:

"That's a real concern. I'm proposing we earmark the first month as a 
 learning sprint — no production traffic, just understanding the system 
 deeply. We bring in the vendor's support for onboarding. 
 We don't go live until the team feels confident in the operational model."

The Sequencing That Works

The typical mistake is proposing the full migration to a skeptical team. Skeptical teams don't process full proposals — they find the first objection and stop.

Better sequence:

Week 1: Acknowledge the history
"I know we've had migrations stall. I want to understand what went wrong 
before I bring a proposal."
[This builds trust and surfaces the real objections]

Week 2: Find the internal ally
Who on the team shares your view? Start there. A proposal from one 
person is advocacy; a proposal from two people is a pattern.

Week 3: PoC
"Let's try this on one feature before committing to anything."
[PoC results change the conversation from hypothetical to empirical]

Week 4: Scoped proposal
"Based on the PoC, here's a 3-month phased plan with stopping points."
[Proposal now backed by evidence and scoped to be safe]

When to Stop Advocating

At some point, continued advocacy becomes destructive. Signals:

• You've presented the case twice with evidence, and the decision-maker (not the team, the decision-maker) has said no.
• The team is not willing to do a PoC.
• The resistance is organizational, not technical — there's a political reason you're not seeing.

At this point: document your concern, the decision made, and the reasoning, then commit to the current approach. You've done your job.

Story Structure

Context (30s): What was the migration, why did you think it was necessary, what was the team's reaction?

Understanding the resistance (1 min): What was actually driving the pushback? Did you investigate before advocating?

Your approach (2 min): How did you build the case? PoC? Quantified cost of status quo? Finding internal allies?

The turn (1 min): What changed minds? What specific evidence or framing moved the conversation?

Outcome (30s): What happened — did the migration proceed? Did you change your own mind? What would you do differently?

Quick Recap

1. Before advocating, diagnose the resistance — prior migration failures, capacity concerns, immaturity concerns, and learning-curve fears each need different responses.
2. "This time will be different" is not persuasive. Show you've designed for the failure modes they've experienced (incremental steps, stopping points, no big-bang cutover).
3. Quantify the cost of the status quo. "We don't have time" is more convincing when the current system is also costing time.
4. Propose a PoC before proposing a full migration — empirical evidence beats hypothetical arguments with skeptical teams.
5. Know when to stop: if the decision-maker has said no twice with your evidence on the table, document your concern and commit.