You run a dozen Laravel apps for a city government on mixed majors; what upgrade cadence would you set, and what trade-offs does it involve?

## The constraint the cadence must respect Laravel's support policy sets the outer limits: - A new major every year, around **Q1**. - **18 months** of bug fixes and **2 years** of security fixes per major. - Each major has a PHP range; Laravel 13 needs **PHP 8.3** or newer. - Minor releases arrive as often as weekly and are designed not to break code. At the end of September 2026, that means Laravel 13 is fully supported, 12 is security-only until February 24th, 2027, and 11 and 10 are end of life. A city portfolio with apps on all four already has two apps outside any support. ## A policy that fits the rhythm 1. **Minors continuously.** Apply 13.x updates on a regular schedule, for example every sprint, with the test suite as the gate. Small, frequent updates keep the eventual major hop small. 2. **Majors on a calendar.** Each app adopts a new major within a fixed window after its Q1 release, for example by the end of Q3. That leaves time for first-party and third-party packages to publish support, while keeping a year or more of bug-fix coverage. 3. **A hard deadline.** No app enters the previous major's **security-only** phase without an upgrade scheduled, and no app runs past **end of life**. An exception needs an owner and a date. 4. **Deprecations as ongoing work.** Fix deprecations reported during the year instead of saving them for the major, when they turn into removals. ## Ordering the portfolio Not every app deserves the same urgency: | App trait | Priority | |---|---| | Public-facing, handles payments or personal data (permit portal, fines) | first | | Staff-only, behind the network perimeter | second | | Low-traffic, near retirement | decide: upgrade or retire | Within a tier, prefer apps with good tests first: they finish quickly and teach the team the new major before the harder ones. ## Shared code across majors City apps often share an internal package (a single sign-on client, a document-generation library). During a transition some apps are on 12 and some on 13, so the package must support **both majors** for a while. Keep its own changes backward compatible across that window, test it against both, and drop the older major only when the last consumer has moved. ## PHP and infrastructure The PHP floor rises with the framework: Laravel 13 needs 8.3, while Laravel 10 apps may still run on 8.1. Server images, CI runners and the hosting platform must offer the new PHP version before the framework upgrade can start, so infrastructure work belongs at the front of the schedule. ## The trade-offs - **Early adoption** gets new features and the full bug-fix window, but some packages may lag, and the first minors of a major carry the most fixes. - **Late adoption** lets the ecosystem settle, but compresses work into the security-only months, leaves no margin for surprises and risks running an unsupported framework. - **Skipping a major** (staying on 12 and going straight to 14) saves one cycle of work, but still requires applying both guides in order, and leaves the app closer to end of life for longer. - **Standardising** every app on the same major simplifies shared packages and training, but forces the slowest app's pace on the rest unless deadlines are per app. ## Communicating the plan Support windows are easy to explain to non-engineers because they are dates. A one-page plan per year works well: which apps move to the new major and when, which are already in a security-only phase, and which exceptions exist with their owners. Budget the upgrade work in the same planning cycle as feature work, so it is not the first thing cut when deadlines press. ## Measuring it Track, per app: current major and minor, PHP version, date the current major enters security-only and end of life, test coverage of core flows, and the next scheduled upgrade. A simple dashboard of these dates makes the risk visible to people who do not read changelogs.