cPanel & WHM 134 LTS Upgrade Planning Checklist: Prepare 110 ELS Hosts

admin

2 hours ago

cPanel & WHM 134 is the current Long-Term Support release. For teams with hosts still on version 110’s Extended Lifecycle Support path, this is the time to plan the transition around the operating system, hosted applications, and customer communications instead of treating the update as a single button click.

This checklist is for administrators who want a deliberate path to the next LTS release without surprises for WordPress, email, DNS, SSL, backups, or the account-level software their customers depend on.

Understand what 110 ELS means

cPanel’s product-version documentation lists version 110 with an approximate December 2026 end-of-life date. It also documents an Extended Lifecycle Support exception through January 1, 2027 for cPanel & WHM 110 servers running CentOS 7 or CloudLinux 7. Those hosts receive critical updates during that period, but the exception is a planning window, not a reason to postpone an operating-system and control-panel transition indefinitely.

Start by separating two decisions: the operating system path and the cPanel & WHM release path. A server can need an operating-system migration before it is a sensible candidate for a current LTS release.

Decide whether 134 LTS is the right target

Record the server’s installed cPanel & WHM version, selected update tier, and operating system.
Choose a target that fits the host’s operating-system support, installed software, and maintenance policy.
Use the WHM Update Preferences interface to review the selected tier and its automatic-update behavior.
Do not plan on a major-version downgrade as a rollback strategy. cPanel documents that major-version downgrades are not supported.
Avoid pinning an old custom build unless cPanel support has given you a specific reason. Custom version numbers do not receive the normal update behavior.

cPanel also notes that an LTS server can move to the next LTS release when it becomes available, even before the prior LTS reaches its documented end of life. Put that behavior into the maintenance plan rather than discovering it during a busy period.

Build a preflight inventory

Write down the pieces that make this server useful before scheduling an update. The inventory becomes both the test plan and the fastest way to explain a maintenance window to customers.

List the accounts and their critical sites, including WordPress and WooCommerce stores.
Record active PHP versions, EasyApache profiles, extensions, and application requirements.
Inventory third-party WHM plugins, billing integrations, backup tooling, monitoring, and security services.
Identify mail, DNS, SSL, database, cron, and queue-dependent workloads that need a post-change check.
Confirm license status, maintenance contacts, and the approved communication path for affected customers.

Old operating systems, custom PHP stacks, or vendor plugins that only document an older control-panel range deserve their own migration decision. Do not hide those exceptions inside a general cPanel upgrade ticket.

Stage the path before production

cPanel recommends that administrators stage updates and test compatibility before moving production servers. Use a representative non-production host or a carefully chosen low-risk server to validate the exact services your customers use.

Confirm supported operating-system options before committing to the target release.
Test a representative set of sites, PHP applications, mailboxes, databases, DNS zones, SSL renewals, and backup restores.
Verify that monitoring and alerting still identify the server and its services correctly after the change.
Document every compatibility exception, owner, and decision before the production window.

Run the production change deliberately

Set a maintenance window that gives customers a clear contact path and leaves time for service verification.
Confirm that the approved recovery point is present and that the team knows how to use it. This guide does not change or create customer backup schedules.
Review Update Preferences in WHM, select the approved tier through the supported interface, and keep the target aligned with the tested plan.
Monitor the maintenance progress and the services that matter to hosted accounts rather than assuming a completed update means every workload is healthy.
Pause for a vendor-supported compatibility decision if a prerequisite or third-party integration does not meet the documented target.

Verify hosted services after the upgrade

Sign in to WHM and a sample cPanel account.
Load representative WordPress and WooCommerce pages on the expected PHP versions.
Send and receive a test message for representative mail domains.
Check DNS resolution, SSL presentation, database-backed pages, scheduled work, and queued jobs.
Review backup visibility, monitoring status, and server error logs for new compatibility warnings.
Close the maintenance notice only after the documented checks pass or any remaining exception has an owner and customer-facing plan.

When to bring in support

Stop and get a vendor-supported answer when the server is on an older operating system, relies on a custom cPanel build, has a critical plugin without a documented compatibility position, or cannot complete the staging checks. A short pause before production is much cheaper than repairing email, checkout, or account-management issues afterward.