Column 1
Skip to content
Column 1

CentOS 7 End of Life: 2026 Web Server Migration Checklist

CentOS 7 cPanel web server migration checklist for backups, supported operating systems, DNS cutover, mail, SSL, PHP compatibility, and verification

Reviewed June 14, 2026: CentOS 7 is no longer a future maintenance problem. CentOS 7 reached end of life on June 30, 2024, and web servers still running it should be treated as migration work, not routine patching.

That does not mean every site has to move in a panic tonight. It does mean the operating system is no longer receiving normal CentOS Linux 7 updates, including security updates. If a production web server, cPanel server, Plesk server, application node, or old VPS is still on CentOS 7 in 2026, the right next step is a planned migration with backups, compatibility checks, and a real rollback path.

Who Should Check This Now

This checklist is for site owners, agencies, hosting admins, MSPs, and small businesses that still have any of these systems in service:

  • CentOS 7 servers hosting WordPress, WooCommerce, Joomla, Drupal, Magento, TYPO3, PrestaShop, or custom PHP sites.
  • cPanel & WHM, Plesk, DirectAdmin, Webmin, Virtualmin, or older unmanaged VPS systems that were built years ago and kept running.
  • Mail, DNS, database, backup, monitoring, staging, or cron-only servers that were forgotten because they do not serve the main website directly.
  • Containers, templates, rescue images, and old cloud images based on CentOS 7.
  • Customer servers that are behind a CDN, WAF, reverse proxy, or managed firewall but still depend on the old operating system underneath.

If you are not sure what a server runs, check it before assuming the host already handled the move. Many older servers survived because the websites still loaded, not because the platform was healthy.

What End of Life Means

CentOS 7 end of life means the normal CentOS Linux 7 update stream is over. The CentOS Project said there would be no updates published for CentOS Linux 7 after June 30, 2024. For a web server, that matters because the operating system sits under the web server, PHP runtime, OpenSSL libraries, database client libraries, SSH, mail services, backup tools, and management agents.

Security tools can reduce risk, but they do not turn an end-of-life operating system back into a maintained platform. A WAF, CDN, malware scanner, or edge rule can buy time during a controlled migration window. It should not become the long-term plan.

Step 1: Inventory The Server Before Choosing A Target

Start with an inventory. The wrong target operating system can create just as much downtime as the old one if the panel, PHP versions, database version, backup tooling, or customer applications do not support it.

  • Web stack: Apache, Nginx, LiteSpeed, OpenLiteSpeed, PHP-FPM, PHP handlers, Node.js apps, Python apps, and reverse proxy rules.
  • Control panel: cPanel & WHM, Plesk, DirectAdmin, Webmin, Virtualmin, or custom automation.
  • Databases: MySQL, MariaDB, PostgreSQL, local database users, remote database hosts, replication, and backup jobs.
  • Sites and applications: WordPress, WooCommerce, Magento, Joomla, Drupal, forums, CRM tools, billing portals, and custom apps.
  • Mail and DNS: Exim, Postfix, Dovecot, Roundcube, SpamAssassin, DKIM, SPF, DMARC, DNS zones, and resolver configuration.
  • Backups: local backups, remote backups, JetBackup, Acronis, rsync jobs, snapshots, database dumps, and restore test history.
  • Security tooling: Imunify360, CloudLinux, KernelCare, CSF/LFD, fail2ban, WAF agents, monitoring agents, and logging agents.
  • Business dependencies: forms, checkout pages, subscription billing, customer portals, API integrations, cron jobs, and scheduled imports.

Document what is actually running before you pick AlmaLinux, Rocky Linux, CloudLinux, Ubuntu, Debian, or a managed hosting replacement. The cleanest migration is usually the one where the destination matches the real workload, not the one that sounds most familiar.

Step 2: Choose A Supported Destination

For many CentOS-style hosting servers, AlmaLinux is the most familiar target. It keeps the RHEL-like package model that many cPanel and hosting workflows expect. CloudLinux may be the better fit for shared hosting where tenant isolation, PHP selector behavior, and resource limits are part of the business model. Ubuntu LTS can be a strong option for Plesk, WordPress-focused servers, and newer unmanaged stacks when the panel and applications support it.

Do not guess. Check the current system requirements from the control panel vendor before you build the replacement server. cPanel lists supported operating systems separately for AlmaLinux, CloudLinux, Rocky Linux, and Ubuntu. Plesk lists supported Linux platforms, recommended versions, virtualization support, upgrade paths, and migration sources in its Obsidian system requirements.

Rocky Linux, RHEL, Debian, and other platforms may still be right for some environments. The point is to choose from the current support matrix for the service you actually run. A generic Linux preference is not enough when customer sites, billing, email, SSL, backups, and panel updates depend on vendor support.

Step 3: Decide Between Migration And In-Place Upgrade

For production hosting servers, a new server plus migration is usually easier to control than an in-place operating system jump. Build the destination, patch it, install the panel or stack, move a test site, verify services, lower DNS TTLs, then schedule a final sync and cutover.

