Migrating a store

Migrations are done together, by hand, with the person who built this platform. There is no self-serve import wizard, and that is deliberate: every Magento store has something odd about it — a patched core module, a 40 GB media directory, a third-party search integration — and a wizard that gets that wrong takes a shop offline.

Write to [email protected] and we will schedule it.

The shape of it

Your current host keeps serving customers the entire time. Nothing moves until you have seen the store working on Nautvia and said so.

1. Set the store up on Nautvia — repository connected, infrastructure attached, your real branch deployed. See Quickstart.
2. Import the database. You export from your current host, we import it into your new database.
3. Sync the media. pub/media copies onto its own volume.
4. Test on a temporary hostname. Your store runs at something.apps.nautvia.com, with real data, while the old site is still live.
5. Re-sync just before the cutover. A second, short database import catches the orders placed while you were testing.
6. Move DNS. You change the A record. Traffic drains from the old host as caches expire.

What we need from you

• A database dump. mysqldump --single-transaction --quick --routines --triggers, gzipped. If it is under 5 GB you can upload it yourself from the Backups tab — see Backups and restores. Larger than that, we handle it over SSH.
• Your pub/media directory, by rsync or as an archive.
• Repository access, and your repo.magento.com keys if the store uses paid Adobe modules.
• Your current DNS provider, and confirmation of who can change records there.
• A list of anything unusual: cron jobs outside Magento's own, custom nginx rules, IP allowlists, payment or ERP integrations that whitelist your current server's IP.

That last one matters more than it sounds. Your IP address changes. Any integration that allowlists your current server has to be told the new address before cutover, not after.

Lower your TTL first

A week before the move, drop the TTL on your store's DNS record to 300 seconds. If you cut over while the record is still cached for a day, some customers keep landing on the old server long after the new one is live — and orders placed there are orders you have to reconcile by hand.

What does not come across automatically

• Sessions and cart contents. Logged-in customers are logged out at cutover. Schedule it for your quietest hour.
• Cron state. Nautvia writes its own crontab entry running bin/magento cron:run. Any cron job you had outside Magento needs re-creating.
• Server-level tweaks. Custom nginx directives, PHP ini overrides and firewall rules do not travel with the database.
• Your old backups. They stay with your old host. Take a copy before you cancel that account.

After the cutover

Keep the old hosting account alive for a week. It costs one more month at most, and it is the only real rollback you have if something surfaces that testing missed — Nautvia's own rollbacks restore code, not the database.