Migrate a Magento Store to a New Host

What a Magento server move actually copies

Migrating a Magento store to a new host means copying four things to the new server — the database, pub/media, the code with its composer dependencies, and app/etc/env.php — then switching the domain once the store loads and completes a test order there. The Magento version never changes. This is a server move, not the Magento 1 to Magento 2 upgrade that most guides describe.

• Database — products, customers, orders, CMS pages and all configuration in core_config_data.
• pub/media — product images, category images, downloadable files and invoices already generated.
• Code — app/code custom modules and composer.json with composer.lock, so the same package versions install.
• app/etc/env.php — database credentials, cache hosts and the crypt key. Without that key, stored passwords and sessions break.

If the store is still on Magento 1 and the goal is Magento 2, the job is a rebuild with a data migration tool. Do not drag those files onto a new server and expect them to run.

What the new server needs before you start

Provision the destination first and confirm each service answers, because a missing PHP extension surfaces as a blank page after the copy.

Disk space must exceed the old account's public_html plus the database, because rsync needs room for both the copy and the generated static files.

Move the database and files in this order

Freeze writes before you copy, or the database and media drift apart and the store shows products whose images are missing. Run these steps in the listed order over SSH.

1. On the old server, from the Magento root: bin/magento maintenance:enable and stop the cron entry so no new order lands mid-copy.
2. Dump the database in one transaction: mysqldump --single-transaction --quick --routines --triggers -u USER -p DBNAME > db.sql.
3. Copy the files with rsync, which resumes if the link drops: rsync -avz --progress /home/OLD/public_html/ NEWIP:/home/NEW/public_html/.
4. On the new server, create the empty database and import: mysql -u USER -p DBNAME < db.sql.
5. Confirm app/etc/env.php came across with the original crypt key, then set ownership and permissions: chown -R NEW:NEW . and find var generated pub/static pub/media app/etc -type f -exec chmod g+w {} +.
6. Run the Magento setup commands: bin/magento setup:upgrade, bin/magento setup:di:compile, bin/magento setup:static-content:deploy -f, then bin/magento cache:flush and bin/magento indexer:reindex.

If both accounts sit on cPanel servers you control, WHM, then Transfers, then Transfer Tool copies the account with its databases and email in one pass. It does not install OpenSearch or Redis, so steps 1 and 2 of the table above still apply.

Point Magento at a temporary URL

Do not test on the live domain. Add a temporary hostname such as new.yourdomain.in, point it at the new server IP, and change the two base URL rows before you open it.

1. Read the current values: SELECT path, value FROM core_config_data WHERE path LIKE 'web%base_url';
2. Update both rows to the temporary hostname: UPDATE core_config_data SET value='https://new.yourdomain.in/' WHERE path IN ('web/unsecure/base_url','web/secure/base_url');
3. Delete any row for web/cookie/cookie_domain so the browser accepts the temporary host, then run bin/magento cache:flush.
4. Issue a certificate for the temporary host and load the homepage, a product page, the cart and the admin login.

You know the copy worked when a product image loads, add to cart returns a cart line, and the admin grid shows the same order count as the old server.

Switch DNS and verify the store

Lower the domain's TTL to 300 seconds a day before cutover, so a mistake is undone in five minutes instead of hours. Then change the A record to the new IP and put the real base URLs back in core_config_data.

1. Confirm propagation with dig +short yourdomain.in returning the new IP, and clear the Magento cache again.
2. Load the homepage, a category, a product, the cart and checkout on the live domain over HTTPS.
3. Place one real order with a low-value product, then refund it. An order that reaches the success page proves the payment, mail and database path together.
4. Check bin/magento cron:run in the crontab and confirm the schedule table gets new rows within five minutes.
5. Watch the new server's error log for an hour, then raise the TTL back to its normal value.

Roll back if the new server fails

Keep the old account and its DNS entry untouched for seven days. A rollback is a DNS change: point the A record back to the old IP, restore the old TTL, and take the new server out of the pool.

Orders placed after cutover exist only on the new database. Before you revert, export them from sales_order and the related invoice and shipment tables, or copy the whole new database over the old one if nothing else changed there. Keep the new server running read-only until that export is verified.

The three failures that stop a Magento move

A blank page or 500 right after the import is almost always the PHP version or a missing extension. Read var/log/exception.log and the PHP error log, install the extension named there, and rerun setup:di:compile.

An empty cart that refills on every page load means Redis is pointing at the old host. Open app/etc/env.php, correct the cache and session host, and flush Redis on the new machine.

Missing product images after a successful copy are a permission or symlink problem: confirm pub/media is owned by the site user, then rerun bin/magento catalog:images:resize for the affected products.

Magento hosting and migration on WebJi®

WebJi® quotes Magento hosting by email before payment, because the right PHP version, database size and search engine depend on the catalogue. Send the current disk usage, order count and Magento version to support@webji.services and the desk replies with a written configuration and price.

Migration is free subject to terms and approval: support moves the database, media and code, then hands over a staging URL for you to test before DNS changes. It does not include theme work or extension rewrites. The plans sit on Magento hosting, and a one-off move without hosting is on the website migration service page. For a large catalogue, add a VPS server for OpenSearch, or write to the contact page.