CubeCart keeps its identity in more places than a single settings screen suggests. The database holds a stored Store URL and SSL preference, the filesystem carries a hardcoded database connection block, and the cache directory hangs on to compiled paths from the old location. When you copy a store to a new domain, a new document root, or a staging subdomain and only change one of those layers, the storefront usually loads once and then redirects you back to the original hostname, or the admin panel throws a blank page while the browser bounces between two addresses. Understanding which layer controls what turns a frightening migration into a predictable checklist.

Everything described here runs inside an unprivileged hosting account. You will work through cPanel Jupiter or DirectAdmin Evolution, File Manager, phpMyAdmin, and a couple of plain text files. No shell administration, no server daemons, and no global database tuning are needed, because CubeCart stores all of its migration-sensitive values in places a normal hosting user already controls.

Where CubeCart stores its identity

Three locations decide whether a migrated CubeCart store behaves. The first is includes/global.inc.php in the CubeCart root. This file defines the database host, name, user, password, table prefix, and the GLOBAL_URL style connection details. When you move to a new server or a new database, this is the file that must match the new credentials, or you get the classic "Database connection error" on every page.

The second location is the CubeCart_config table inside the database. CubeCart serializes most of its store settings into a single row here, and that serialized blob contains the store URL and the SSL flag. Because the value is PHP-serialized, you cannot safely fix it with a blind search-and-replace across the whole SQL dump: serialized strings carry byte-length prefixes, and changing the text without changing the length counter corrupts the row. CubeCart's admin interface writes this value correctly, so the cleanest path is to let the admin panel rewrite it rather than editing serialized data by hand.

The third location is the compiled cache. CubeCart writes rendered Smarty templates and setting caches into cache/ (and historically filerecords / tmp style folders depending on version). These files can embed the old domain and old absolute paths. After a move, stale cache is the usual reason a store keeps showing the previous URL even though the database looks correct. Clearing it is safe and non-destructive because CubeCart regenerates every file on the next request.

Transferring files and the database cleanly

Start on the source account. In cPanel, open File Manager, browse to the CubeCart document root (commonly public_html or public_html/shop), select all files, and use Compress to build a single .zip or .tar.gz. On DirectAdmin the workflow is identical under File Manager. Compressing first avoids the timeouts and half-copied folders that plague file-by-file FTP transfers on large image libraries.

For the database, open phpMyAdmin, select the CubeCart database, choose Export, pick the Custom method, and enable Add DROP TABLE so the import is idempotent. Download the .sql.gz file. On the destination account, create a fresh database and database user through MySQL Databases (cPanel) or MySQL Management (DirectAdmin), assign the user with All Privileges to that database, and record the exact database name, username, and password. Shared hosting prefixes the account name to both the database and user, so the new names will differ from the source even if you typed the same short label.

Upload the file archive into the new document root, extract it with Extract in File Manager, and confirm the folder structure is not double-nested (a common mistake is ending up with public_html/shop/shop/). Import the SQL through phpMyAdmin on the destination. If the dump is larger than the import limit, upload the .sql.gz into the account first and use phpMyAdmin's file-based import, or split the export by tables. Keep an eye on error_log in the document root if the import behaves oddly; permission or duplicate-key messages surface there.

Now edit includes/global.inc.php with File Manager's built-in editor. Update the four values that changed:

$glob['dbhost']     = 'localhost';
$glob['dbdatabase'] = 'newuser_cubecart';
$glob['dbusername'] = 'newuser_ccuser';
$glob['dbpassword'] = 'YourNewStrongPassword';
$glob['dbprefix']   = 'CubeCart_';

Leave dbhost as localhost on Hostiso shared hosting; the local socket is correct and faster than a remote host string. Keep the table prefix exactly as it was in the source database, or CubeCart will report missing tables. Save the file, then set its permissions to 644 so the web server can read it while other accounts cannot.

Changing the store URL and forcing the new domain

With files and database in place, the store may still redirect to the old address because the serialized Store URL in CubeCart_config still points there. The supported fix is to sign in to the CubeCart admin at https://newdomain.com/admin.php, go to Store Settings → General, and correct the Store URL and SSL URL fields to the new domain, then save. Saving rewrites the serialized blob with the correct byte lengths automatically.

If the redirect loop blocks you from reaching admin at all, break the loop temporarily by overriding the URL. Add a line to includes/global.inc.php:

$glob['storeURL'] = 'https://newdomain.com';
$glob['adminFolder'] = 'admin';

That override lets you load admin, correct the database values through the UI, and afterward you can remove the temporary line. Once admin is reachable, empty the compiled cache from Store Settings → Advanced using the Rebuild cache / Clear cache control, or delete the contents of the cache/ folder in File Manager. Do not delete the folder itself, only what is inside it.

Handle HTTPS and canonical redirects in .htaccess at the document root rather than relying on plugins. A safe block for a domain change plus forced SSL looks like this:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.newdomain\.com$ [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]

Only add these rules after the Store URL in admin already matches, otherwise you stack a database redirect on top of an .htaccess redirect and reintroduce the loop. If the document root itself changed (for example moving the store from a subfolder to the primary domain), also update the Document Root mapping in cPanel's Domains area or DirectAdmin's domain settings so the primary domain serves the CubeCart folder directly.

Finish by verifying PHP. Use MultiPHP Manager (cPanel) or PHP Selector under Select PHP Version (CloudLinux) to match the PHP version the store ran on previously, and confirm the required extensions such as pdo_mysql, curl, gd, and zip are enabled. If you need to raise upload or memory limits for the migration, place them in a .user.ini file in the document root:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120

Load the storefront, add a product to the cart, and step through checkout to the payment stage. Session persistence and a working cart across page loads confirm the Store URL, SSL flag, and cookie domain all agree. Watch the document-root error_log during that test; a clean log with the new domain in every generated link means the migration is complete.