Plan an upgrade from an unsupported WHMCS version as a sequence of compatible transitions. Very old releases can require intermediate PHP, ionCube and application changes before the final supported version can run.
IN THIS ARTICLE
01 Inventory the starting point
- Record the exact WHMCS version, PHP and ionCube versions, database environment and server operating system.
- List every custom theme, hook, gateway, registrar, provisioning module and addon.
- Read the vendor's Updating Through EOL Versions guidance and the requirements for each necessary intermediate release.
- Choose the supported target based on your actual integration compatibility, not just its version number.
- Create a complete backup and rehearse the sequence on a protected test copy.
02 Build an upgrade sequence
For each stage, specify which application files and runtime versions must change together. Include any point where you must stop and adjust PHP or ionCube before the next stage. Obtain missing legacy upgrade instructions from WHMCS rather than guessing a direct jump.
Review template and module removals. For example, WHMCS 9.0 removes older PHP support and legacy Smarty features. An old theme can therefore need code changes even if the database update succeeds.
03 Test business records and operations
Use representative existing clients, unpaid invoices, recurring services and domain records in the isolated test environment. Verify login, customer permissions, invoice display, payment callbacks and scheduled processing after each material stage.
Keep live gateways, registrars and servers disconnected from the test copy. Record any manual data repair and why it was needed so the production plan can reproduce it accurately.
What if an addon does not support the target WHMCS version?
A module can restrict a workflow to a particular WHMCS major version. The supplied Hosting Suite renewal accounting requires WHMCS 8, so resolve billing ownership and compatible module support before moving that installation to a different major version.
04 Complete the production change
Schedule the tested sequence, create a fresh coordinated backup and control incoming changes during the migration. Validate critical operations before restoring normal automation.
If a stage fails, use the planned recovery point and retain its error evidence. Avoid changing multiple dependencies blindly on the live system. A supported final version is useful only when the integrations and customer records it operates remain correct.