[Platform lifecycle] Migrate off Spring Boot 3.5.x after end of OSS support

[seonghobae]

Buyer / acquisition-readiness gap

Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 pins spring-boot.version to 3.5.16, spring-cloud.version to 2025.0.3, and spring-kafka.version to 3.3.16 in the root Maven authority.

Spring's June 25, 2026 release announcement states that Spring Boot 3.5.16 is the last OSS release of the 3.5.x generation and directs OSS users to upgrade to 4.0.x or 4.1.x, with commercial support as the alternative. Spring Framework's maintained-version guidance likewise records 6.2.x as the final 6.x feature branch and says its OSS support ended in June 2026. A commercial/acquisition-grade platform should not silently depend on an OSS-EOL framework line without either a documented commercial-support entitlement or a tested migration plan to a supported line.

This is a lifecycle/supportability issue, not evidence that the current dependency set is immediately exploitable. Existing dependency/security PRs remain separate and must not be bypassed.

Current exact repository evidence

• protected source: develop@622e5e6c3d534f230c390f10e3832efadfc01825;
• root pom.xml protected blob: 7c0ee7c2add6888706849d305696d1ab4d33e0c3;
• spring-boot.version=3.5.16;
• spring-cloud.version=2025.0.3;
• spring-kafka.version=3.3.16;
• Java target remains 25.

Root-POM work is already active in separate lanes (including shared dependency/security and JaCoCo-control changes), so this issue must not trigger an overlapping root-POM writer until those exact paths/heads are rechecked and a non-racing migration branch can be established.

RCA

• Immediate cause: mightyETL is pinned to the final OSS patch of Spring Boot 3.5.x.
• Technical root cause: framework lifecycle was treated as a version-pinning concern rather than a governed platform-support contract with explicit OSS/commercial-support and migration exit criteria.
• Control failure: current tests validate selected dependency versions and application behavior but do not fail when the foundational framework line leaves the repository's accepted support window.
• Buyer impact: unsupported foundational libraries increase security-response, defect-remediation, compatibility, support-contract and due-diligence risk even when current scanners are green.

Distinct remedies / feasibility

Preferred — test-first migration to a supported Spring Boot line

Use Spring Boot's maintained 3.5→4.0 migration guide and reverify the latest supported 4.x line at implementation time. Before changing dependency management:

1. inventory every direct Spring/Spring Cloud/Spring Kafka/API dependency and explicit override;
2. determine a compatible Spring Cloud release train from primary Spring compatibility guidance rather than guessing;
3. identify removed/deprecated APIs and configuration-property changes;
4. prove Java 25, Maven, standalone modules and modular/MSA profiles remain supported;
5. run dependency-tree convergence, SBOM/license, SAST/vulnerability and reproducibility checks on the exact migration head;
6. exercise application bootstrap and critical ETL/CDC/gateway/config/eureka behavior rather than accepting compilation alone;
7. preserve database migrations, wire formats, authentication boundaries, Kafka semantics and rollback compatibility unless separately versioned;
8. document rollback limits when a major framework migration changes serialized/configuration/runtime contracts.

Alternative — documented commercial support entitlement

If the product deliberately remains on Boot 3.5.x under a valid Spring commercial-support contract, record the support owner, support horizon, patch-distribution process, incident/CVE intake path, evidence retention and migration deadline without storing contract secrets. This reduces lifecycle risk but does not remove the need for a supported-line migration plan.

Reject

• treating the final 3.5.16 OSS release as indefinitely supported;
• blind major-version bump without Spring Cloud/Kafka compatibility proof;
• weakening tests/security gates to make a migration compile;
• copying checks from another PR/head or relying on synthetic-merge-only evidence as exact-source acceptance;
• racing active root-POM writers.

TDD / acceptance

Before production dependency mutation, add a fail-first platform-lifecycle/migration contract that reaches the actual Maven/runtime boundary. The accepted implementation must prove at minimum:

1. the selected Spring Boot line is currently supported by the repository's declared support policy, or a documented commercial-support entitlement explicitly governs the old line;
2. Spring Cloud and Spring Kafka versions are primary-source compatible with the chosen Boot/Framework line;
3. Maven dependency resolution is complete and convergent; no unresolved BOM-managed children are accepted as clean vulnerability evidence;
4. the full reactor compiles and all deterministic tests run with zero skips attributable to the migration;
5. ETL, CDC, gateway, Config Server and Eureka bootstrap/critical contracts are exercised where those modules are supported;
6. security/authentication, Actuator exposure, serialization, Kafka retry/DLT semantics and configuration binding receive targeted regression tests for migration-relevant changes;
7. applicable owned-production statement/branch coverage is exact and non-vacuous;
8. SBOM, dependency review, SAST/vulnerability and provenance evidence is regenerated on the unchanged exact source;
9. deployment, migration/rollback, compatibility, Security, Test Strategy, Operability and Traceability authorities record the supported platform line without promoting active-PR state to shipped truth;
10. qualifying independent review and protected integration gates pass before calling the lifecycle gap closed.

Current execution classification

known_gap / defer_until_non_racing_root_pom_lane.

Do not mutate the root POM from this issue while another active PR owns overlapping dependency/coverage Maven authority. Recheck live PR changed paths and protected develop immediately before implementation. This issue is ready for a dedicated migration spike/RED branch once the root-POM writer lease is available.

Primary references

Spring. (2026, June 25). Spring Boot 3.5.16 available now. https://spring.io/blog/2026/06/25/spring-boot-3-5-16-available-now/

Spring Boot. (2026). Spring Boot 4.0 migration guide. https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Migration-Guide

Spring Framework. (2026). Spring Framework versions. https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions