How to Migrate Magento From cPanel Hosting to Cloudways Step by Step

Migrating a Magento store from traditional cPanel hosting to Cloudways can improve performance, scalability, and server management. The process requires careful preparation because Magento depends on files, databases, cache, cron jobs, SSL, and correct domain routing. A store administrator should treat the migration as a structured project rather than a quick file transfer.

TLDR: A Magento migration from cPanel to Cloudways involves creating a new Cloudways server, backing up the existing store, moving files and the database, updating configuration, testing the site, and switching DNS. The safest approach is to complete the migration on a temporary Cloudways URL before pointing the live domain. After launch, SSL, cache, cron jobs, permissions, and performance settings should be verified.

Step 1: Prepare the Magento Store Before Migration

Before any files are moved, the administrator should review the current Magento installation. This includes checking the Magento version, PHP version, database size, active extensions, custom themes, and disk usage. Cloudways supports modern PHP versions, but the selected server stack must be compatible with the Magento version running on the existing cPanel account.

The administrator should also place the store into a controlled maintenance window if the site receives frequent orders. For Magento 2, maintenance mode can be enabled from the command line. However, many migrations are first performed on a staging copy, allowing the live store to continue operating until the final database sync.

  • Confirm Magento version: Magento 1 and Magento 2 have different configuration paths.
  • Check PHP compatibility: Extensions and themes may require specific PHP versions.
  • Review custom modules: Unsupported modules may break after migration.
  • Record current settings: Base URLs, cron tasks, cache settings, and email configuration should be documented.
Image not found in postmeta

Step 2: Create a Cloudways Server and Application

The next step is to create a new server on Cloudways. The administrator should select a cloud provider, server size, location, and Magento application. For stores with moderate traffic, a server with enough RAM and CPU resources should be chosen, especially because Magento can be resource intensive.

After the server is launched, Cloudways provides application credentials, SSH access, SFTP access, database credentials, and a temporary application URL. This temporary URL is useful for testing before the live domain is pointed to the new server.

It is recommended that the same or a compatible PHP version be selected before importing the Magento files and database. The server settings can usually be adjusted from the Cloudways platform, including PHP, memory limits, upload size, and execution time.

Step 3: Back Up the cPanel Magento Store

A complete backup should be created before migration. The administrator should not rely only on partial backups because Magento stores essential information in both the file system and the database.

The backup should include:

  • Magento files: The full document root, usually located in public_html or a subdirectory.
  • Database: Exported through phpMyAdmin or the cPanel backup tool.
  • Media folder: Product images, category images, and uploaded assets.
  • Configuration files: For Magento 2, app/etc/env.php; for Magento 1, app/etc/local.xml.
  • Email and DNS records: These may be needed after launch.

The database can be exported as a compressed SQL file. For large Magento databases, using SSH and mysqldump is usually more reliable than exporting through a browser-based tool.

Step 4: Transfer Magento Files to Cloudways

Once the backup is ready, the Magento files should be uploaded to the Cloudways application directory. This can be done using SFTP, SCP, or rsync. For large stores, rsync over SSH is often preferred because it can resume transfers and sync only changed files during the final migration phase.

On Cloudways, the application web root is typically inside the application’s public directory. The administrator should ensure that the Magento files are placed in the correct location. If Magento is installed in the wrong directory, the temporary URL may show an empty page or server error.

After uploading files, file permissions should be corrected. Magento requires writable access to directories such as var, generated, pub/static, and pub/media in Magento 2. Permissions should be secure but functional, avoiding overly broad settings whenever possible.

Step 5: Import the Database on Cloudways

The Magento database must then be imported into the Cloudways database. The administrator can use the Cloudways database manager, phpMyAdmin if available, or SSH. For large databases, the command line is usually the most stable option.

After importing the database, the Magento configuration file must be updated with the new database details. In Magento 2, the database connection is stored in:

app/etc/env.php

In Magento 1, it is usually stored in:

app/etc/local.xml

