How to Migrate a Magento Store to a New Host

Why Magento Migrations Are Trickier

Migrate a Magento store in four steps: back up code, database and media; restore on the new host; update base URLs and reindex; test, secure and cut DNS over. The spine:

1. Backup — mysqldump with --single-transaction, the full application tree, and pub/media via rsync.
2. Restore — import the dump, restore code with Magento-correct ownership, place env.php with new credentials.
3. Reindex — update core_config_data base URLs if they changed, run indexer:reindex and cache:flush.
4. Cutover — test via hosts-file override, issue SSL, verify cron, then switch DNS in a low-traffic window.

Magento is version- and dependency-sensitive — read the pre-migration checklist before touching anything, and keep a rollback plan first-class. WebJi®'s Magento team runs this sequence daily if you would rather delegate.

Pre-Migration Checklist

Before touching anything, document:

• Versions: Magento edition and version (1.x versus 2.x is a different universe), PHP version in use and required, database engine version, the Elasticsearch/OpenSearch dependency, composer setup.

• Extensions and theme: every third-party module with its version — the migration's fragile cargo; validate each against the new environment.

• Data sizing: full database size, media/gallery size (often the biggest artefact), var/ directory excluded — it regenerates fresh.

• Destination pre-build: matching or newer PHP with required extensions, the search engine, cron entries staged.

• Cutover plan: maintenance window chosen from order analytics (typically pre-dawn), stakeholders informed, DNS TTLs dropped in advance.

Backups for the window itself follow the 3-2-1 rule.

Step 1: Backup Code, Database and Media

Step one, backup the three components. Code: the full application directory — for Magento 2 the composer-installed tree including vendor, app/code customisations and config (composer.json and auth for reproducibility; exclude var/cache and generated where size demands). Database: mysqldump with single-transaction consistency — Magento's write volume makes a naive dump risk capturing half a transaction; include triggers and routines if customised.

Media: the product-image directories (pub/media on Magento 2) — often gigabytes; rsync handles them efficiently server-to-server, and a second delta pass at cutover catches uploads since the first copy. Take backups while the store trades normally, verify each dump imports into a scratch database. A backup you have not restored is a rumour — and stage all three artefacts on the destination before touching anything else.

Step 2: Restore on the New Host

How this plays out with base URL updates (core_config_data): settings that look cosmetic usually decide page speed and uptime under real traffic. The defaults WebJi® ships are tuned for Indian network conditions, and support can review your setup on request.

Step 3: Update Base URLs and Reindex

Update Base URLs and Reindex. Do this on one site or a staging copy first, then check the public URL in a private window so cache does not hide the result. Stop if the page errors, and email support@webji.services with the step name and the exact error before you repeat it on every account. WebJi® support mail is staffed 24/7 in Hindi and English; the phone line +91 141 4941811 is business hours only.

Step 4: Test, SSL and DNS Cutover

Step four, test, secure and cut over. Testing in staging configuration. A hosts-file override points your domain at the new server; then traverse the store as a customer. Check catalogue and search, product pages, cart, checkout through a test payment, customer login with an existing account, order history, and admin functions including order creation.

SSL: certificates issued on the new environment (Let's Encrypt included with WebJi® hosting, or migrated commercial certificates) and full-page HTTPS verified, including mixed-content checks on product pages. Cron verification: jobs firing on schedule — abandoned-cart emails, indexing, sitemap generation. Only then: lower TTLs, switch DNS in the low-traffic window, and keep the old server warm for a week.