How to Migrate Magento to a New Server

Migrating a Magento store to a new server may be necessary when your existing hosting environment no longer provides enough CPU, RAM, storage, performance, or reliability. A migration can also be useful when moving to a better hosting provider, upgrading server hardware, changing operating systems, or moving from shared hosting to a VPS or dedicated server.

A Magento migration involves more than copying website files. You need to move the database, media files, configuration, Composer dependencies, custom code, and server environment while keeping the store functional.

In this guide, you will learn how to migrate Magento to a new server safely, test the new environment, switch the domain, and minimize downtime.

What Is a Magento Server Migration?

A Magento server migration means moving an existing Magento installation from one hosting server to another.

A typical migration looks like this:

Old Server
    |
    |  Magento Files
    |  Database
    |  Media
    |  Configuration
    ↓
New Server
    |
    ↓
Testing
    |
    ↓
DNS / Domain Switch
    |
    ↓
Live Magento Store

The goal is to move the complete application without losing products, customers, orders, configurations, or media.

---

Why Move Magento to a New Server?

Common reasons include:

• Better server performance
• More CPU and RAM
• Faster storage
• Improved network connectivity
• Better security
• Higher PHP limits
• Better database performance
• More reliable backups
• Improved server monitoring
• Scalability for growing traffic
• Moving to a Magento-optimized hosting environment

A properly planned migration can improve both store performance and reliability.

---

What You Need Before Starting

Before migrating Magento, make sure you have access to both servers.

You should have:

• SSH access to the old server
• SSH access to the new server
• Magento administrator access
• Database credentials
• Domain/DNS access
• Access to the Magento files
• Composer access
• Appropriate PHP version
• MySQL/MariaDB access
• Required PHP extensions
• A recent backup

For a production store, it is strongly recommended to test the migration on a staging environment first.

---

Step 1: Check Your Current Magento Environment

Before moving anything, document your existing environment.

Check the Magento version:

php bin/magento --version

Check PHP:

php -v

Check Composer:

composer --version

Check enabled Magento modules:

php bin/magento module:status

Check indexer status:

php bin/magento indexer:status

Also record:

• PHP version
• Web server
• Database version
• Magento version
• Installed extensions
• Cron configuration
• SSL configuration
• Redis configuration
• Search service configuration
• CDN configuration
• Custom modules
• Custom themes

This information makes it easier to reproduce the existing environment on the new server.

---

Step 2: Prepare the New Server

Do not copy Magento files to an unprepared server.

Install and configure the required software first.

Depending on your Magento version, this may include:

• Linux
• Nginx or Apache
• PHP
• PHP-FPM
• MySQL or MariaDB
• Composer
• Elasticsearch or OpenSearch where required
• Redis
• SSL
• Cron
• Required PHP extensions

The exact software versions must match the requirements of your Magento release.

Check PHP modules with:

php -m

Compare the output with the old server.

---

Step 3: Create a Full Backup

Before migration, create a complete backup of the existing store.

Back up:

• Magento files
• Database
• pub/media
• Custom code
• Themes
• Configuration
• Composer files

A database backup can be created using:

mysqldump -u DB_USER -p DATABASE_NAME > magento.sql

For compression:

mysqldump -u DB_USER -p DATABASE_NAME | gzip > magento.sql.gz

Keep the backup until the new server has been completely tested.

---

Step 4: Enable Maintenance Mode

For the final migration, enable Magento maintenance mode so that customers do not place orders while the final database and file changes are being transferred.

Run:

php bin/magento maintenance:enable

Check the status:

php bin/magento maintenance:status

For a large store, you can perform most of the migration before maintenance mode and only use a short maintenance window for the final synchronization.

---

Step 5: Put the Old Store in a Consistent State

Before creating the final database backup:

php bin/magento cache:flush

Check indexers:

php bin/magento indexer:status

If necessary, run:

php bin/magento indexer:reindex

The goal is to start the final migration from a clean and consistent application state.

---

Step 6: Export the Magento Database

On the old server, export the Magento database:

mysqldump -u DB_USER -p DATABASE_NAME > magento.sql

For larger databases:

mysqldump -u DB_USER -p DATABASE_NAME | gzip > magento.sql.gz

Verify that the backup file exists:

