Migrate a Magento Store to a New Host
Migrate a Magento store by reproducing its exact supported stack, transferring the database, media, code and environment configuration, then testing a protected destination before cutover. Coordinate all writers, cron and consumers so data stays consistent. Preserve the crypt key and a recovery plan; DNS rollback alone cannot safely reconcile orders and payments created after the move.
For store administrators moving an unchanged Magento release, with release-specific requirements, transaction-preserving cutover and a recovery plan beyond changing DNS.
knowledge
- Read time
- 5 min
- Sections
- 8
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026.
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 — preserve the crypt key and update environment-specific endpoints. The key protects encrypted stored configuration; it is not a substitute for migrating database password hashes or validating sessions.
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.
| Component | Verify |
|---|---|
| PHP and extensions | The release’s supported versions and actual CLI/web runtime |
| Database | Supported engine/version, collation and restore compatibility |
| Search | The release’s supported OpenSearch or Elasticsearch dependency |
| Cache, sessions and queues | Actual supported services, private endpoints and configuration |
| Composer and scheduled work | Locked dependencies, cron and consumer restart plan |
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.
Check Adobe’s release-specific system requirements and preserve a tested backup and recovery procedure before changing the destination stack.
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.
- Enable maintenance mode under the approved cutover plan and stop cron, message consumers and other external writers. Maintenance mode alone does not make every source of writes disappear.
- Dump the database in one transaction:
mysqldump --single-transaction --quick --routines --triggers -u USER -p DBNAME > db.sql. - Copy the files with rsync, which resumes if the link drops:
rsync -avz --progress /home/OLD/public_html/ NEWIP:/home/NEW/public_html/. - On the new server, create the empty database and import:
mysql -u USER -p DBNAME < db.sql. - Preserve the original crypt key, then check the intended filesystem owner and deployment permissions. Correct only identified paths using the release’s documented model, not a blanket recursive permission command.
- Use the exact release’s deployment procedure for configuration, compilation, static assets, caches and indexes. An unchanged host move is not automatically a schema upgrade; review any setup:upgrade operation before it modifies the database.
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.
- Read the current values:
SELECT path, value FROM core_config_data WHERE path LIKE 'web%base_url'; - 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'); - Delete any row for web/cookie/cookie_domain so the browser accepts the temporary host, then run
bin/magento cache:flush. - 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
Plan a lower DNS TTL far enough ahead for the previous cached TTL to expire, then test the destination before cutover. A 300-second example does not guarantee worldwide convergence or a five-minute rollback. Reconcile base URLs and keep the old service recoverable.
- Confirm propagation with
dig +short yourdomain.inreturning the new IP, and clear the Magento cache again. - Load the homepage, a category, a product, the cart and checkout on the live domain over HTTPS.
- Use an authorised test transaction or payment sandbox and verify order, payment, email and stock handling individually. A success page alone does not prove each integration worked; do not create live charges without approval.
- Restart and inspect cron and message consumers under the actual scheduler configuration, then verify relevant scheduled jobs and logs rather than assuming a fixed five-minute result.
- 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
A Magento rollback is an application-and-data recovery decision, not merely pointing DNS back. Preserve both environments, stop conflicting writes and decide which data set is authoritative before reverting traffic.
Orders, invoices, payments, stock and related entities can change after cutover. Do not merge a few sales tables or overwrite a database blindly. Use a reviewed reconciliation or recovery procedure, preserve current snapshots and verify payment records before reopening writes.
The three failures that stop a Magento move
Inspect Magento and PHP logs for a blank page or HTTP 500; version, extension, compilation, permissions and application errors are candidates, not a diagnosis from the symptom alone.
A cart or session failure needs inspection of cookie settings, session storage, application configuration and logs. Do not flush a shared Redis instance or assume one upstream host is the cause without evidence.
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
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.
Frequently asked questions
How do I migrate a Magento store to a new host?
Enable maintenance mode, dump the database, rsync the files including pub/media and app/etc/env.php, import the database on the new server, run setup:upgrade and reindex, test on a temporary hostname, then switch DNS. The store version stays the same.
Is a host move the same as upgrading Magento 1 to 2?
No. A host move copies an unchanged store to a different server. A Magento 1 to 2 upgrade rebuilds the store on a new codebase and needs a data migration tool. Doing both at once doubles the failure points, so finish the host move first.
Will migration affect my orders and customers?
The database carries existing orders and customer data, but writes during copying or after cutover need a defined reconciliation plan. Maintenance mode, cron, consumers and external integrations must be considered together. Do not reopen two writable copies or roll back DNS without protecting newer transactions.
How long does a Magento migration take?
Duration depends on media size, database volume, dependencies, access and validation. No measured migration window is established here. Agree an approved cutover plan, preserve recovery options and complete a staging rehearsal before making a time commitment for the live store.
What must be reconfigured after moving the host?
The two base URL rows in core_config_data, the Redis host in app/etc/env.php, the OpenSearch endpoint, the system crontab entry and the SSL certificate. Reindex and flush the cache after each change.
Why does my store show a blank page after the move?
A blank page is usually a PHP version mismatch, a missing extension or a failed compile. Read var/log/exception.log and the PHP error log, install what the log names, then rerun setup:di:compile and flush the cache.
Last editorial update: 14 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.