To move a website safely, list everything the old host does for you, lower the DNS TTL well before the move, copy the site to the new host and test it there before any visitor sees it. Then switch DNS and check the website, email and SSL. Keep the old hosting account running until the DNS change has spread and you have confirmed that nothing still depends on it. Done in this order, every step of the move can be reversed.
#Make an inventory before you touch anything
A move usually goes wrong because of something the old host did quietly. Go through the old account and write down:
- Files. The website's code, uploaded media, and any files outside the public web folder, such as configuration files or private storage.
- Databases. Every database, its user and permissions, and the database server version. Check the application's configuration to see which databases it actually uses.
- Software versions. The PHP version, or other runtime, and the extensions the site needs. A version mismatch is a common cause of a blank page after a move.
- Email. Every mailbox, alias, forwarder and mailing list, and where the mail is actually stored. It may be on the old host, or with a separate provider that only needs its DNS records kept.
- Cron jobs. The scheduled tasks and the exact commands they run. They are easy to miss because nothing visible breaks at first.
- DNS records. Export or copy the whole zone: A, AAAA, CNAME, MX and TXT records, including SPF, DKIM and any verification records for other services.
- SSL. Which certificate the site uses and whether it renews automatically.
- Other settings. Redirect rules, password-protected folders, IP restrictions and custom error pages.
Also check who controls the domain and its DNS. If you do not have the login for the registrar, get it now. The article on how domain names and DNS records work explains records and nameservers if you need a refresher.
#Lower the DNS TTL in advance
Every DNS record has a TTL (time to live), which tells resolvers how long they may cache the answer. If the TTL on your A record is long, some visitors will keep reaching the old server for that long after you change it.
Lower the TTL on the records you will change. Usually these are the A and AAAA records for the domain and the www name, plus the MX records if email is moving. Do it at least as long before the move as the current TTL value, so the old, longer value has expired everywhere by the time you switch. Raise it again once the move has settled.
If you are also changing nameservers, that change is made at the registrar and can take longer to spread than a change to a single record. Where you can, move the site by changing records first, and change nameservers as a separate step.
#Copy the site and test it before switching
- Set up the new account. Create the databases and users, select the same runtime version, and add the domain.
- Copy files and data. Transfer the files over SFTP or with the control panel's tools. Export each database from the old host and import it on the new one. Keep the file permissions the application expects.
- Update the configuration. Point the application at the new database name, user, password and host. Look for hard-coded paths or old server addresses in configuration files.
- Test on the new host privately. Edit the
hostsfile on your computer so the domain resolves to the new server's IP address for you alone, then browse the site as usual. Check pages, logins, forms, search, uploads, checkout in test mode and the admin area, and read the server's error log. - Recreate the cron jobs and confirm that each one runs.
- Prepare SSL. Some certificates can only be issued once the domain points to the new server; others can be copied or validated through DNS. Know which case applies, so the site is not left without a valid certificate after the switch.
#Cut over DNS and check email
Pick a quiet time. If the site takes orders, comments or form submissions, freeze changes on the old site or plan a final database sync just before the switch, so nothing written on the old server is lost.
- Make the final copy of the database and of any new uploads.
- Change the A and AAAA records, or the CNAME, to point to the new server.
- Install or confirm the SSL certificate and check that the site loads over HTTPS without warnings. The article on SSL certificates covers the mixed-content problems that can appear at this point.
- If email is moving, create the mailboxes on the new host and copy existing mail over IMAP. Then update the MX records and the SPF and DKIM TXT records for the new mail server.
- Send and receive test messages to and from an outside address, and check that outgoing mail does not land in spam.
Email is easy to forget once the website looks right. Mail can keep arriving at the old server for a while after the MX change, so log in there during the transition and move anything that lands.
#Rollback and what to keep until propagation finishes
Keep a way back until you are sure the move worked:
- Keep the old hosting account active and paid until DNS has spread, email has settled and the new site has run normally for a while. Do not cancel it on the day of the move.
- Keep the export of the old DNS zone. If something serious breaks, point the records back to the old server. The low TTL makes this quick.
- Keep full backups of the files, databases and mailboxes taken just before the switch, stored somewhere other than either host.
- Watch both servers. Check the old server's access log. When it stops receiving real visitors and mail, propagation is effectively finished for your users.
- Write down the new setup: where the site runs, which versions it uses, where backups go and which cron jobs exist.
Only then close the old account and raise the TTL back to a normal value.
#How PN Scripts can help
PN Scripts Hosting offers shared hosting, KVM VPS with root access, dedicated servers and domains, so a site and its domain can be managed with one company. You can compare what each package includes on the hosting plans page.
Comments
Comments
Be the first to leave a comment.
Leave a comment