Moving an OpenCart website to another hosting: instructions

Typical scenario: files uploaded, database imported, you enter the domain and see a white screen. Or the homepage opens, but without any images, and the admin panel returns a 500 error. The process of migrating OpenCart itself is not complicated—the store consists of files and a single MySQL database. Problems almost always hide in two config files and in small details that get mentioned only after the move.

What exactly we're moving

Two things: all files from the site root and a database dump. Nothing else. Standard OpenCart has no licenses, server bindings, or hidden dependencies. Paid modules are another matter: each is licensed differently—somewhere tied to the domain, somewhere to the server, sometimes not tied at all. If you have such modules, contact each developer before the migration and clarify whether you need to re-register the license. This is individual for each module; there's no universal rule here.

Before starting, record the versions on the old server: the OpenCart version (visible in the admin panel footer) and the PHP version (simply a file with phpinfo()). The second number is critical: migrating from, say, PHP 7.4 to 8.1 along with changing hosting turns problem-finding into a lottery. You won't understand what broke: the server, the config, or an incompatible module. First migrate to the same PHP version, and only then, in the new location, experiment with upgrading.

Step 1. Backups

It's more convenient to pack files into an archive on the server rather than pulling 40 thousand small files over FTP. If you have SSH:

tar -czf shop-files.tar.gz -C /var/www/mysite/public_html .
mysqldump -u db_user -p db_name > shop-db.sql

Without SSH, use phpMyAdmin for the database and an archiver in the file manager of your panel. On a large database, phpMyAdmin may cut off the export due to timeout; then ask your hosting support to make the dump or use a script like Sypex Dumper.

Make backups before any actions and don't delete the old site until the new one has been working for at least a week.

Step 2. Files and database on the new server

Unpack the archive to the site root, create a new database and user in the panel, import the dump. There's one catch here: encoding. If the old database was in utf8 and the new one was created as utf8mb4 (or vice versa), Cyrillic text may turn into question marks after import. Check the encoding of the dump in the first lines of the file and create the database with the same encoding.

Step 3. config.php and admin/config.php

This is where most white screens are hidden. There's a config.php in the root, another identical one in the admin folder, and you need to edit both. Inside there are two blocks: paths to folders and database access credentials.

Incorrect (paths left from the old server):

define('DIR_APPLICATION', '/home/olduser/public_html/catalog/');
define('DB_USERNAME', 'olduser_shop');

Correct (current path and new credentials):

define('DIR_APPLICATION', '/var/www/mysite/public_html/catalog/');
define('DB_USERNAME', 'newuser_shop');

The full path to the root on the new server will be provided by the panel or the pwd command in the appropriate folder. In admin/config.php there are more paths—DIR_CATALOG and HTTP_CATALOG are specified separately; don't miss them. In OpenCart 3.x, also pay attention to DIR_STORAGE: if the storage folder was moved outside public_html on the old server (the engine itself suggests this), on the new one it should be placed the same way and the correct path should be specified.

If the site goes silent after editing the configs, don't guess. Open system/storage/logs/error.log or the PHP log in the panel: it will show the exact file and line—usually it's an incomplete path or an old database password.

Step 4. Permissions and PHP

On most hosting services, 755 for folders and 644 for files is sufficient; you don't need to set 777—it doesn't fix the problem, it only opens a hole.

Check the PHP version and limits in the panel: max_input_vars at least 10000 (otherwise large modules and menus won't save), memory_limit at least 256M, upload_max_filesize for your imports. If the store ran on Apache with .htaccess and the new server is on NGINX, the SEO URL rules will need to be rewritten for NGINX format, otherwise all pretty URLs will return 404 while the homepage works just fine.

Step 5. After migration

Go to the admin panel and refresh the modifier cache: Extensions → Modifiers → "Refresh" button. Without this, OCMOD modifications may pick up old cache with foreign paths. In OpenCart 3.x, additionally clear the theme cache and SASS through the gear icon on the admin homepage.

Then walk through the live store: category, product card, search, add to cart, checkout to completion. Separately check email: if the old hosting's SMTP was set up, order confirmation emails will silently stop arriving, and you'll find out from a customer a week later. And look at error.log over the next few days—small migration oversights will appear there.

Switch the domain to the new server after all checks (you can test through the hosts file on your computer). It's worth lowering the TTL of the DNS record to 300–600 seconds in advance; then the switch will take minutes instead of a day.