A website migration is more than copying files. Domains, DNS, databases, email, certificates, scheduled tasks, third-party callbacks and search URLs can all be affected.
Create an inventory before moving
Record the domain, current DNS, hosting account, PHP and database versions, storage usage, email services, cron jobs, SSL certificates, CDN settings and third-party integrations. This inventory becomes the migration checklist and rollback reference.
Also record all important URLs and forms so they can be tested after the move.
Prepare complete backups
Export website files and the database, and verify that the backup opens. For large sites, check whether uploads, order documents or logs are stored outside the usual web directory.
Keep the old server available until the new site has been tested and DNS has fully propagated.
Build and test before changing DNS
Install the site on the new server using a temporary domain or local hosts-file override. Confirm the correct PHP modules, file permissions, rewrite rules, caching and scheduled tasks.
Test forms, logins, search, checkout, payment callbacks and transactional emails. A visual homepage check is not enough.
Plan DNS, SSL and email carefully
Reduce DNS TTL in advance when possible. Install SSL before sending traffic to the new server and ensure both www and non-www versions redirect consistently.
If email uses the same domain, preserve MX, SPF, DKIM and DMARC records. Website migrations often cause email problems when DNS records are replaced without review.
Complete post-migration checks
After switching, monitor error logs, traffic, form submissions and orders. Check redirects, canonical URLs, sitemap and robots rules. Confirm that search engines do not see the temporary test domain.
Only cancel the old hosting after backups are secured and the new environment has operated normally for an agreed period.
Document changes and verification results
Keep a short record of the date, affected component, previous version, new version, backup location and the checks completed after the change. This turns future troubleshooting into a comparison instead of guesswork.
For recurring work, record failures as well as successful tests. A pattern such as a form failing only after cache clears or a scheduled task missing at the same time each day is easier to identify when evidence is kept.
When to escalate the issue
Escalate when the site affects payments, customer data, account access, security, email delivery or repeated downtime. Stop making untracked changes if the cause is unclear, because every additional change can hide the original fault.
Provide the technical person with the URL, time, exact steps, screenshots, recent changes and available logs. A concise evidence package usually reduces diagnosis time more than a long general description.
