Quantifying migration cost for a major release

WHAT THIS TESTS The interviewer wants quantitative rigor on both sides of a release: a defensible pre-release forecast and a post-release actuals check. They are listening for code analysis, reasonable assumptions, and a feedback loop.

A GOOD ANSWER COVERS Before the release, enumerate each breaking change, then scan consuming repositories with static analysis to count affected usages per change, weighted by complexity (a simple prop rename is cheap, a behavioral change is expensive). Estimate per-usage effort, subtract what a codemod can automate, sum across teams, and convert engineer-hours to dollars using a blended rate to get a forecast. This both justifies the cost and lets you reduce it by investing in codemods. After the release, measure actuals: upgrade lead time per team (announce to merged), engineer-hours logged or PR size as a proxy, the number of support tickets and Slack questions the migration generated, and how many teams stalled. Compare actuals to the forecast to refine future estimates and to prove whether codemods paid off.

COMMON WRONG ANSWERS Guessing a round number with no code analysis, which is indefensible. Counting affected files but ignoring per-change complexity. Never measuring the actual cost afterward, so you never improve the estimate or learn whether codemods helped.

LIKELY FOLLOW-UPS How do codemods change the estimate? How do you weight change complexity? How do you measure effort without timesheets?

ONE CONCRETE EXAMPLE A major release has three breaking changes. An AST scan finds nine hundred affected usages across fifteen repos; you estimate ten minutes each, knock seventy percent off via a codemod, and forecast roughly forty-five engineer-hours. After release you track that teams averaged a six-day upgrade lead time and the migration generated twelve support tickets, validating the forecast and the codemod investment.