LiteCart keeps its moving parts unusually simple compared to larger ecommerce platforms, which works in your favor during a migration. There is no framework-level environment file to wrestle with and no compiled container cache to clear. What trips people up instead is a small set of hardcoded values: the store URL stored in configuration, the database credentials written into a PHP include file, and absolute paths that LiteCart records for its data and cache directories. When any of those point at the old account, the old hostname, or the old document root, the storefront either throws a blank white page, redirects endlessly to the previous domain, or loads the catalog with broken asset and image links.

The scenarios this covers are the common ones on managed shared hosting: moving a store between two Hostiso accounts, cloning a live shop into a staging subdirectory, restoring from a backup after a failed update, or replacing the domain entirely (for example switching from oldshop.com to newshop.com). Every one of these comes down to the same three-layer problem — files, database, and the URL/path values that tie them together — so the workflow below applies regardless of which specific task you are performing.

Moving the files and preparing the destination

Start on the source account. In cPanel open Files > File Manager, navigate to the LiteCart root (typically /home/username/public_html or a subfolder like /home/username/public_html/shop), select everything, and use Compress to build a single .zip or .tar.gz archive. Compressing first avoids the thousands of individual FTP transfers that stall on a store with a large product-image library. Download that archive, or if both accounts live on the same server, generate it and move it through the destination's File Manager Upload dialog.

LiteCart stores its uploaded images under includes/data/ and writes cache files to includes/cache/ and cache/. Those directories must survive the move with their contents intact, so confirm the archive actually captured them before you delete anything on the source. In DirectAdmin the equivalent path is System Info & Files > File Manager, and the compress/extract controls sit in the same toolbar.

On the destination, extract the archive into the intended document root. If you are cloning into staging, extract into something like /home/username/public_html/staging and point a subdomain there via Domains > Subdomains rather than overwriting the live site. After extraction, check the permissions: LiteCart expects directories at 755 and files at 644, with the writable folders (includes/cache/, cache/, includes/data/, and logs/) remaining writable by the account user. CloudLinux already isolates each account under its own user, so you do not need group-write or world-write bits — resist the urge to set 777, which the server may reject or flag.

Set your PHP version before testing. LiteCart 2.x runs cleanly on PHP 7.4 through 8.1 depending on release. In cPanel use Software > MultiPHP Manager to assign the domain its version, or Select PHP Version (PHP Selector) to also enable required extensions — mysqli, gd, mbstring, curl, and zip. DirectAdmin exposes the same control under Account Manager > Select PHP Version. Matching the source account's PHP version removes one large variable from your first load test.

Exporting and importing the database

LiteCart keeps the entire catalog, orders, customers, and settings in MySQL, so the database is the heart of the migration. On the source, open Databases > phpMyAdmin, select the store database, and use the Export tab with the Custom method. Choose SQL format, tick Add DROP TABLE so a re-import cleanly replaces existing tables, and download the .sql file. For stores larger than the phpMyAdmin upload ceiling (often 50 MB on shared plans), compress the export to .sql.gz — phpMyAdmin imports gzipped dumps directly, which usually fits under the limit.

On the destination account, create a fresh database and user through Databases > MySQL Databases (cPanel) or Account Manager > MySQL Management (DirectAdmin). Note the full names, which on shared hosting carry the account prefix, such as newuser_litecart and newuser_lcuser. Assign the user to the database with All Privileges. Then open phpMyAdmin on the destination, select the empty database, and use Import to load the dump. If the import times out on a very large file, raise limits temporarily for the session by creating a .user.ini in the LiteCart root:

max_execution_time = 300
memory_limit = 512M
post_max_size = 128M
upload_max_filesize = 128M

Give the FastCGI process a minute or two to pick up the new .user.ini values, then retry the import. Remove or trim those overrides once the migration is complete so staging values do not linger on the live account.

Rewriting configuration, paths, and store URLs

LiteCart reads its connection and path settings from includes/config.inc.php in the store root. Open it in File Manager with Edit and update the database constants to match the new account: DB_SERVER (keep localhost on shared hosting), DB_USERNAME, DB_PASSWORD, DB_DATABASE, and the table prefix if you set one. In the same file, LiteCart defines absolute filesystem and URL constants — commonly DIR_FS_STORAGE, DIR_FS_DOCUMENT_ROOT, WS_DIR_APP, and the HTTP/HTTPS server URLs. The filesystem paths still reference the old home directory (/home/olduser/), so rewrite them to the new absolute path. Getting DIR_FS_DOCUMENT_ROOT wrong is the usual cause of a blank page with a path-not-found entry in the log.

The storefront and admin URLs are stored in two places. The config file holds the base server URL constants, and the database settings table holds additional store and admin address values. In phpMyAdmin run the SQL tab against the new database to surface the stale entries:

SELECT `key`, `value` FROM `lc_settings`
WHERE `value` LIKE '%oldshop.com%';

Update the matches in place, adjusting the table prefix to yours:

UPDATE `lc_settings`
SET `value` = REPLACE(`value`, 'oldshop.com', 'newshop.com')
WHERE `value` LIKE '%oldshop.com%';

After the database is clean, handle redirects and HTTPS at the .htaccess level so visitors and crawlers land on the canonical new domain. LiteCart ships a root .htaccess; add a canonical host and HTTPS block near the top of the LiteSpeed rewrite section:

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

If you migrated into a subdirectory or changed the document root, verify that RewriteBase in the LiteCart .htaccess reflects the new path — RewriteBase / for a root install or RewriteBase /shop/ for a subfolder. A mismatched base is what produces 404s on every internal link while the homepage still loads.

Final housekeeping: empty the contents of includes/cache/ and cache/ through File Manager so LiteCart regenerates templates and configuration snapshots against the new URLs, then issue a fresh SSL certificate for the new domain through Security > SSL/TLS Status and its AutoSSL run. If outbound payment callbacks matter to your setup, the same TLS and credential principles described in this guide on checkout callbacks and outbound TLS apply once the new hostname is live. Watch logs/error.log and the account's error_log during the first storefront load to catch any remaining stale path before customers do.