The administrator should update the database host, database name, username, and password according to the credentials shown in the Cloudways application dashboard.

Step 6: Update Magento Base URLs

Magento stores its base URLs in the database. During testing, these values may need to be changed to the Cloudways temporary URL. After the final launch, they should be changed again to the live domain.

For Magento 2, base URLs can be updated using the command line or directly in the database. The administrator should check both secure and unsecure URLs. Incorrect base URLs can cause redirect loops, broken admin access, missing assets, or mixed-content warnings.

After changing URLs, cache should be cleared. Magento 2 commonly requires commands such as cache clean, cache flush, static content deployment, and reindexing. These commands should be run from the Magento root directory.

Step 7: Test the Store on Cloudways

Before DNS is changed, the migrated Magento store should be tested thoroughly. The administrator should use the temporary URL or a local hosts file entry to preview the site with the real domain. Testing with a hosts file can reveal issues that may not appear on a temporary URL.

Important areas to test include:

  1. Homepage and category pages: Layout, images, and navigation should load correctly.
  2. Product pages: Configurable products, images, price rules, and options should function properly.
  3. Cart and checkout: Shipping, tax, payment gateways, and order placement should be verified.
  4. Admin panel: Login, catalog management, order views, and configuration should be checked.
  5. Email delivery: Order confirmation and contact forms should be tested.

If errors appear, the administrator should review Magento logs, server logs, PHP settings, and extension compatibility. Many common migration issues are caused by missing PHP extensions, incorrect permissions, outdated generated files, or old cache data.

Step 8: Configure Cron Jobs, Cache, and SSL

Magento depends heavily on cron jobs for indexing, email, catalog rules, newsletters, and scheduled tasks. The administrator should recreate cron jobs from cPanel inside the Cloudways cron management area. Magento 2 usually requires cron commands that run from the application root using the correct PHP binary.

SSL should also be installed before the final DNS switch or immediately after domain mapping. Cloudways provides an SSL management option, often using a free certificate. Once SSL is active, secure base URLs should use https.

Cache and performance settings should be reviewed as well. Cloudways may provide server-level caching features, while Magento has its own cache system. The administrator should confirm that cache settings do not interfere with cart, checkout, or customer sessions.

Step 9: Point the Domain to Cloudways

When the migrated store has passed testing, the domain can be pointed to Cloudways. The administrator should update DNS records at the domain registrar or DNS provider. Usually, the main A record should point to the Cloudways server IP address. If the store also uses www, the appropriate CNAME or A record should be updated too.

DNS propagation can take time, although many changes are visible within a few hours. During this period, some visitors may reach the old server while others reach the new one. To reduce this risk, the administrator can lower the DNS TTL value before migration and perform a final database sync just before switching.

Step 10: Perform Post-Migration Checks

After launch, the administrator should monitor the store closely. New orders, customer registrations, payment notifications, and admin functions should be checked. Error logs should be reviewed during the first several hours and again after peak traffic periods.

The old cPanel hosting account should not be canceled immediately. Keeping it active for several days provides a safety net in case missed files, email records, or historical backups are needed.

FAQ

How long does a Magento migration from cPanel to Cloudways take?

A small Magento store may be migrated in a few hours, while a large store with many products, custom extensions, and a large database may require a full day or more for transfer, testing, and DNS changes.

Can Magento be migrated without downtime?

Near-zero downtime is possible if the migration is tested on Cloudways first, DNS TTL is lowered in advance, and a final database sync is performed immediately before launch.

Does the database need to be changed after migration?

Yes. The Magento configuration file must be updated with the new Cloudways database credentials, and the Magento base URLs may also need to be updated in the database.

What is the most common migration problem?

Common issues include incorrect file permissions, wrong base URLs, missing PHP extensions, old cache files, and incompatible Magento extensions.

Should the old cPanel hosting account be deleted after migration?

It should be kept active for several days after the Cloudways launch. This gives the administrator time to confirm that all files, orders, emails, and DNS settings are working correctly.