What falls between November 2026 and the end of 2027
Eight deadlines shape the calendar of a client site estate. Two have already passed: Node.js 20 (30 April 2026) and Debian 11 LTS (31 August 2026). They are no longer planned, they are caught up on. Four fall within twelve months: PostgreSQL 14, PHP 8.2, Node.js 22 and Ubuntu 22.04. Two close out 2027: PostgreSQL 15 and PHP 8.3.
The table below sorts them by date, with the primary source and the action to put in the plan. One reading rule: the date is the one the vendor publishes, to the exact day when it gives one, to the month when it only publishes the month. Nothing comes from a third-party site without confirmation at the source. For the detail of a migration, follow the guide named in the first column: this article sets the order, it does not redo the tutorials.
End-of-life calendar, in date order
Scroll the table
| Component and detailed guide | End of support and source | Action to schedule |
|---|---|---|
| Node.js 20 — guide: Node.js 20 end of life, migrating your VPS | 30 April 2026, already passed — nodejs/Release repository, schedule.json | Debt: move to Node.js 22 or 24 without waiting |
| Debian 11 — guide: Debian 11 end of life, Plesk, dist-upgrade or migration | 31 August 2026, already passed — wiki.debian.org/LTS | Debt: dist-upgrade to Debian 13 or migrate |
| PostgreSQL 14 — guide: PostgreSQL end of life, planning the version upgrade | 12 November 2026, final release — postgresql.org/support/versioning | Dump and restore or pg_upgrade to a supported major |
| PHP 8.2 — guide: PHP 8.2 end of life, migration checklist | 31 December 2026, security support — php.net/supported-versions | Move every site to PHP 8.4, since PHP 8.3 ends a year later |
| Node.js 22 | 30 April 2027 — nodejs/Release repository, schedule.json | Move to Node.js 24, supported until 30 April 2028 |
| Ubuntu 22.04 LTS — procedure: Ubuntu 24.04 to 26.04, do-release-upgrade | May 2027, standard security maintenance — ubuntu.com/about/release-cycle | Upgrade to Ubuntu 24.04 before the start of the month |
| PostgreSQL 15 | 11 November 2027, final release — postgresql.org/support/versioning | Plan the next major, PostgreSQL 16 running until 9 November 2028 |
| PHP 8.3 | 31 December 2027, security support — php.net/supported-versions | Nothing to do for sites already on PHP 8.4 (security support until 31 December 2028); move the others |
Active support, security support, final release: three meanings of the word end
Vendors do not all mean the same thing by end. PHP distinguishes two phases: active support, which brings bug fixes and security fixes, then security support, which delivers only critical fixes. PHP 8.2 left active support on 31 December 2024, PHP 8.3 on 31 December 2025. The dates in the table are therefore security support dates: 31 December 2026 for PHP 8.2, 31 December 2027 for PHP 8.3. PHP 8.4 stays in active support until 31 December 2026 and in security support until 31 December 2028.
PostgreSQL speaks of a final release: after the date, no further minor release ships for that major. Node.js speaks of the end of life of the line, Debian and Ubuntu of the end of standard security maintenance. In every case, after the date, a newly found flaw is no longer fixed by the vendor's standard support: that date, not the site going down, is what defines the risk.
How to order the estate: six priority rules
- Debts first — Node.js 20 and Debian 11 are past their end date; they come before any upcoming deadline, even if the site shows no symptom.
- Then the nearest date — the order of the table is the order of work, unless a client constraint says otherwise.
- The longest job before the shortest — a PostgreSQL major needs a tested restore; a PHP version change is validated site by site. The first one starts earlier.
- The system carries the rest — the Debian or Ubuntu version often determines the PHP and database versions offered by its repositories; plan the system upgrade together with them.
- The client with several deadlines goes first — a site that combines PHP 8.2, Node.js 20 and PostgreSQL 14 costs three interventions if handled component by component, one if handled by window.
- An uncertain date is handled at its start — when the vendor publishes only the month, plan before the month, not on the last day.
Debts already due: Node.js 20 and Debian 11
Two rows of the table are no longer forecasts. Node.js 20 reached its end on 30 April 2026, Debian 11 the end of its LTS support on 31 August 2026. The classic mistake is to put them in next year's budget when they are already out of support. A debt is costed and repaid; it is not planned at the pace of a future end of life.
For Node.js, the target is line 22 or line 24. Line 22 ends on 30 April 2027 and line 24 on 30 April 2028: choosing 24 avoids returning to the same job in six months. For Debian, the target is Debian 13, whose LTS support ends on 30 June 2030. Debian 12 is only a stepping stone: its LTS support runs from 11 June 2026 to 30 June 2028. The full procedures are in our guides on Node.js 20 and on Debian 11; they are not redone here.
PostgreSQL: the deadline you cannot catch up on in place
PostgreSQL 14 publishes its final release on 12 November 2026, PostgreSQL 15 on 11 November 2027 and PostgreSQL 16 on 9 November 2028. The pace is yearly, and it is the only family in the table where changing version is not a simple update: a major cannot be installed over the previous one, because the storage format changes from one major to the next.
Two routes remain: a logical backup restored into the new version (pg_dump then pg_restore), or pg_upgrade, which converts the data directory. In both cases, plan for downtime proportional to the database size and a restore tested before the switch. For an estate, this puts PostgreSQL at the head of the queue as soon as its date approaches, even when the site using it is simple. Both methods are detailed in our guide on PostgreSQL version upgrades.
MySQL: a deliberate gap in the table
MySQL is not in the table, on purpose. A deadline for MySQL 8.0 circulates on endoflife.date, but we did not find it in the Oracle documentation we read: without a primary source, it stays out. What is established is the model of LTS series: five years of premier support, three years of extended support, and an upgrade from LTS to LTS without skipping a series. MySQL 8.4 is an LTS series. If some clients are still on 8.0, the migration guide to MySQL 8.4 remains the reference; add the row to the table as soon as you have read the date from the vendor.
Grouping by client and by window: the method in seven steps
Read the versions of every client server
On Debian or Ubuntu:
lsb_release -d. On RHEL or AlmaLinux:cat /etc/os-release. Then for each stack:php -v,node -v,psql --version. One line per server and per component in a spreadsheet.Do not forget containers
An up-to-date server can host an old image. List them with
docker image ls, then query each image:docker run --rm <image> php -vordocker run --rm <image> node -v.Put its end date on every line
Copy the date from this article's table next to each component you recorded. The resulting column is the only one you need to sort.
Compute each client's first deadline
For each client, keep the nearest date across all servers. It sets the client's window: everything that expires in the following months joins the same intervention.
Choose a single window per client
PHP, Node.js and system in the same intervention, with a single prior backup and a single rollback plan. The windows table below gives a split by deadline.
Rehearse on a copy before touching production
Restore the backup onto a test machine, play the upgrade, then check the site. For PostgreSQL, restore the dump and run the application's queries before switching.
Record and recompute
After each intervention, update the row with the new version and its end date. The calendar recomputes itself, and the spreadsheet becomes the agency's register.
Proposed maintenance windows
Scroll the table
| Window | Deadlines covered | Recommended grouping |
|---|---|---|
| Window 1: before 12 November 2026 | PostgreSQL 14 only | Only the PostgreSQL upgrade fits in these fifteen days; the Node.js 20 and Debian 11 debts are handled in parallel, without waiting for this date |
| Window 2: before 31 December 2026 | PHP 8.2 | Move every site straight to PHP 8.4, to avoid a second job within the year; a window to set before the year-end freeze |
| Window 3: two months before 30 April 2027 | Node.js 22 and Ubuntu 22.04 (May 2027) | A single intervention: runtime and system, set two months before the first date: waiting until 30 April 2027 would leave no margin |
| Window 4: before 11 November 2027 | PostgreSQL 15 | Next major by dump and restore or pg_upgrade, rehearsed on a copy |
| Window 5: before 31 December 2027 | PHP 8.3 | Only concerns sites left on PHP 8.3, to move to PHP 8.4; can merge with window 4 for clients who accumulate both |
Ubuntu 22.04: why “May 2027” without a day
For Ubuntu 22.04 LTS, Canonical announces the end of standard security maintenance in May 2027, without publishing a day. The endoflife.date site shows 1 June 2027. Both readings are compatible with an end of month, but only Canonical's wording is a primary source; the other site's day is a reading. We therefore write “May 2027” and plan the upgrade before the start of the month.
The next version, Ubuntu 24.04 LTS, is announced with standard maintenance until May 2029. The do-release-upgrade procedure is described in our guide Ubuntu 24.04 to 26.04; it applies the same way from one LTS to the next, with a full backup before each jump.
A calendar is decided, not delegated
The dates in this article are those of the writing: recheck them at the source before planning, since a vendor can change them. ServOrbit provides the guides; administering your servers and running the migrations remain your responsibility, guide provided, no hands-on support. Always test on a copy.
Seeing the whole estate in a single table
An end-of-life calendar is only worth something if you see the whole estate in one place. The ServOrbit.com agency platform centralises your clients' domains, hosting and VPS, with their renewal deadlines: it is the starting point of step 1, an up-to-date list of clients and machines rather than a spreadsheet rebuilt every quarter. Software end-of-life dates are not tracked by the platform: the versions installed on each server are read on the machines, with the commands above, and matched against this table.
The official documentation
Supported PHP versions: https://www.php.net/supported-versions.php
PostgreSQL versioning policy: https://www.postgresql.org/support/versioning/
Node.js release schedule: https://github.com/nodejs/Release/blob/main/schedule.json
Debian LTS: https://wiki.debian.org/LTS
Ubuntu release cycle: https://ubuntu.com/about/release-cycle
MySQL releases and LTS series: https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
Ubuntu dates on endoflife.date: https://endoflife.date/ubuntu