In-place tools can help in labs, simpler servers, and carefully tested paths. AlmaLinux ELevate supports major-version upgrade workflows for RHEL-derived distributions and documents CentOS 7 to AlmaLinux paths. That does not make an in-place upgrade automatically safe for a busy cPanel, Plesk, mail, or ecommerce server. Treat it as a project that needs backups, testing, maintenance time, and a way back if services fail.

If the server hosts paying customers, ecommerce orders, production email, or a business-critical WordPress site, assume you need a staged migration unless you have already tested the exact in-place path on a copy of the server.

Step 4: Back Up And Prove The Restore Path

Do not start the migration with only a dashboard that says backups exist. Prove that the backups can restore the parts that matter.

  • Take a full account or server backup before changing packages or moving accounts.
  • Export databases separately for high-value sites, especially WooCommerce and membership sites.
  • Save control panel account packages, DNS zones, SSL certificates, custom web server includes, cron jobs, mailboxes, and application configuration files.
  • Confirm remote backups are reachable from outside the old server.
  • Restore at least one representative site or account to a staging location before the production window.
  • Record what cannot be rolled back cleanly, such as database writes that happen after the final sync begins.

Snapshots are useful, especially on virtual machines, but they are not a complete rollback plan by themselves. A snapshot can protect the old server state. A tested restore protects the business.

Step 5: Plan The Cutover

A clean migration window should have a written order of operations. For a typical web-hosting move, that order looks like this:

  1. Lower DNS TTLs before the maintenance window.
  2. Patch and reboot the destination server before account content moves.
  3. Install the panel, web server, PHP versions, database packages, backup agent, security tools, and monitoring.
  4. Migrate a test account or staging site first.
  5. Compare PHP versions, modules, database versions, file permissions, SSL behavior, and web server redirects.
  6. Put high-write sites into maintenance mode during final sync when needed.
  7. Move accounts, mailboxes, databases, DNS zones, SSL certificates, and cron jobs.
  8. Update DNS, load balancer, CDN, or WAF origin settings.
  9. Keep the old server available during the rollback window, but restrict access so it does not keep accepting stale writes.

For cPanel migrations, use WHM Transfer Tool or your host's supported account-transfer path where possible. For Plesk migrations, use Plesk Migrator or the documented migration workflow. For unmanaged servers, build a written rsync, database dump, config, service, DNS, and SSL checklist before the window begins.

Step 6: Verify After The Move

Do not call the migration finished because the home page loads. Check the workflows that create revenue, support requests, and customer trust.

  • Confirm the destination operating system version, kernel, panel version, and pending updates.
  • Test HTTP and HTTPS for the main domain, important subdomains, and redirects.
  • Check SSL certificate issuance, renewal automation, HSTS behavior, and mixed-content warnings.
  • Test WordPress admin login, forms, WooCommerce cart and checkout, payment gateways, membership login, search, and scheduled tasks.
  • Check PHP error logs, web server error logs, database logs, mail logs, and panel task logs.
  • Verify mail sending, receiving, DKIM signing, SPF alignment, DMARC reports, and webmail access.
  • Confirm backups are running on the new server and perform a small restore test.
  • Review CDN, WAF, firewall, and monitoring dashboards for unexpected blocks, origin errors, or stale origin IPs.
  • Look for unexpected executable files in webroots after migration, especially on older WordPress and PHP sites.

Keep notes for customer communication. If a form, cart, email route, or admin login needed a fix, record what changed and when it was verified.

Temporary Risk Reduction If You Cannot Move Yet

If a CentOS 7 server cannot be migrated immediately, reduce exposure while the real migration is scheduled.

  • Remove public access to control panels, SSH, database ports, and admin tools wherever possible.
  • Restrict management access to trusted IPs, VPN, or a secure admin jump path.
  • Patch applications, CMS installs, plugins, themes, panels, and third-party agents that still receive updates.
  • Review user accounts, SSH keys, panel users, database users, API tokens, and old FTP accounts.
  • Enable or tune WAF, malware scanning, integrity monitoring, and log retention.
  • Move the highest-value sites first if the whole server cannot move in one window.
  • Give customers a clear migration window instead of leaving them on an unsupported platform indefinitely.

Temporary controls are a bridge. They are not a replacement for a supported operating system.

Related Fix I.T. Phill Reading

Sources

Need help getting an old CentOS 7 server onto a supported platform? Fix I.T. Phill can help inventory the server, plan backups, choose a supported destination, migrate sites, verify email and checkout flows, and keep the rollback path clear.

2026 migration planning refresh

CentOS 7 is past end of life, so web-hosting servers still running it need a migration plan rather than another temporary patch note. Inventory accounts, PHP versions, databases, DNS zones, mailboxes, SSL certificates, cron jobs, backups, and third-party control-panel plugins before choosing AlmaLinux, Rocky Linux, CloudLinux, Ubuntu, or another supported platform.

For cPanel servers, confirm the current cPanel-supported operating systems before building the replacement host. Plan the move around backups, account transfer order, DNS TTLs, mail queue handling, SSL issuance, customer notices, and a post-cutover verification list for websites, wp-admin, forms, mail, backups, and monitoring.

Related Fix I.T. Phill reading

Sources