+48 501 250 220

Debian 11 and CentOS 7 out of support: upgrade or migrate the server

Support for Debian 11 ended on 31 August 2026, and for CentOS 7 on 30 June 2024 (As of 2026-10). We will upgrade your server, or plan and carry out the move to Debian. We also work with Proxmox VE 8 and with physical servers that we move to Proxmox.

Have your server checked Support dates of the Linux distributions
  • Full stack and DevOps since 2012
  • Virtualisation with KVM and Proxmox
  • Reply within one working day
Two server cabinets with horizontal slots side by side, the left one dashed, the right one outlined in orange; one arrow points to the right, a dashed one back to the left; both stand on one line with a small circle

Is your server still running Debian 11 or CentOS 7?

The question usually comes from outside: a security questionnaire from your client, an audit or a notice from your hosting provider. You can read the version in /etc/os-release.

The server keeps running after support ends, but the project issues no patches for vulnerabilities disclosed afterwards. They stay open until the system is upgraded or replaced.

A server joined by a line to a wall calendar; one day in the calendar grid is marked orange

Security update end dates for Debian and CentOS

As of: 2026-10
Date Event Source
2021-12-31 CentOS Linux 8: end of life. centos.org (opens in a new window)
2024-06-30 CentOS Linux 7: end of life. redhat.com (opens in a new window)
2026-08-31 Debian 11: end of LTS support. wiki.debian.org (opens in a new window)
2028-06-30 Debian 12: end of LTS support. wiki.debian.org (opens in a new window)
2030-06-30 Debian 13: end of LTS support. Regular security updates until 9 August 2028. debian.org (opens in a new window)

Which route suits which starting point? (As of 2026-10)

Criterion Debian 11 CentOS 7 or 8 Proxmox VE 8
Route and target In-place upgrade in stages, first to Debian 12, then to 13, because Debian supports only the step to the next release. The target is usually Debian 13. If your application cannot yet handle its PHP version, we stay on Debian 12. Rebuild on Debian 13 alongside the old server. The old server stays unchanged until acceptance. Upgrade to Proxmox VE 9 following the vendor's guide. First a tested backup of all virtual machines and containers, then the pve8to9 check tool, node by node in a cluster.

Why we plan server and application together

Servers without patches often run unnoticed for years, for example CentOS 8 or Ubuntu 16.04, 18.04 and 20.04. Without Ubuntu Pro, those three Ubuntu versions have received no security updates since April 2021, May 2023 and May 2025 respectively (As of 2026-10).

A new operating system brings new software: Debian 11 ships PHP 7.4, Debian 12 PHP 8.2 and Debian 13 PHP 8.4 (As of 2026-10). An application written for PHP 7.4 needs testing before it runs on the newer versions. The server upgrade then doubles as an application upgrade.

We plan both together. The application side is covered on the page PHP 8 upgrade, and for ColdFusion or Lucee on ColdFusion: end of support and options. The Ubuntu dates are under Linux & DevOps.

An application window standing on a server, a bracket on the left groups both and carries an orange dot; on the right a plan sheet

Five steps, each ending in a written result

  1. Inventory

    We record the operating system, services with versions, applications, cron jobs and certificates. We also record mail sending, backups, third-party packages and modified configuration files. You receive the inventory in writing.

  2. Backup and restore test

    We check that a current backup exists, restore it on a test system and record the result.

  3. Staging

    We build the new state on a copy and test your application on it. Remaining adjustments are listed in order of risk. Your production system stays unchanged.

  4. Changeover in a maintenance window

    We agree the plan, the time and the fallback with you in writing beforehand. We then upgrade or switch over and check everything listed in the inventory.

  5. Documentation and runbook

    We document the configuration and describe operations in a runbook, so that the server can be rebuilt and another provider can take it over.

Still on physical servers? Move to Proxmox or to containers

Often a physical server runs exactly one application, and every machine needs its own updates and backups. We virtualise the machines on Proxmox, in a currently supported version, or move applications into containers:

  • Inventory of the machines, their dependencies, the network and the performance needs
  • Plan: what runs as a virtual machine, what moves into a container?
  • Move in maintenance windows with a fallback plan, backups and a restore test as above

Afterwards you have less hardware to maintain and replace, and a snapshot can be taken before an update. We work out in the plan whether consolidation pays off: hardware, power and licences. For moving applications into containers, see From hosting to containers.

See the Linux operations and infrastructure service

Six small separate machines on the left, thin arrows run into a larger frame divided into compartments on the right, one compartment is filled orange

Our engineers' experience with Linux servers and virtualisation

Full stack and DevOps
Since 2012, from code to server
Operating systems
Debian and Ubuntu in operation, CentOS in migrations
Configuration as code
Ansible with separate inventories for production and test

How we start a server upgrade

  • Secure access to the server via VPN or SSH keys, following your standards.
  • We change nothing on the production system until a restore test has succeeded.
  • Access credentials, configuration and documentation stay with you.
  • We also tell you plainly when an upgrade on its own is not worth it, and propose a solution with the future in mind.

And if someone on our side is unavailable? We write the documentation on request. The repository is normally with you. We arrange cover on request.