ls -lh magento.sql.gz

Do not delete the original database until the migration has been successfully completed and verified.

---

Step 7: Transfer Magento Files

Copy the required Magento files from the old server to the new server.

A common method is rsync:

rsync -avz /path/to/magento/ user@NEW_SERVER:/path/to/magento/

For large media directories, rsync is particularly useful because it can synchronize only changed files during subsequent transfers.

For example:

rsync -avz pub/media/ user@NEW_SERVER:/path/to/magento/pub/media/

You can also use SFTP or another secure transfer method.

---

Step 8: Transfer the Database

Copy the database backup to the new server:

scp magento.sql.gz user@NEW_SERVER:/home/user/

Then extract it:

gunzip magento.sql.gz

You should now have:

magento.sql

---

Step 9: Create the Magento Database on the New Server

Log in to MySQL or MariaDB:

mysql -u root -p

Create a database:

CREATE DATABASE magento;

Create a dedicated database user:

CREATE USER 'magento_user'@'localhost' IDENTIFIED BY 'STRONG_PASSWORD';

Grant the required privileges:

GRANT ALL PRIVILEGES ON magento.* TO 'magento_user'@'localhost';

Then:

FLUSH PRIVILEGES;

Use a strong database password and avoid using the root database account for Magento.

---

Step 10: Import the Database

Import the backup:

mysql -u magento_user -p magento < magento.sql

For large databases, monitor the process and make sure the command finishes without errors.

After importing, verify that tables exist:

mysql -u magento_user -p magento

Then:

SHOW TABLES;

You should see Magento tables.

---

Step 11: Configure Magento’s Database Connection

Magento stores environment-specific database configuration in:

app/etc/env.php

Open the file:

nano app/etc/env.php

Locate the database configuration.

It may look similar to:

'db' => [
    'connection' => [
        'indexer' => [
            'host' => 'localhost',
            'dbname' => 'magento',
            'username' => 'magento_user',
            'password' => 'STRONG_PASSWORD'
        ],
        'default' => [
            'host' => 'localhost',
            'dbname' => 'magento',
            'username' => 'magento_user',
            'password' => 'STRONG_PASSWORD'
        ]
    ]
],

Update the values to match the new server.

Do not expose env.php publicly because it contains sensitive configuration.

---

Step 12: Verify the Base URLs

If the domain is staying the same, Magento’s base URLs may not need to change.

Check the current values:

php bin/magento config:show web/unsecure/base_url

and:

php bin/magento config:show web/secure/base_url

If the domain is changing, update the URLs accordingly.

For example:

php bin/magento setup:store-config:set --base-url="https://new-example.com/"

and:

php bin/magento setup:store-config:set --base-url-secure="https://new-example.com/"

Then flush the cache:

php bin/magento cache:flush

---

Step 13: Install Magento Dependencies

If vendor/ is not being transferred as part of your deployment, install Magento’s Composer dependencies on the new server.

From the Magento root:

composer install

For production environments, a deployment commonly uses:

composer install --no-dev

The exact Composer workflow should follow your project’s deployment configuration.

Do not run arbitrary dependency upgrades during a server migration unless you intentionally want to change software versions.

A migration should normally reproduce the existing application environment rather than unexpectedly upgrading it.

---

Step 14: Set Correct File Ownership and Permissions

Make sure the web server can access Magento files.

Check ownership:

ls -la

Do not use overly permissive settings such as:

chmod -R 777 .

This can create serious security problems.

Use the ownership and permissions recommended for your web server and Magento deployment architecture.

---

Step 15: Configure Magento Cron

Magento requires scheduled tasks for many background operations.

Check existing cron jobs on the old server:

crontab -l

Then configure the required Magento cron jobs on the new server.

A typical Magento cron configuration uses:

php /path/to/magento/bin/magento cron:run

You may need separate cron entries depending on your Magento version and deployment setup.

After migration, verify that cron is actually executing rather than simply existing in the crontab.

---

Step 16: Configure PHP-FPM

If the new server uses PHP-FPM, verify:

• PHP version
• PHP-FPM service
• Worker configuration
• Memory limits
• Maximum execution time
• Upload limits
• OPcache
• Required extensions

Check PHP:

php -v

Check PHP-FPM according to your operating system’s service manager.

