I'm migrating a decade-old peer-reviewed journal from a custom HTML/PHP site to a new WordPress installation on another hosting provider. The new site is nearly finished on a temporary domain, and the domain transfer has just started. I understand plugins, CSS, and basic WordPress administration, but I'm unsure about the correct order for DNS, SSL, URL replacement, redirects, and launch tasks.
The site has several main pages, hundreds of PDFs, more than 500 images, contact forms, embedded videos, and many old article, author, and PDF URLs. I have already started documenting redirects, including regex rules for old PHP URLs. Preserving those URLs is especially important because articles have been indexed and cited for years.
My current plan is to finish the temporary site, point the domain's nameservers to the new host, activate SSL, change the WordPress and site URLs, run a database search-and-replace, configure 301 redirects, test everything, and then disable maintenance mode. Should the redirect rules and database changes be prepared before the DNS switch? Could changing the nameservers cause visitors to see errors while propagation takes place, and when exactly should SSL be issued?
2 Answers
SSL normally comes after the DNS change. Let’s Encrypt needs to validate the real domain, so the domain must resolve to the new hosting account before the certificate can be issued. You can configure the hosting and prepare the site beforehand, but expect a short period during propagation when HTTPS may not work yet.
Nameservers are not quite the very last step: they come shortly before SSL and the final launch. The old site should generally remain available while different DNS resolvers update, so visitors will not all receive 404s at once. Once the new server is receiving traffic, issue SSL, force HTTPS, update the WordPress URLs, and test the redirects.
Do as much as possible before changing DNS. Finish and test the new site on its temporary address, back up the database, and prepare your old-to-new URL map in a spreadsheet. You can write the redirect rules ahead of time even though they will not take effect until traffic reaches the new server.
A sensible sequence is: complete the site; verify the domain transfer; lower the DNS TTL to around 300 seconds a day or two before the switch if your provider allows it; freeze changes on the old site and take a final backup; point the nameservers to the new host; wait for the domain to resolve there; issue and verify the SSL certificate; update WordPress’s site URLs; perform any remaining database replacement; enable the 301 redirects; test pages, images, PDFs, forms, HTTPS, and mixed content; then disable maintenance mode.
Keep the old hosting account active for at least a month so you have a rollback option. For a journal, make the article URL redirects the highest priority, and check any DOI records separately because DOI destinations are managed independently of DNS.
That helps clarify the distinction: the redirect list can be prepared and tested in advance, but the redirects only work once the domain is actually reaching the new server. I’ll also make sure the old hosting remains available during the transition.
Also be careful with the database search-and-replace. Take a backup first, especially if serialized WordPress data is involved. You usually do not need it merely to change the WordPress Address and Site Address, but it can help replace leftover temporary-domain references in image, PDF, and internal-link fields.