Blesta 6.0 landed in August 2026 as the largest release in the project's history, introducing the Paradigm admin interface, signed one-click upgrades, utf8mb4 as the default character set, and a three-tier code reorganization. The follow-up patches (6.0.1, 6.0.2, and the security-focused 6.0.3) arrived quickly after. A release of that scope touches the database schema, the template layer, and the file structure at the same time, which means an upgrade that goes wrong does not simply throw a cosmetic error \u2014 it can leave the installer halfway through a migration with a schema that no longer matches either the old or the new codebase.
On a managed shared account you cannot fix that with a server restart or a root-level database rollback, because you do not have that access. Everything you do runs as an unprivileged hosting user through cPanel Jupiter, DirectAdmin Evolution, phpMyAdmin, and the Blesta AdminCP. That constraint is the entire reason a disciplined procedure matters: your only safety net is the backup you took before you started and your ability to restore it through the same panel tools. This walkthrough assumes you are moving within or onto the supported 6.0.x line and shows how to rehearse, execute, and reverse the change without ever needing a shell.
Take verified file and database backups first
Blesta's own documentation is blunt about this: back up files and the database before any upgrade or patch. The important word is verified. A backup you never confirmed is a guess, and an upgrade is the worst time to discover a truncated archive.
Start with the database, because it carries every invoice, service, and transaction. In cPanel open phpMyAdmin, select your Blesta database in the left pane, click the Export tab, choose the Custom method, and set the format to SQL. Under output, enable \u201cSave output to a file\u201d and set compression to gzipped. Make sure \u201cAdd DROP TABLE / VIEW\u201d is checked so the dump can cleanly overwrite an existing schema on restore. In DirectAdmin the path is the same phpMyAdmin screen, reached through Account Manager > MySQL Management. For larger databases that time out in phpMyAdmin, use the panel's own backup instead: in cPanel, Files > Backup > Download a MySQL Database Backup; in DirectAdmin, Create/Restore Backups with only the database selected.
Now the files. Blesta typically lives under a path like /home/USER/public_html/blesta or a dedicated subdomain docroot. In cPanel File Manager, navigate one level above the Blesta folder, select the folder, and click Compress to produce a .zip or .tar.gz. DirectAdmin's File Manager offers the same \u201cAdd to Archive\u201d action. The single most important file inside that archive is config/blesta.php \u2014 it holds your database credentials and the encryption keys. If you lose it, your encrypted data is unrecoverable even with a good database dump.
Verify both artifacts before continuing. Download the file archive to your machine and confirm the byte size is non-trivial and the zip actually opens. For the database, do not assume success \u2014 if the release notes publish a SHA-256 for downloads, treat your own backups with the same suspicion and at minimum confirm the .sql.gz is more than a few kilobytes and contains CREATE TABLE statements for your core tables when opened in a text editor. Store a copy off the server. A backup that sits in the same account you are about to modify is only half a backup.
Rehearse the upgrade in a staging copy
Because 6.0 changes the schema and the character set, rehearsing against a copy removes almost all of the real risk. Create a staging subdomain in cPanel under Domains > Create a New Domain (for example staging.yourdomain.com pointed at /home/USER/staging), or in DirectAdmin under Account Manager > Domain Setup / Subdomain Management.
Copy the Blesta files into the new docroot by extracting the archive you just made, then create a fresh database and database user via MySQL Databases in either panel and import your .sql.gz dump into it through phpMyAdmin's Import tab. Edit config/blesta.php in File Manager so the staging copy points at the staging database, not production. Leave the encryption keys in that file untouched \u2014 they must match the data you imported. Blesta also records its own hostname and paths in the database, so after the first load you may need to adjust the company URL under Settings > Company > General > Basic Setup to the staging address.
Confirm the staging PHP version matches what 6.0.x requires. In cPanel use MultiPHP Manager to set the PHP version for the staging domain, or use Select PHP Version (PHP Selector) on CloudLinux to enable required extensions such as mysqli, mbstring, json, openssl, and gd. In DirectAdmin this is under Account Manager > Select PHP Version. Raise limits for the migration through a .user.ini file in the Blesta root rather than touching any server config:
; .user.ini in the Blesta docroot\nmemory_limit = 256M\nmax_execution_time = 300\nupload_max_filesize = 64M\npost_max_size = 64MNow run the upgrader on staging exactly as you will in production: browse to https://staging.yourdomain.com/admin/upgrade and follow the prompts, or use the one-click CLI upgrade under Settings > System > Upgrade Options if your account permits it. Watch the Blesta logs/ directory and your account's error_log (visible in File Manager) for PHP fatals during the schema conversion. When the footer shows the new Installed Version and you can log in, create invoices, and run an automation task cleanly, you have proven the real upgrade will work.
Run the production upgrade and keep rollback ready
Schedule the production change for a low-traffic window and put the installation into a quiet state first. Under Settings > System > Automation you can confirm the task runner is idle, and it is worth pausing the cron temporarily so the upgrader is not competing with a billing run mid-migration \u2014 if your cron fires through the panel's Cron Jobs area, comment that line out for the duration. If the automation task itself is misbehaving, the companion article on safe upgrade and rollback planning reinforces the same backup-first mindset across CMS platforms.
Download the correct package from your Blesta client area. A patch (for example blesta-6.0.x patch) only applies within the minor branch it belongs to; a full release is required when crossing from an older minor version. Upload the archive into the Blesta docroot with File Manager, extract it, and let it overwrite the existing files. The 6.0 line ships cryptographically signed releases, so the upgrader verifies the package against Blesta's public key \u2014 do not substitute files from untrusted mirrors or the signature check will fail.
With production files replaced, browse to /admin/upgrade and let it complete, then confirm the version in the footer. If anything fails \u2014 a blank page, a half-migrated schema, or persistent fatals in error_log \u2014 do not re-run the upgrader repeatedly hoping it clears. Roll back immediately: in File Manager delete the broken Blesta directory and extract your pre-upgrade file archive back into place, then in phpMyAdmin drop the affected database tables and import your pre-upgrade .sql.gz dump (the DROP TABLE statements you enabled earlier let this overwrite cleanly). Because you never altered the original config/blesta.php encryption keys, the restored files and restored database match and the system comes back exactly as it was. Re-enable the cron only after you have confirmed login, billing, and a manual automation run all behave on the version you have settled on.