Migrating a store

You can move a store yourself: the database and the encryption key come along, and the store runs on a temporary address next to your current site until you move DNS. Every Magento store has something odd about it — a patched core module, a 40 GB media directory, a third-party search integration — so if you would rather do it together, write to [email protected] and we will schedule it.

Setting it up

1. Create the site and choose "I have a running store". Paste the crypt key from your current app/etc/env.php ('crypt' => ['key' => '…']). Your saved payment, SMTP and integration secrets are encrypted with it; without it they cannot be read. After a key rotation there are several keys, one per line — paste them all.
2. Attach a database, cache and search from the Resources card.
3. Upload your database dump under Backups → Import (.sql or .sql.gz, up to 5 GB). Export it with mysqldump --single-transaction --quick --routines --triggers. DEFINER clauses and GTID statements are stripped on import, so a dump from another host imports as it is.
4. Deploy. The first deploy imports the dump instead of installing Magento, runs setup:upgrade for your code, and points the store at its temporary *.apps.nautvia.com address.

The environment shows this as a checklist until the first deploy, and Deploy stays disabled until the dump is uploaded. You can correct the crypt key until then; afterwards the store depends on it and it can no longer be changed.

Sign in to the admin with your existing admin accounts — they came with the database. Only the admin address is new; the key button next to Visit shows it.

If you ever tear the environment down, its database goes with it, and the next deploy imports the latest uploaded dump again — take a backup first if the store has taken orders since.

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 as above — repository connected, infrastructure attached, database imported by the first deploy.
2. Check the encryption key worked — open a payment method or an SMTP setting in the admin; it should show its saved value.
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 import catches the orders placed while you were testing: upload a fresh dump, restore it from Backups, deploy.
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. Up to 5 GB you upload it yourself from the Backups tab — see Backups and restores. Larger than that, we handle it over SSH.
• Your crypt key from app/etc/env.php.
• 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.