# Is Your Website Running an End-of-Life PHP or CMS? How to Check and What It Costs to Fix _Published 2026-09-20 · Updated 2026-09-20 · Security & Maintenance · https://websitesupgrade.com/guides/eol-php-cms-check/_ > You can find your PHP and CMS version yourself in about ten minutes, and the answer decides your next move. As of 2026, anything on PHP 8.1 or older, WordPress below the current release, Joomla 4, or Drupal 10-or-older is at or past the end of free security fixes — not an emergency, but a real, growing risk. Check first, then decide between a cheap version bump and a planned migration. > Your site probably runs on PHP — WordPress, Joomla, Drupal, Magento, and most custom sites built before 2020 all do. PHP versions have a fixed support life, and when a version crosses its end-of-life date it keeps working but stops receiving security patches. The same is true of the CMS on top of it. This guide shows you how to check both versions yourself, which versions are end of life as of 2026, and what fixing the problem typically costs in Canada. By the end you will know whether you need a ten-dollar hosting toggle or a budgeted migration project. ## How to check your versions in ten minutes You do not need a developer for the check itself. Three places, in order of ease: 1. **Your CMS admin.** WordPress: *Tools → Site Health → Info → Server* shows the PHP version, and the dashboard footer shows the WordPress version. Joomla: *System → System Information*. Drupal: *Reports → Status report*. Magento: the admin footer shows the version. 2. **Your hosting control panel.** cPanel hosts show the PHP version under *MultiPHP Manager* or *Select PHP Version*; Plesk shows it under the domain's *PHP Settings*. 3. **Ask, if the panels are gone.** One email to your host or developer — "what PHP and CMS version is my site on?" — has a one-line answer. Write down both numbers before reading on. The PHP version and the CMS version age independently; a current WordPress on PHP 8.1 is still exposed. ## What is actually end of life in 2026 PHP publishes its own support calendar at [php.net/supported-versions.php](https://www.php.net/supported-versions.php): each branch gets two years of active support, then two years of security-only fixes, then nothing. As of 2026 the table reads: | Branch | Status as of late 2026 | Security fixes until | |---|---|---| | PHP 8.1 | **End of life** | ended 31 Dec 2025 | | PHP 8.2 | Security fixes only | 31 Dec 2026 | | PHP 8.3 | Security fixes only | 31 Dec 2027 | | PHP 8.4 | Active support | 31 Dec 2028 | | PHP 8.5 | Active support | 31 Dec 2029 | For the CMS layer, as of 2026: WordPress officially supports only its latest release (the 7.x line), though it has historically back-ported critical fixes to much older versions as a courtesy — do not count on courtesy as a security posture. Joomla 4 reached end of support in late 2025; the supported line is Joomla 5/6. Drupal 7 reached its final end of life in January 2025, and Drupal 10's end of life is tied to the Drupal 12 release cycle — check [drupal.org's release-cycle page](https://www.drupal.org/about/core/policies/core-release-cycles/schedule) for the current date. Magento 1 has been unsupported since 2020; Adobe Commerce and Magento Open Source 2.x follow Adobe's published lifecycle. The short version: PHP 8.1 or older, Joomla 4 or older, or Drupal 10 or older all mean "no more free security fixes" either now or within months. ## How risky is it, honestly End-of-life software is not a fire alarm. Sites do not get hacked the day support ends. What changes is the direction of risk: every disclosed vulnerability from that date onward stays unpatched on your site forever, and attackers specifically scan for old versions because they are the cheapest targets. As of 2026, automated scanning for EOL PHP and CMS fingerprints is routine. Two honest qualifications. First, some hosts run *hardened* PHP builds (CloudLinux HardenedPHP is common on shared hosting) that back-port patches to EOL versions — ask your host whether yours does, because it changes the urgency from "now" to "soon". Second, an EOL version on a brochure site with no forms is less exposed than the same version behind a store checkout. Neither qualification is a reason to stay put; both are reasons to plan rather than panic. ## What fixing it typically costs Costs scale with how many versions you have to jump, not with the version itself. Typical ranges we see quoted in Canada as of 2026: | Situation | Typical effort | Typical cost (CAD) | |---|---|---| | PHP bump one or two versions, current CMS | 2-8 hours | 0-500 (often a hosting toggle + test) | | PHP bump plus CMS minor updates, some plugin conflicts | 1-3 days | 500-2,000 | | EOL CMS (Joomla 4, Drupal 7/10, WP far behind) with custom code | 1-4 weeks | 2,000-8,000+ | | Migration to a different platform | 2-8 weeks | 5,000-20,000+ | These are ranges, not quotes — the spread is real. A "cheap" PHP bump stops being cheap the moment a paid plugin or a custom theme refuses to run on the new version, which is why the middle row exists. ## Upgrade in place or migrate The decision is usually simple: - **Stay and upgrade** when the CMS itself is still supported, the content model still fits, and the only problem is versions. A version bump is always cheaper than a migration. - **Migrate** when the CMS is dead (Drupal 7, Magento 1), when you are planning a redesign anyway, or when annual maintenance on the old stack exceeds the cost of moving. If you are weighing that second case, our [refresh-or-rebuild test](/guides/refresh-or-rebuild-test/) is the next read. Either way, the order of operations is the same: 1. **Copy the site to staging** — a subdomain on the same host or a local copy; your host or developer can usually produce one in under an hour. 2. **Upgrade there first.** Bump PHP, update the CMS, update plugins and themes, one layer at a time so you can tell which step breaks. 3. **Test the paths that make money** — every form, the checkout, the search, login if you have one. Design glitches are visible; a silently failing contact form is not. 4. **Switch production, keep the rollback.** Hosts can usually flip PHP back for a day or two while you confirm nothing regressed. Never upgrade production in place without a copy — that is the one step that turns a routine fix into a lost weekend. If performance is also on your list, the triage order in our [slow-website guide](/guides/slow-website-what-to-fix-first/) pairs well with a PHP bump, since newer PHP is measurably faster. ## What to tell whoever does the work You can save billable hours by arriving with three facts: your current PHP and CMS versions, whether your host offers a staging copy, and a list of the plugins or custom features you actually depend on. "WordPress 6.x on PHP 8.1, WooCommerce plus these five plugins, staging available" turns a vague "my site might be out of date" call into a scoped job — and a scoped job is the difference between the first and third rows of the cost table. — Editorial team. Facts current as of 2026; we revise guides when the ground shifts. ## FAQ **My site works fine — is end-of-life PHP actually a problem?** Working is not the same as safe. EOL means reported security holes no longer get patched, so the risk grows every month — quietly. It also blocks other work: many hosts and plugin vendors now require PHP 8.2+ as of 2026. **Can I just click 'update' and be done?** Sometimes. A minor PHP bump on a current CMS is often a hosting-panel toggle plus a test pass. The expensive cases are jumps of several versions or an EOL CMS with custom code — budget days to weeks, not minutes, and always test on a copy first. **What if my host does not offer a newer PHP?** Then the host is part of the problem. Most Canadian and global shared hosts offer PHP 8.3+ as of 2026; if yours tops out below that, moving hosts is usually cheaper than staying unpatched. ## Related - https://websitesupgrade.com/guides/slow-website-what-to-fix-first/ - https://websitesupgrade.com/guides/refresh-or-rebuild-test/