WHMCS has confirmed that 8.13 and 9.0 reach end of life on 31 December 2026. After that date neither branch gets security updates or fixes. Installations keep running, but anything discovered in January goes unpatched on the system that holds your client data and payment tokens. The supported target is WHMCS 9.1, generally available since 20 October 2026 with an anticipated end of life of 30 September 2027.
This is for hosts still on 8.13 because 9.0's mandatory invoice immutability broke their workflow, and for anyone on 9.0 who hasn't scheduled the next update. Upgrade before Black Friday traffic, not over Christmas.
What changes in 9.1
| 8.13 | 9.0 | 9.1 | |
|---|---|---|---|
| Security fixes after 31 Dec 2026 | No | No | Yes (until ~Sep 2027) |
| Invoice immutability | Off | Mandatory | Configurable in General Settings |
| PHP 8.4 | No | No | Yes |
| ionCube Loader 15.0.0 | Not required | Not required | Required |
| Unattended maintenance updates | No | No | Yes, on by default |
The reason 8.13 got an extended support window is the immutability change: from 9.0, non-draft invoices could not be edited. 9.1 makes that a setting called Invoice Immutability, under Configuration > System Settings > General Settings > Invoices. You can use full immutability with credit and debit notes (the default), immutability off with notes still available, or both off. Check your local invoicing rules before you relax it.
Upgrade order that avoids breakage
WHMCS is explicit about the sequence, and getting it backwards is what breaks installations.
- Back up files and the database, and clone to a staging copy.
- Upgrade ionCube Loader to 15.0.0 on the current PHP version. Confirm with:
php -v | grep -i ioncube
- Update WHMCS to 9.1 from Utilities > Update WHMCS. Updates only appear if your PHP version is compatible.
- Then move PHP to 8.4. Run Utilities > System > PHP Version Compatibility first to check encoded third-party modules.
On staging, test ordering, invoicing, a real gateway payment, and provisioning for each server module you use. Two other checks are worth doing:
- Plesk servers: the 9.1 Plesk module requires XML API protocol 1.6.9.1, so Onyx 17.8 or Obsidian 18.0+. This matches Plesk's own removal of old XML-RPC protocols in 18.0.82.
- Payments: the legacy Stripe, Stripe ACH, and Stripe SEPA modules are deprecated in favour of Stripe Dynamic Payments, and BitPay now needs a POS token. If you are still on 8.12 or earlier with PayPal Basic or PayPal Checkout, remove or replace those modules before going straight to 9.1, or the admin area returns HTTP 500.
All admins with a "Remember Me" session must log in again after the update. Code that relied on Set-Cookie from includes/api.php also needs updating.
The PHP 8.2 deadline is the same day
PHP 8.2 security support also ends on 31 December 2026. Don't move the PHP version and WHMCS 9.1 at once. Do WHMCS first and PHP second, a few days apart. On cPanel servers, add PHP 8.4 through EasyApache 4 and switch only the billing vhost. On CloudLinux, use the PHP Selector for that account.
Or move off WHMCS
If a forced upgrade every 12 to 18 months is the real problem, this is a natural point to compare costs. Blesta sells an owned license alongside a monthly lease, and ships unobfuscated PHP rather than ionCube-encoded files. Read the Blesta vs WHMCS comparison and the WHMCS-to-Blesta migration checklist. Be realistic about timing: a billing migration is a project, not something to finish before 31 December. Patch WHMCS to 9.1 now, then migrate in Q1 if the numbers support it.
When does WHMCS 8.13 reach end of life?+
Can I turn off invoice immutability in WHMCS 9.1?+
Should I upgrade PHP or WHMCS first?+
Does WHMCS 9.1 support PHP 8.4?+
What happens if I keep running WHMCS 9.0 after December 2026?+
Next steps
- Compare Blesta, WHMCS, and ClientExec
- Scope WHM API tokens for your billing system
- Set up Blesta cPanel provisioning
If you're moving billing platforms, start with a Blesta license. Contact us for volume pricing.