We upgrade the runtime, operating system or database to a current version, or replace individual parts. For every change we plan the way back beforehand.
way back ready
- Test on a copy
- Rollback planned
- Maintenance window
What we modernise
Runtime
PHP, Node.js and Java get new versions regularly, and older ones drop out of support. Security updates for PHP 8.2 end on 31 Dec 2026, support for Node.js 22 on 30 Apr 2027. Along with the runtime we upgrade the dependencies and adapt the code. A move from PHP 7 to PHP 8 usually affects the framework and libraries too.
Operating system
We plan a release upgrade as a rebuild. The new server with the current release goes up next to the old one, then we move the services across. The old server stays as the way back until the new one runs.
Database
PostgreSQL, MySQL/MariaDB and MongoDB have their own end of support dates, PostgreSQL 14 for example on 12 Nov 2026. Before we run an upgrade in production, we test it on a copy of the data.
Replacing individual parts
Some parts are no longer worth maintaining, for example a module without a vendor or a library without a successor. We replace those parts one by one. The rest of the system stays.
All dates are in our EOL calendar.
How we plan a change
We plan changes based on the ITIL® framework. Depending on the risk, every change takes one of three paths.
- Standard changes recur and are approved in advance from a template.
- For a normal change we assess the risk, plan the rollback, get approval from the change authority and apply it in the maintenance window.
- In an emergency we apply the change straight away after expedited approval and do the review and documentation afterwards.
Upgrades of runtime, operating system or database are always normal changes. We fix the rollback beforehand. More under How we work.
Move the mouse over a step or tap it. What happens before it and what comes after stays highlighted.
Keep or replace
Not every legacy system needs replacing. We decide with you based on four points.
- whether runtime, framework and operating system still get updates, paid or not
- how often you have to adapt the system to the business
- whether code and operations are documented or live only in one person’s head
- what maintenance costs over the next few years, compared with a replacement
Often the core stays, and we replace individual parts. We recommend a Legacy Check as the basis for that decision.
Migrating data
We copy large datasets in time windows, with resume points. That way we can stop a run and pick it up later where it left off.
Afterwards we compare, day by day, how many records sit in the old and in the new system. A matching total alone proves nothing, so we compare the contents as well.
We delete in batches, oldest data first, so replication keeps up.
Experience
We run upgrades like these all the time across the 50+ IT services we look after. Which versions run at our clients stays confidential.