Legacy modernization projects fail less often because the new implementation is bad, and more often because nobody was ever quite sure what the old system actually did — undocumented edge cases, quiet business-logic decisions baked into code nobody's touched in years, behavior that everyone assumes but nobody's verified. Analysis-first is built almost exactly for this problem.
Extracting behavior instead of assuming it
app-analysis reverse-engineers actual functionality — from source code, live interaction with the running legacy system, and tech-stack research — rather than starting from institutional memory of what the system "is supposed to" do. This distinction matters enormously in modernization work specifically, because institutional memory of a legacy system is notoriously wrong in small, expensive ways: an edge case someone forgot about, a business rule that was itself a workaround for a since-fixed bug, a piece of behavior everyone assumed was intentional design and was actually an accident nobody ever corrected.
Design and art analysis for legacy UI you're actually keeping
If the modernization is "same UI, new stack under the hood" rather than a full redesign, design-analysis extracting the existing screen-level flows, component structure, and interaction patterns gives you a genuine specification of the current UI to rebuild against — rather than a new team's fresh guess at what the old screens were trying to do.
Marking origin, so "kept" and "changed" stay visible
Once analysis findings exist, spec-requirements drafts from them with each requirement's origin explicitly marked — reverse-engineered from findings, or genuinely new. This is exactly the property a modernization project needs most: a clear, permanent record of which behaviors were deliberately preserved from the legacy system and which were deliberately changed, so six months post-launch nobody's debating whether a behavior difference is a bug or an intentional improvement.
Where full tier is almost automatic
Modernization work is very often full tier by default — it's frequently the literal definition of "a major extension of something already built," one of the explicit Design-First triggers. The heavier pipeline here isn't overkill; it's proportionate to genuinely replacing load-bearing infrastructure.
Modernization isn't primarily a rewriting problem. It's primarily a knowing problem — and analysis-first is the part of the workflow built specifically to solve it before a single line of the new system gets written.