Magento performance can be heavily affected by PHP-FPM configuration, especially on busy stores.

---

Step 17: Configure Redis if Used

If the old Magento installation uses Redis for caching or sessions, configure the new server accordingly.

Magento’s Redis configuration may be stored in:

app/etc/env.php

Check whether the old server contains Redis configuration before migration.

Make sure:

• Redis is installed
• Redis is running
• Magento can connect to it
• Authentication is configured if required
• Redis is not unnecessarily exposed to the public internet

---

Step 18: Configure the Search Service

Magento installations may use Elasticsearch or OpenSearch depending on the Magento version and environment.

Check the existing configuration before migration.

Verify that the required search service is:

• Installed
• Running
• Accessible by Magento
• Configured with the correct host and port

After migration, test product search carefully.

A store may appear to work normally while catalog search is broken.

---

Step 19: Configure the Web Server

Configure Apache or Nginx for the new Magento installation.

The web server must point to Magento’s pub directory rather than exposing the entire Magento root.

For example:

Magento root:
 /var/www/magento

Web root:
 /var/www/magento/pub

Configure:

• HTTPS
• Rewrite rules
• PHP-FPM
• Static files
• Compression
• Security headers
• Request limits
• Error logging

Follow the web server configuration appropriate for your Magento version.

---

Step 20: Install the SSL Certificate

Before switching the domain, make sure HTTPS works on the new server.

Test:

https://example.com

Check:

• Certificate validity
• Certificate chain
• HTTPS redirect
• Mixed content
• TLS configuration

If you are using a CDN or reverse proxy, verify the SSL mode and origin configuration as well.

---

Step 21: Test the New Server Without Changing DNS

This is one of the most important migration steps.

Do not immediately point your live domain to the new server.

Instead, test the new server using a temporary hostname, local hosts-file entry, staging domain, or another controlled method.

For example, you can temporarily map:

203.0.113.50 example.com

in your local hosts file.

This allows you to test the new server while public DNS still points to the old server.

---

Step 22: Run Magento Commands on the New Server

From the Magento root, run the necessary deployment commands.

For example:

php bin/magento setup:upgrade

Then:

php bin/magento cache:flush

If required:

php bin/magento setup:di:compile

And:

php bin/magento setup:static-content:deploy -f

Reindex if necessary:

php bin/magento indexer:reindex

Check indexer status:

php bin/magento indexer:status

---

Step 23: Test the Magento Store

Before changing DNS, thoroughly test the new server.

Check the storefront:

• Homepage
• Categories
• Product pages
• Search
• Product images
• Customer registration
• Customer login
• Cart
• Checkout
• Coupons
• Shipping
• Taxes
• Payment methods

Then test the Admin Panel:

• Login
• Dashboard
• Products
• Categories
• Orders
• Customers
• Configuration
• Extensions
• Reports

Do not skip checkout testing.

A migration can appear successful while payment or shipping integrations are broken.

---

Step 24: Perform the Final Synchronization

Once the new server has been thoroughly tested, prepare for the final cutover.

A low-downtime migration can follow this sequence:

Initial file transfer
        ↓
Initial database copy
        ↓
Configure new server
        ↓
Test new server
        ↓
Enable maintenance mode
        ↓
Final database backup
        ↓
Final file synchronization
        ↓
Final testing
        ↓
Change DNS
        ↓
New server becomes live

Using rsync for the final file synchronization can reduce the amount of data that needs to be transferred during the maintenance window.

---

Step 25: Change DNS

Once the new server is ready, update the domain’s DNS records.

For example:

example.com → NEW_SERVER_IP

and, if applicable:

www.example.com → NEW_SERVER_IP

DNS propagation can take time depending on TTL values and caching.

Keep the old server available during the transition rather than shutting it down immediately.

---

Step 26: Monitor DNS Propagation

After changing DNS, verify that traffic is reaching the new server.

You can check DNS resolution with:

dig example.com

or:

nslookup example.com

Check from multiple networks if possible.

During the transition, some visitors may still reach the old server because of DNS caching.

---

Step 27: Monitor the New Server

After the domain starts pointing to the new server, monitor:

• CPU usage
• RAM usage
• Disk usage
• PHP-FPM
• Database
• Redis
• Search service
• Magento logs
• Web server logs
• Checkout
• Payment processing
• Cron
• Email delivery

