Active eCommerce CMS is a Laravel application, and that architecture shapes everything about how a migration behaves. The absolute site URL, mail configuration, file-storage paths, and database credentials all live in a single .env file at the application root, while the marketplace stores its own copy of the base URL and uploaded image paths inside several database tables. When you move the install to a new account, clone it into a staging subdomain, or replace the primary domain, these two sources of truth drift apart. The symptoms are predictable: the storefront loads but CSS and product images 404, the admin panel redirects to the old hostname, AJAX calls to the cart fail silently, and payment return URLs point at the wrong domain.

None of this requires root access to fix. Everything a hosting user controls on our LiteSpeed, AlmaLinux, and CloudLinux stack is enough to complete a clean migration: File Manager to move and edit files, phpMyAdmin to export and import the schema, the PHP Selector to match the runtime version, and a plain text editor for .env and .htaccess. The sections below walk through the full sequence in the order that avoids cache corruption and broken sessions.

Moving the files and database onto the new account

Start with a full capture of the source install. In cPanel File Manager open the application directory (typically /home/USER/public_html for a root-domain install, or a subfolder if Active eCommerce lives under a path), select everything including the hidden .env and .htaccess, and use Compress to build a single archive. On DirectAdmin Evolution the File Manager offers the same Add to archive action. Hidden files are the ones that trip people up, so confirm File Manager is set to show dotfiles via Settings → Show Hidden Files before compressing.

Download the archive, then upload and extract it into the destination document root. Keep the folder structure identical: the public directory, storage, bootstrap/cache, and app must all land in the same relative positions. If the new account uses a different document root than the old one, you still extract the application body in the same layout and only adjust the web entry point later through .htaccess, never by scattering files.

For the database, export from the source using phpMyAdmin. Select the Active eCommerce database, open the Export tab, choose Custom, and under format-specific options enable Add DROP TABLE so re-imports stay clean. For stores with large products or orders tables, set the compression dropdown to gzipped to stay under upload limits. On the destination, create a fresh database and database user through cPanel's MySQL Databases wizard (or DirectAdmin's MySQL Management), assign the user with ALL PRIVILEGES, then import the dump through phpMyAdmin's Import tab. Record the exact new database name, username, and password, because they are the first values you will rewrite in .env.

Match the PHP runtime before you load the site. Active eCommerce releases generally target PHP 8.1 or 8.2. In cPanel open MultiPHP Manager, select the domain, and set the same major.minor version the source account used; in DirectAdmin this is under PHP Selector. A mismatched PHP version produces a blank page or a 500 before any URL logic even runs, so settle this first.

Rebasing the .env file and database URL values

The .env file is where the migration lives or dies. Open it in File Manager with Edit and update the credentials and URL block. The database keys come first:

DB_CONNECTION=mysql
DB_HOST=localhost
DB_PORT=3306
DB_DATABASE=newuser_shopdb
DB_USERNAME=newuser_shop
DB_PASSWORD=your-new-password

On our shared platform the database host is always localhost, not a remote IP, so leave that unchanged regardless of what the old server used. Next, correct the application URL, which Active eCommerce reads for asset generation and absolute links:

APP_URL=https://newdomain.com
APP_ENV=production
APP_DEBUG=false

Set APP_DEBUG to false for the live site, but flip it to true temporarily if you need to read a real stack trace during troubleshooting. Active eCommerce also stores its canonical URL inside the database, so the .env change alone is not sufficient. In phpMyAdmin open the business_settings table and locate rows where type matches values such as site_url or base_url depending on your release, then edit the value column to the new domain. Run a careful search for the old hostname across text fields rather than guessing:

SELECT * FROM business_settings WHERE value LIKE '%olddomain.com%';

Review each match before changing it, then update them individually or with a targeted statement scoped to that table. Uploaded media paths stored in the uploads table are usually relative, so they survive a domain change untouched; if you also moved the storage folder to a different subpath, verify a few file_name entries resolve under /public/uploads. The approach mirrors other Laravel-based platforms, and our Perfex CRM migration guide covers the same database-plus-env rebase pattern if you want a second reference point.

Clearing cache, fixing permissions, and the document root

Laravel caches configuration and routes into bootstrap/cache and storage/framework. A migrated install frequently serves the old APP_URL from these cached files even after you edit .env. Without SSH you clear them by deleting the cached artifacts manually in File Manager: remove config.php, routes-v7.php, and any *.php files inside bootstrap/cache (leave the .gitignore), and empty the subfolders under storage/framework/cache, storage/framework/sessions, and storage/framework/views. On the next request the framework regenerates them from your new environment values.

Permissions matter because the file owner changes during a cross-account move. The storage and bootstrap/cache directories must be writable; set them to 755 through File Manager's Change Permissions dialog, applied recursively. Files should be 644. If image uploads fail after migration, this is almost always the cause, and it reads in the local storage/logs/laravel.log as a permission-denied write.

When the document root differs between accounts, point the web server at Active eCommerce's public folder rather than moving files around. If the application body sits above the web root, a .htaccess in the domain's root can rewrite into public:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/public/
RewriteRule ^(.*)$ /public/$1 [L]

Cleaner still is to set the domain's document root directly to the public directory in cPanel under Domains (or DirectAdmin's domain settings), which keeps the application source outside the web-accessible tree. After everything is wired, load the storefront, then the admin login at /admin, and confirm the browser never redirects back to the old hostname. Check storage/logs/laravel.log for residual errors, re-save a setting inside the admin Business Settings → General panel to force a fresh write, and the migrated store is live on its new address.