Selection matters here especially: pick a migration you drove — you set the sequencing, owned the rollback story, made the call on when to advance — not one where you ported a few files of someone else's plan. Lead with the motivation as a risk, not a preference: "our custom token validation was hand-rolled crypto; one bad assumption and every session was forgeable", not "we wanted something cleaner". That framing tells the interviewer you migrate because the status quo is dangerous, which is when the work is justified.

The substance is risk management, and the spine is: make the big change a sequence of small reversible steps, each independently safe to ship and roll back. Run old and new in parallel before you cut over (dual-write, dual-read, or accept-either), so divergence is observable rather than catastrophic. Shift traffic behind a flag — a canary first, then a ramp — with the metric that tells you it's going wrong before customers do, and a kill switch that needs no deploy. The drill is "what would you do differently?" — answer with a specific de-risking lesson, not regret: maybe the dual-write window was too long and you'd have built the reconciliation check first, or you'd have picked a smaller blast-radius service as the canary. Close with the real outcome quantified — "5M users over six weeks, error rate flat, zero unplanned downtime" — and keep the decisions first-person.