Prioritising the backlog

A readiness scan on a real estate returns more findings than any team can fix at once, so prioritisation is the whole game — and the course already gives you the model. Module 8's migration loop prioritises on three axes: is the object actually *used* (SCMON), does it touch a *standard object the Simplification Items are changing*, and what is the *cost to fix*. The readiness self-audit applies the same logic at the practice level, weighting each risky pattern by how hard it blocks cloud adoption (direct table writes and modifications weigh most). Reuse that weighting rather than inventing a new one.

The resulting rule of thumb: high-usage, standard-impacting, low-cost findings go first, because they retire the most upgrade risk per unit of effort. Unused code is a candidate for the decommission policy — mark, watch a cycle, delete (the capstone) — rather than remediation; the cheapest fix is the code you delete. The wrap-versus-rewrite decision (the decoupling-cockpit matrix) sequences the rest: wrap cheaply now where a released equivalent is far off, rewrite where the released API is ready.

Make the priority visible. A single ordered list — deep-linked the way the readiness audit links each finding to the module that fixes it — keeps the team working worst-first instead of cherry-picking easy wins, and lets a lead defend why item B waits while item A ships.

Source notes: clean-core-curriculum (delivery synthesis)