Sequencing an XML-to-Compose migration

A large migration is not N independent screen conversions. It has a critical path, and the ordering decision that matters most is made in week one, before anybody has learned anything.

The version that works: hardest screen first, because the hardest screen surfaces the architectural blockers while there is still budget to solve them properly. Easiest-first looks safer, shows progress for months, then meets every blocker at once with the least schedule left.

Two consequences surprised the project this was mined from:

• The widget swap is the small half. The large half is consolidating state the old screens scattered across host classes, adapters and listeners into something a declarative UI can read.
• Nothing gets deleted until navigation moves. Screens render in the new toolkit long before the old artifacts can go, because the old navigation graph still owns the screen identities.

What the history actually shows