A quiet deadline with loud consequences
On June 30, 2026, open source support for Spring Boot 3.5 came to an end. There was no keynote, no product launch, and no press tour, which is exactly why it is easy to miss and dangerous to ignore. Spring Boot is the default framework for building Java services across a large share of the enterprise, powering everything from banking backends to logistics platforms. When the community stops shipping free patches for a version that many production systems still run, the clock starts on a decision that every engineering organization touched by Java now has to make.
The final community release, version 3.5.16, shipped on June 25, and after that the free security fixes stop. This is not a soft recommendation to upgrade eventually. It is the point at which newly discovered vulnerabilities in that branch will no longer be addressed by the maintainers without a commercial arrangement. For a framework this deeply embedded, the end of open source life is one of those infrastructure events that never trends on social media but quietly reshapes the roadmap of thousands of teams. We treat it as a scheduling forcing function, because that is what it is.
The 4.x generation is the sanctioned path
The officially blessed answer is to move to the Spring Boot 4.x line. Spring Boot 4.0 arrived on November 20, 2025, and 4.1, the current stable release, followed on June 10, 2026. Both are built on Spring Framework 7 and set a minimum of Java 17, with 4.1 supporting newer Java releases through the current cycle. On paper this is a clean generational step, and for teams that have kept their dependencies current it may be a manageable one. The framework's maintainers have every incentive to make the on-ramp smooth, and the 4.x line is where new capabilities will accrue.
The catch is that a major version bump in a framework this central is rarely a one-afternoon affair. Spring Framework 7 brings changes that ripple through configuration, dependency versions, and the wider ecosystem of libraries that a real application pulls in. Third-party migration guidance puts the effort for a 3.x to 4.x move in the range of 200 to 500 hours, depending on the size and age of the codebase. That is a genuine project with planning, testing, and rollback considerations, and it competes for the same engineering capacity that every other initiative wants. Pretending it is trivial is how teams end up stalling.
Most of the fleet is older than you think
Here is the uncomfortable part. The organizations most exposed by this deadline are often not the ones running 3.5. They are the ones still on much older releases. Industry commentary notes that Spring Boot 2.7 continues to carry the largest installed base of any single Spring Boot version, held in place by Java 8 dependencies and third-party libraries that never made the jump to the 3.x line. For those teams, 3.5 reaching end of life is not even the immediate problem; it is a marker on a road they have not started walking, and the gap to a supported release keeps widening.
This is the accumulated cost of deferred maintenance made visible. Every skipped upgrade compounds, turning what could have been a series of routine bumps into a daunting, multi-quarter modernization. The framework treadmill does not stop, and the distance between a long-frozen application and the current supported line grows with each release. We would argue that the end of 3.5 support is a useful moment for leadership to ask a blunt question of every Java service in the portfolio: what version is it on, who owns the upgrade, and what is the plan if a critical vulnerability drops tomorrow.
Paid support buys time, not a reprieve
For applications that genuinely cannot be migrated on the community timeline, a market exists to fill the gap. Vendors such as HeroDevs offer what they call Never-Ending Support, providing continued security patches and compliance documentation as drop-in secure replacements for versions that have aged out of community maintenance. For a regulated enterprise facing an audit, or a business-critical system where a rushed migration carries more risk than a measured one, that can be a rational purchase. It keeps the security patches flowing while the real upgrade is planned and executed properly.
But extended support should be understood as buying time, not as a substitute for modernization. It addresses the security exposure of running an unsupported branch; it does not address the mounting technical debt, the shrinking pool of engineers who want to work on stale stacks, or the eventual incompatibility with the surrounding ecosystem. We would use paid support deliberately, as a bridge with a defined end date and a funded migration on the other side of it. Treating it as a permanent way to avoid upgrading simply moves the reckoning down the road and makes it larger when it arrives.
How to run the migration as risk management
The right way to frame this is not as a framework chore but as risk management, and it belongs in front of the people who own risk. Running an unsupported framework in production means that a future vulnerability in that branch has no free fix, which is a direct security exposure and, in regulated industries, a compliance problem. The cost of the upgrade is knowable and can be scheduled. The cost of an unpatched flaw in an internet-facing service is not, and it tends to arrive at the worst possible time. Put in those terms, the business case for prioritizing the work usually makes itself.
Practically, we would start with an inventory of every Spring Boot service and its version, then triage by exposure and business criticality rather than by convenience. Internet-facing and data-sensitive systems move first. Where a clean migration to 4.x is feasible, fund it now while the deadline pressure is fresh. Where it is not, buy extended support as an explicit, time-boxed bridge and schedule the real upgrade. The framework treadmill is relentless by design, and the platform teams that treat these end-of-life dates as predictable, plannable events rather than surprises are the ones that avoid the fire drills that competitors keep walking into.
The wider lesson for platform teams
Spring Boot is not unique in this. The same dynamic plays out across the open source stack that enterprises quietly depend on, from language runtimes to database drivers to the container base images that everything ships inside. Each has a support lifecycle, each has an end-of-life date, and each of those dates lands with the same soft thud that Spring Boot 3.5 just made. The organizations that get surprised are the ones treating these as isolated events to be handled reactively. The ones that stay ahead maintain a living map of their dependencies and the support horizon attached to each.
That map is arguably the highest-leverage artifact a platform engineering team can own. It turns a stream of unpredictable fire drills into a planned backlog that can be staffed, sequenced, and budgeted. It also gives leadership an honest view of where the real modernization debt sits, which is usually not where intuition suggests. The end of Spring Boot 3.5 support is a single line item on that map. The teams that will look back on it as a non-event are the ones who saw it coming, funded the response, and had already started moving before the community patches stopped.
