Score your readiness with eight yes or no questions: a green baseline, trustworthy tests, a clean warning run, current dependencies, known support dates, an owner, a staging environment and a rollback. Six or more yes answers means you can start now. Fewer means fix the gaps first.
The scorecard
Answer for one service at a time. Give one point per yes.
| # | Question | Why it matters |
|---|---|---|
| 1 | Is the build and test suite green today? | Failures after the upgrade are only attributable if the start was clean |
| 2 | Would a failing test tell you about a real regression? | Tests that pass for everything give false comfort |
| 3 | Do your tests run with deprecation warnings enabled, and are your own warnings cleared? | Removed APIs are the main cause of upgrade breakage |
| 4 | Are direct dependencies within one major of their latest? | Old dependencies often block the framework |
| 5 | Do you know the end of support date for your current and target versions? | It sets your deadline |
| 6 | Is there a named owner and time allocated? | Upgrades without owners stall |
| 7 | Is there a staging environment with production shaped data and traffic? | Many breakages only show under real load |
| 8 | Can you roll back in minutes? | It limits the cost of being wrong |
Reading your score
Six to eight. Start. Pick the target, plan the steps and set gates.
Three to five. Spend a sprint on the gaps first. Fix the failing baseline, clear warnings, add tests around the areas the upgrade will touch. The upgrade itself will be faster afterward.
Zero to two. Treat readiness as the project. Do not attempt a large framework move yet. Start with tests, observability and a deploy process you trust, and with the lowest risk dependency updates.
Common low scoring areas and quick wins
- Weak tests. Add characterization tests: record what the code does now for key flows, so a change shows up as a diff. These are cheap and catch the upgrade regressions that matter.
- Warnings never viewed. Run the suite once with warnings on and read the whole output. Group by owner.
- Stale dependencies. Update those that support both the old and new framework versions, in small pull requests, before the framework move.
- Unknown support dates. Look them up on the project's policy page and record them in your service catalog.
- No rollback. Rehearse one. A rollback you have never used is a hope.
Add a security question
For each service, ask a ninth question: do you know which known vulnerabilities in the current stack are reachable? That answer affects the order of work. A reachable flaw in the current version raises the priority of the upgrade, and an unreachable one gives you time to prepare properly.
Use it across a portfolio
Score every service in one workshop, plot them, and start with services that score high and carry the nearest support deadline. Those are the cheap wins. Services that score low and have a near deadline need an executive conversation about resources, because the cost of doing it fast is high.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are prioritized, which feeds your ninth question.
Quick check
What if one question scores no and the rest yes?
Fix that gap if it is a baseline or rollback problem. Others can be handled during the upgrade.
Should the score be shared with leadership?
Yes, as a portfolio view, with deadlines next to each service.
Safeguard provides dependency inventory, vulnerability and reachability data that you can use to answer the security question. Start with the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
