Admin Flows
A migration succeeds or fails on its long tail, not its architecture.
Admin Flows was large enough that pulling it together took multiple Senior and Principal engineers. By the time I drove the stabilization phase, the architecture was settled and what remained was everything that actually decides whether a migration lands: process lifecycle, theming, flyout behavior, and the seams between rejuvenated and legacy surfaces. I synced with partner teams to adopt XAML Islands safely and shipped 12+ fixes into that long tail: two-toned backgrounds and WinUI styling, a process that failed to terminate on exit, and a set of flyout fixes for scenarios the first iteration of AdminFlows never fully supported.
The decision I'd defend hardest was theming. I enforced Dark Mode on flows that hadn't been rejuvenated yet, rather than letting each flow pick up theming whenever its owning team migrated. Per-flow theming is the lower-effort path and it produces a half-themed Settings, which reads as broken to users who neither know nor care which team owns which page. Along the way I also contributed accessibility fixes to the RenamePC page and found a further bug affecting users on Scan Mode and Narrator.
I then learned Microsoft's CFR process and led the release of the AdminFlows experiment out to DevInternal and DevExternal. That was the full plan, develop, and release cycle. What converted this from a one-team effort into multi-org adoption wasn't the fixes: it was partner onboarding documentation for consuming the new visuals and UX, plus office hours where I fielded questions to keep partners unblocked. More than 20 teams in the Windows org ship Rejuvenated Admin Flows.
A platform migration is 20% architecture and 80% making the migration survivable for everyone downstream.