Why vBulletin Upgrades Go Wrong on Shared Hosting

A vBulletin upgrade touches three things at once: the PHP application files under your document root, the database schema that every page query depends on, and the configuration that ties them together. When any one of those falls out of sync with the others, the forum stops rendering. The most common failure pattern is an upgrade that half-runs: files get overwritten to the new release, but the upgrade.php script aborts partway through because a table alter timed out, PHP hit a memory ceiling, or the connection dropped. You are then left with new code expecting columns that the database does not yet have, which produces fatal errors on every request.

Shared hosting adds its own constraints. You cannot restart MySQL, raise server-wide max_execution_time, or run a schema migration from a root shell. The upgrade has to complete through the browser-based installer or the command running under your unprivileged account, and it has to respect the PHP limits that apply to your package. If a large post or attachment table needs an ALTER TABLE that runs longer than your execution limit, the browser request dies and the migration leaves the schema inconsistent. This is why a tested backup and a rehearsed rollback matter more than the upgrade clicks themselves.

vBulletin 5 Connect is the current supported major line, and its upgrade path moves the database through a sequence of numbered steps tracked in the datastore and version tables. Because those steps are applied in order and recorded as they finish, a partially applied upgrade cannot simply be re-run from the top without first restoring a clean copy. Treating the upgrade as a reversible operation, where you can return the files and the database to the exact pre-upgrade state in minutes, is what separates a routine maintenance window from an all-night recovery.

Taking Verified File and Database Backups

Before touching anything, read your current version from the AdminCP under Maintenance > Diagnostics and note it along with your PHP version from cPanel > Select PHP Version or DirectAdmin > Select PHP Version (PHP Selector). vBulletin 5 has firm PHP requirements per release, so confirm the target version supports your current PHP branch, or plan the PHP change as part of the same window.

Take the database backup through phpMyAdmin rather than a plugin so you get a clean SQL file you control. In cPanel open phpMyAdmin, select your forum database on the left, choose the Export tab, pick Custom, set the format to SQL, and under output choose Save output to a file with gzipped compression. Enable Add DROP TABLE / VIEW / PROCEDURE so the dump restores cleanly over existing tables. For large forums, phpMyAdmin exports can time out in the browser; if that happens, use cPanel > Backup > Download a MySQL Database Backup, which runs server-side and hands you a gzipped file. DirectAdmin users get the same result from DirectAdmin > Create/Restore Backups by selecting only the database.

For files, compress the entire forum directory so you capture code, templates on disk, and the critical /core/includes/config.php. In cPanel > File Manager, navigate to the parent of your forum folder (often public_html), select the forum directory, and click Compress to produce a .tar.gz. DirectAdmin's File Manager offers the same Add to Archive action. Name the archives with the date and current version, for example:

vb-files-2026-10-05-v5.7.6.tar.gz
vb-db-2026-10-05-v5.7.6.sql.gz

A backup you have not verified is a guess. Confirm the SQL dump is non-trivial in size and that the archive lists your real files by using File Manager's View on the archive or extracting it to a throwaway folder. Then download both files to your own machine so a server-side incident cannot take your backup with it. Record the exact file paths and the database name in a short note; during a failed upgrade you do not want to be hunting for which of five archives is the good one.

Staging a Copy and Running the Upgrade

The safest upgrade never happens on the live site first. Build a staging copy in a subfolder so you can rehearse the full migration against real data. Create public_html/stage in File Manager, extract your file archive into it, and import the database into a new database you create under cPanel > MySQL Databases or DirectAdmin > MySQL Management. Add a user, grant it on the new database, and import the SQL through phpMyAdmin's Import tab after selecting the staging database. Edit stage/core/includes/config.php to point $config['Database']['dbname'], username, and password at the staging database, and set the site URL in the AdminCP after first load so staging does not redirect to the live domain.

Protect staging from search engines and visitors with an .htaccess in the stage folder:

Require ip 203.0.113.0
# or, for basic auth if your IP changes:
# AuthType Basic
# AuthName "Staging"
# AuthUserFile /home/USER/.htpasswds/stage/passwd
# Require valid-user
Header set X-Robots-Tag "noindex, nofollow"

Give the upgrade room to finish by raising PHP limits for the account using a .user.ini at the forum root. On LiteSpeed these values apply per directory and are honored by the PHP handler without server access:

memory_limit = 512M
max_execution_time = 300
max_input_vars = 5000
upload_max_filesize = 64M
post_max_size = 64M

Upload the new vBulletin release files into staging, overwriting the old ones, then run the upgrade by browsing to https://yourdomain.com/stage/core/install/upgrade.php. Step through each numbered migration; if a step stalls, the installer lets you resume from where it stopped, which is exactly the resilience you want to confirm before doing this on live. Watch the account error_log that appears in the forum directory in File Manager for any PHP warnings during schema changes. Once staging renders the forum, admin logins work, and attachments load, you have proven the exact sequence that will run on production.

Going Live, Maintenance Mode, and Rollback

Schedule the live upgrade for a low-traffic window and put the forum into maintenance first. In the AdminCP under Settings > Options > General Settings, set the site to disabled with a message, which stops users from posting while the schema shifts mid-migration. Take one final, fresh database and file backup immediately before the upgrade, because activity since your staging export means the pre-upgrade dump is your only accurate restore point.

Upload the new release files over the live forum directory through File Manager, keeping your existing config.php untouched, then run https://yourdomain.com/core/install/upgrade.php and follow the identical steps you rehearsed. Clear the datastore and rebuild from AdminCP > Maintenance after completion, then bring the site out of maintenance and test posting, search, attachments, and a non-admin account.

If the upgrade fails and the forum will not render, roll back rather than troubleshoot a half-migrated database under pressure. Rename the broken forum directory, extract your pre-upgrade file archive back into place, then drop and re-import the database: in phpMyAdmin select the live database, use Operations or an empty SQL to drop tables, and import your gzipped pre-upgrade dump through the Import tab. Because your dump included DROP statements, the import overwrites cleanly. Within minutes the forum is back on the known-good version, and you can diagnose the failure on staging without any visitor impact. Keep the dated archives for at least a week after a successful upgrade so a late-surfacing issue still has a path home.