What items need to be checked when switching hosts on the day of switching, and parsing, certificates, and email cannot be missed.
What items need to be verified on the day of the host switch, how should the DNS, certificate, and email be checked? Verify in the order of the access chain, not by checking each item on the background function table: First, confirm that the domain name resolution really points to the new host, then confirm that the certificate on the new address is complete and available, then verify whether the page can render normally (whether the pseudo-static address matches the rules), and whether the old address is permanently redirected to the new address. Finally, verify the write side - whether form submissions, comments, and interface calls can be stored in the database. The DNS, certificate, and email items are most often overlooked because they are not in the site program, but at the boundary between the host and the domain.
Before the switch: Arrange the backup and parsing validity period first
Two things must be completed before the switch, and it can't be done on the day of the switch.
The first thing is a complete backup. Backup and recovery support data along with static files for backup and recovery, the migration scenario must include attachments and generated files, and only backing up the database will leave the missing half of the image in the recovery state. The third-party migration list is consistent on this point: backups must be done, and two copies must be done.
The second is to lower the expiration time of the resolution record. The conventional suggestion is to reduce the TTL to 300 seconds 24 to 48 hours before the switch, so that the residual time of the old records during the switch is minimized; if it is changed on the day of the switch, the uncached visitors will still be sent to the old host, looking like a 'switch failure'.
The third step is to pull up the new environment in advance according to the deployment method. For sites deployed using Docker images, you can run the same image on the new host and mount the data volume back; for sites deployed using Baota panel or aaPanel with one-click deployment, you also need to check if the running directory, listening port, and rewrite module are equivalent. The deployment method is different, and the items to be verified on the day have not changed, but the location where problems usually occur is usually in this layer of difference.
Switching day: verify each item according to the access chain
| Verification items | How to verify | Common failure symptoms |
|---|---|---|
| Domain resolution | Multiple queries confirm that the new IP is pointed to | Part of the regions are still resolved to the old host |
| SSL Certificate | Access the new domain directly and check the certificate chain and validity period | The certificate is only valid for the old address, the browser warns |
| Page rendering | Visit the homepage, list page, and detail page once each | Error on the detail page or dropped to the error page |
| Static address | Check if several standard addresses can be hit | The rules have not been migrated, all go through dynamic parameters |
| Old address redirection | Visit the historical address to confirm permanent redirection | Only jump to the homepage or return to a temporary redirection |
| Write the chain | Submit the form, leave a message, comment and check the entry | Readable but not writable, the interface returns an exception |
| Email identity | Send a test email and check the sending identity record | Email goes to the spam box or fails to send |
This item of the certificate needs to be emphasized separately: The certificate on the new host is not only about whether it is installed, but also whether the certificate chain is complete, whether it covers both www and non-www writing. When the chain is missing, the desktop browser may be normal, but the mobile端 and interface client will report an error directly.
The verification order of static rules and 301 redirects
The most common hidden failure in host migration is not the loss of content, but the lagging behind of address rules. The rule definitions in the static rule management should be migrated with the site, otherwise the same page can be accessed through both standard addresses and parameter addresses, and the search end will see two copies. The check order is: first, check whether the rules on the new host are effective, and then see if the addresses generated by the site match the actual accessible addresses.
If the address format is changed during migration, you should set up a 301 redirect on the old address side. The writing style suggestion for the third-party list is the same: use permanent redirect, do not use temporary redirect - a temporary state that does not withdraw for a long time will allow the new and old address systems to coexist. Similarly, do not cancel the old host account on the same day, the conventional practice is to keep it for at least one week after switching, to accommodate visitors who still have cached resolution, and also as a rollback point.
One week after switching: old account and log observation
This week, look at three things: availability records, server logs, and traffic distribution. Check for intermittent failures in availability; look at where abnormal status codes are concentrated in what kind of addresses; and see if there is still a significant proportion of requests hitting old hosts - if there are, it indicates residual parsing or external links still pointing to old addresses.
Email is a typical item that does not show any problems on the same day but explodes after a week. Records related to identity (SPF, DKIM, DMARC) are often overlooked during host migration because they are in domain resolution rather than site background. The way to verify is not to see if there is any configuration, but to actually send an email and check the delivery results and identity verification.
Acceptance list
One, the resolution has been fully directed to the new host, and the review is consistent across multiple regions. Two, the new address certificate and certificate chain are complete, and both domain name formats can be accessed. Three, the pseudo-static rules are in effect, and the standard address is consistent with the actual address. Four, the old address is permanently redirected to the new page. Five, forms, messages, comments, and interface writes are all stored normally. Six, emails can be delivered normally, and the sender identity verification has passed. Seven, the old host account has been retained for more than one week, and the rollback path has been tested once.
Common questions
Can we change the resolution and backup first on the day of the switch?It is not recommended. The backup must be completed before the switch, and if there is no available restore point when an exception occurs after the switch, rollback will become reconstruction.
What should you do if the old content is displayed on the page during verification?First, distinguish between parsing leftovers and uncached cache. Multiple queries to confirm the parsing direction, then clear the page cache, the handling location of the two things is different.
Is there any risk in canceling the old host account in advance?Yes. Leftover parsing and external links will still send requests to the old address, and if it is disabled in advance, it will become inaccessible directly, and also lose the rollback point.
Should you care if you don't change the email service provider?To. Even if the email service does not change, the identity record and resolution on the domain side are still affected by the host migration, and it is still necessary to send a verification once in actuality.