More under Experience and How we work.

On the left a sheet with lines of text and a signature line with an orange tick; an arrow points to a server drawn with dashed lines on the right

The first step: intro call, then the server check

Server check

For companies with Linux servers that nobody knows well any more: before an upgrade, after the administrator has left or when a client asks about backups.

  • Version and support status of the operating system and services
  • Hardening: SSH access, firewall, open services and TLS certificates
  • Updates: what is missing and how they have been applied so far
  • Backups: what is backed up and whether a restore test is documented
  • Monitoring and logs: what is monitored and what is missing
  • List of findings in order of priority

At this stage we change nothing on the server. The check does not cover the application or its code. That is what the legacy review is for. We agree the scope and price in the intro call and confirm them in writing before we start. If you wish, you then receive a quote for ongoing support.

What the result contains

A written list of findings in order of priority, with recommendations on hardening, updates, backups and monitoring, plus an upgrade plan with maintenance windows. Both are yours.

Request a server check

Two cases from our work

  • A browser, a box labelled Apache and three lanes to PHP, PHP and CFML; the CFML lane and box are orange

    ColdFusion 2025 in production behind Apache: five traps that are not obvious

    We prepared a production installation of Adobe ColdFusion 2025 on Debian 12, behind an Apache 2.4 that already serves several other sites. The installation itself takes 34 seconds. The attention went into the connector and the configuration details that are easy to miss: an error 503 caused by IPv6, mappings that reach into every virtual host, and a profile that quietly adds a debugger.

  • Four envelopes pass the gates SPF, DKIM and DMARC, each ticked in orange, on the way into the inbox

    Email deliverability for four company domains

    A mail server for four company domains signed nothing, published no DMARC policy and was rejected by Microsoft. Our engineers audited it, piloted the change on one domain and rolled it out in batches. The result: all three checks pass at Gmail, the Microsoft block was lifted, and the users noticed nothing.

Questions that come up before the upgrade

Can we keep running Debian 11 or CentOS 7 for now?

Technically yes, the server keeps running. Without security updates, though, every vulnerability that becomes known after support ends stays open, and there will be more of them over time (As of 2026-10).

Until the upgrade you can reduce the risk. Expose only the services that are needed, limit administrator access to a VPN, put a WAF in front of the application and test the backups. That does not remove the risk. In the intro call we will tell you what is acceptable for your server.

Can we go straight from Debian 11 to Debian 13?

Not on the existing system. Debian supports upgrades only from the immediately preceding release, so the path leads from 11 to 12 and then from 12 to 13. The Debian 13 release notes (opens in a new window) say the same (As of 2026-10). We therefore go step by step and test after each step.

The alternative is a rebuild on Debian 13 alongside the old server. It needs more preparation but leaves the old server unchanged as a fallback. It pays off above all when software and configuration have piled up over the years and nobody has a full picture any more.

What should we replace CentOS 7 with?

We migrate CentOS servers to Debian, our main platform. Debian 13 receives security updates with LTS until 30 June 2030 (As of 2026-10). Beforehand we check whether the application depends on software that exists only for Red Hat-based systems.

We build the new server alongside the old one. The old server stays in place as a fallback until you have signed off the result.

How long is the server unavailable during the changeover?

That can only be said after we have looked at your system. We do not promise a changeover without any interruption. We rehearse the procedure beforehand on a copy, carry out the changeover in a maintenance window agreed with you and keep a rollback ready.

With a rebuild, the new server is set up alongside the old one, and the interruption is usually limited to the switch itself. With an upgrade of the existing system, services and the server restart, so an interruption is to be expected.

What do we gain by moving to a container?

An environment that can be rebuilt. The same version and configuration apply on the developer's machine, on staging and in production, recorded in the repository instead of in one person's head. We test new versions of PHP, Lucee or ColdFusion alongside production and can roll them back. Moving to another server or another provider also becomes easier.

A container fixes no bug in the code and does not bring an unsupported version up to date. It only makes those changes easier.

What is your hourly rate?

It depends on scope, engagement model and urgency. Describe your situation briefly and, after a conversation, we will send you an offer. You do not need a budget for that. We quote fixed prices for the entry products.

When can you start?

You will receive a first reply within one working day. When we begin work depends on our current workload and on the scope. We give you a binding answer in the intro call. If it is urgent, the 48-hour emergency assessment starts as soon as we have access to the system.

Do you cover weekend duty from time to time?

Yes. Support and emergencies are covered around the clock (24/7), weekends included. For other enquiries we are available Monday to Friday, 9:00 to 17:00 Central European Time, and we reply within one working day.

Describe your server to us in three sentences

Tell us the operating system, version, applications and where the server is located (with you or at a hosting provider). We reply within one working day.

Fields marked optional can stay empty.

Reply by email

For a call back we only need your phone number: emergencies around the clock, otherwise within one working day.

Which system, which technology, what do you want to achieve? Please do not send passwords or confidential documents.

Reply within one working day · without obligation

We use your details only to answer your enquiry. Prownex IT Services Sp. z o. o. is the controller. Retention and your rights are described in the privacy policy.