The Framework Upgrade with an EOL Clock

Separate the security fix from the framework upgrade; they have different risk and different clocks.

Sequence:

1. Weeks 1 to 2: confirm exploitability in your configuration. If the CVE is reachable, mitigate without the full upgrade through a dependency override to a patched transitive version, a configuration change, or a compensating control. This buys months and is reversible. Document the residual risk.
2. Weeks 1 to 4: move to Java 17 on the current Spring Boot line if supported. This is large but mechanical, and it de-risks the later step. Run the 1,700 tests, fix failures, and deploy to production before touching the framework. Change one variable at a time.
3. Weeks 4 to 12: upgrade 2.3 to 2.7 and then to 3.x. Spring Boot 3 requires Jakarta EE 9 and later, so javax.* imports become jakarta.* across the codebase. Use automated migration for the mechanical part, then fix by module.
4. Introduce an abstraction layer around the PDF library before the upgrade, so its replacement is independent of the framework work.

Controls: feature flags around changed modules, canary release to 5% of traffic, a rehearsed rollback, and a golden-master suite comparing policy calculations and rendered PDFs before and after.

Why not big bang: a single 240k-line branch accumulates merge conflicts, delays the CVE fix behind a large release, and offers no safe rollback. The end-of-support date is a deadline, not a plan.

Wrap it first, then decide with evidence. The library is used at 60 call sites, but the actual API surface is probably narrow: render, merge, sign. An anti-corruption layer exposing only those operations reduces a replacement from 60 edits to one adapter and creates a place to run side-by-side comparisons.

Options:

• Replace with a maintained open-source library. Best long term if output fidelity is acceptable. Build a golden-master corpus of real documents including edge cases such as fonts, signatures, and accessibility, then diff rendered output before switching. Fidelity, not features, is the risk.
• Fork and patch. Viable if the needed fix is small and you can own the build. It requires a security patch process and an accountable owner; beware the fork drifting into a new legacy system.
• Pay the vendor for support. Fastest if available, but verify that the CVE is actually fixed and that the contract covers future ones.
• Isolate in a separate service. Contains the blast radius if exploitation requires crafted input to this library, at the cost of latency and operational overhead.

Decision criteria: exploitability and exposure, output fidelity risk, three-year total cost including maintenance, and licensing.

Recommendation: add the abstraction layer now; migrate if a maintained alternative passes the golden-master corpus within the upgrade window; otherwise isolate the renderer and schedule replacement. Record the decision in an architecture decision record with a review date, because no decision is how a CVE stays open for two years.

Gates should be evidence-based; the date is a constraint, not a criterion.

Proposed gates:

• Zero critical or high CVEs in the runtime dependency tree, with exceptions documented and time-boxed.
• All 1,700 tests green on Java 17 and Spring Boot 3, and mutation score on the policy-calculation module no lower than the pre-upgrade baseline, which prevents silent test erosion during migration.
• Performance within 5% of baseline for the top 10 transactions on production-like data.
• Golden-master comparison: 100% of the sampled PDF corpus and policy calculations match, with every difference explained.
• Rollback rehearsed in staging with a measured time, and the previous version deployable.
• Canary at 5% of traffic for 48 hours with error rate and latency inside the error budget.

Governance: a weekly go/no-go with the security lead and product owner. If a gate fails, the decision is to delay or to ship with a named risk acceptor and a compensating control, never to lower the gate. Record the decision.

Anti-pattern: a single 'upgrade complete' milestone. The risk is not the build passing; it is behavior drift in a policy system, which only the golden-master comparison and the canary can catch. A date-based milestone measures effort, not safety.