Website migration

A migration looks like copying files. What actually decides whether it goes well is everything around them: DNS records, mail, certificates, payment webhooks, cron jobs and the addresses that search engines already know.

We plan it as an operation with a rollback. First an inventory of what the project consists of and where it currently runs. Then a full copy on the new place, working and testable while the old site still serves visitors. Only after the numbers match — products, orders, users, pages — do we switch.

What the plan always includes:
— a backup restored and verified before anything is moved;
— a map of old addresses to new ones and 301 redirects in place at the moment of the switch;
— mail: SPF, DKIM and DMARC, so the new server's letters do not land in spam;
— payments and webhooks re-registered for the new domain and tested with a real small payment;
— cron jobs, queues and scheduled tasks, which are the usual thing to forget;
— the old site left untouched for two weeks as the real rollback.

We move sites between hostings, from a shared host to a server, between domains, and between platforms — including WordPress and WooCommerce stores, where the data lives in tables a generic export does not know about.