Quantifying migration cost for a major release
Whether you can estimate and measure migration effort.
Pre-release, scan codebases for affected usages and estimate engineer-hours; post-release, track actual upgrade lead time and effort.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
How do codemods change the estimate? How do you weight change complexity? How do you measure effort without timesheets?
A 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.
Interview question
What most improves the accuracy of a pre-release migration cost forecast?
- a.Assuming every breaking change costs the same per usage
- b.Asking each team to guess their own number
- c.Scanning consumer repos for affected usages and weighting by per-change complexityCorrect
- d.Using last release's total cost unchanged
Why? this is the answer
Counting real affected usages and weighting by complexity grounds the forecast in the actual codebase. Treating every change as equal-cost ignores that a behavioral change is far pricier than a prop rename.
Just read this? Test yourself on what you have been reading.
Read the original → thedesignsystem.guide
- #design-systems
- #migration
- #metrics
- #breaking-changes
- #estimation
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles