Off end-of-life software, without the outage.
Old Ubuntu, PHP and database releases stop getting security fixes, and customers' questionnaires start asking about them. I plan the move, rehearse it on a copy, and do it in a window.
- Moves
- Ubuntu, Debian, CentOS, PHP, MySQL, whole servers
- Method
- Inventory, staging rehearsal, rollback ready, maintenance window, two weeks' stabilisation
- Price
- A fixed quote, in writing
What's past its date, or close
Ubuntu 20.04, Debian 11, Amazon Linux 2, PHP 8.1, MySQL 8.0, MariaDB 10.6 and Node 20 have already stopped getting security fixes. PostgreSQL 14 ends on 12 November 2026 and PHP 8.2 on 31 December 2026, then Ubuntu 22.04 in May 2027. The tracker has every date, with the days left worked out today.
Five steps, every time
- Inventory
What's on the server, what depends on it, and what will break on the new release. You get a written scope and a fixed quote.
- Staging
A copy of the server, upgraded first. Every site and job tested on it, every problem fixed there.
- Rollback ready
A snapshot or the old server kept running, so there's always a way back.
- The window
The real upgrade or switch-over at a time you agree, with checks on every site afterwards.
- Two weeks' stabilisation
Anything that turns up after is fixed as part of the job, and the runbooks are updated.
The usual moves
In place, one LTS at a time (20.04 → 22.04 → 24.04 → 26.04), or rebuilt straight onto a fresh server. 20.04 and 22.04 end of life →
Including the WordPress and Laravel fixes that come with it. 8.1 and 8.2 end of life →
Usually rebuilt; ELevate in place only suits simple servers. CentOS 7 end of life →
Tested against the application first. MySQL 8.0 and PostgreSQL 14 end of life →
Rebuilt onto fresh instances, as there's no in-place path. Amazon Linux 2 end of life →
Consolidation and moves between providers.
Questions
Can you upgrade Ubuntu in place, or do you rebuild?
Both. An in-place do-release-upgrade is fine for a well-kept server; a rebuild onto a fresh machine is safer for one that has drifted for years. I recommend one after the inventory, with the reasons.
Will our sites go down?
Only for the planned window, if at all. Migrations to a new server switch over at the end, once the new one has been tested, and the old one is kept until you're happy.
What if something breaks afterwards?
Every project includes two weeks of stabilisation after the switch: anything that turns up is fixed as part of the job.
How is a project priced?
A fixed quote in writing after the inventory, so you know the cost before anything starts.
What's on your oldest server?
Tell me what you run and I'll tell you the safest way to move it, and roughly what it costs.