Pay particular attention to customer orders immediately after the migration.

---

Step 28: Keep the Old Server Temporarily

Do not delete the old server immediately.

Keep it available until:

• DNS has fully transitioned
• Orders are working
• Customers can log in
• Payments are working
• Cron is functioning
• Emails are working
• No critical errors are appearing

Once the new environment has been stable for an appropriate period and your backups are verified, you can safely retire the old server.

---

Common Magento Migration Problems

Database Connection Error

If Magento reports a database connection problem, check:

Database hostname
Database name
Database username
Database password
Database server status

Review:

app/etc/env.php

---

CSS or JavaScript Is Missing

Clear Magento cache:

php bin/magento cache:flush

If necessary, deploy static content:

php bin/magento setup:static-content:deploy -f

Also verify web-server permissions and the pub/static configuration.

---

Product Images Are Missing

Check whether:

pub/media/

was transferred completely.

Also verify ownership and permissions.

---

Admin Login Does Not Work

Check:

• Admin URL
• Database connection
• HTTPS
• Cookies
• Base URLs
• Custom Admin path
• Cache

If you previously changed the Magento Admin URL, make sure the same configuration exists on the new server.

---

Magento Shows a 500 Error

Check:

var/log/

and the web server/PHP-FPM logs.

A 500 error can be caused by:

• PHP incompatibility
• Missing PHP extensions
• File permissions
• Dependency problems
• Configuration errors
• Extension conflicts
• Memory limits

---

Search Does Not Work

Check your Elasticsearch/OpenSearch configuration and make sure the required service is running.

Then run:

php bin/magento indexer:reindex

Test product search again.

---

Cron Is Not Running

Check:

crontab -l

Then verify that the Magento cron command is using the correct PHP binary and Magento path.

---

Emails Are Not Being Sent

Check:

• SMTP configuration
• PHP mail configuration
• SMTP credentials
• DNS records
• SPF
• DKIM
• DMARC
• Firewall rules

Do not assume that email configuration automatically moves with the website.

---

How to Minimize Magento Migration Downtime

For a busy Magento store, downtime should be as short as possible.

Use a staged migration:

Phase 1 — Copy

Transfer the Magento files and database while the old store remains online.

Phase 2 — Configure

Prepare the new server completely.

Phase 3 — Test

Test the new environment without changing public DNS.

Phase 4 — Freeze

Put the old store into maintenance mode.

Phase 5 — Synchronize

Transfer the final database and changed files.

Phase 6 — Switch

Update DNS.

Phase 7 — Monitor

Watch the new server and store carefully.

This approach can reduce the final downtime to a short maintenance window.

---

Magento Migration Checklist

Before Migration

• Record Magento version
• Record PHP version
• Record database version
• Record installed extensions
• Back up Magento files
• Back up the database
• Verify backups
• Prepare the new server
• Install required PHP extensions
• Configure the database
• Configure PHP-FPM
• Configure Redis if required
• Configure Elasticsearch/OpenSearch if required
• Configure the web server
• Install SSL

During Migration

• Transfer Magento files
• Transfer pub/media
• Import the database
• Configure app/etc/env.php
• Install Composer dependencies
• Configure cron
• Set permissions
• Run setup:upgrade
• Flush cache
• Compile if required
• Deploy static content if required
• Reindex
• Test the new server

Final Cutover

• Enable maintenance mode
• Create final database backup
• Perform final synchronization
• Verify the new server
• Update DNS
• Monitor DNS propagation
• Test checkout
• Test payments
• Test orders
• Monitor server logs
• Keep the old server temporarily

---

Final Thoughts

Migrating Magento to a new server requires careful planning because the store consists of much more than website files. The database, media, configuration, Composer dependencies, PHP environment, search service, cache, cron jobs, SSL, and web-server configuration all need to work together.

The safest approach is to prepare the new server first, create verified backups, copy the store, test everything before changing DNS, perform a final synchronization, and monitor the new environment after the cutover.

For a busy Magento store, use a staged migration and a short final maintenance window to minimize downtime. Never shut down the old server immediately after changing DNS; keep it available until the new environment has been fully verified and your recovery backups are secure.