I'm migrating a decade-old peer-reviewed journal from an old custom HTML/PHP site on Kualo to a new WordPress installation on GreenGeeks. The new site is currently on a temporary domain, and the domain transfer has just started. I understand plugins, CSS, and basic WordPress administration, but I've never handled a hosting migration or DNS cutover before, and I'm overwhelmed by the order of operations.
The site contains static pages, several hundred article PDFs, more than 500 images, contact forms, embedded videos, and many old URLs that may already be cited or indexed. I have a large redirect list prepared, including rules for old PHP URLs such as `/what-is.php?...` that need to point to new WordPress paths.
My rough plan was to finish the site, point the nameservers to the new host, enable SSL, change the WordPress URLs, run Better Search Replace, configure redirects, test everything, and then disable maintenance mode. However, I'm worried that changing the nameservers too early could cause visitors to see errors, and I'm unsure whether SSL, redirects, and database URL replacement should happen before or after DNS changes.
What sequence would minimize downtime and reduce the risk of losing old article links, PDFs, search rankings, or access to the site?
3 Answers
For a journal, the redirect map is probably the most important part of the migration. Preserve every article URL you can find, including old PHP query-string URLs, author pages, PDF locations, and other links that may appear in citations. Map each old address to the most relevant new page and use permanent 301 redirects rather than sending everything to the homepage.
After launch, resubmit the XML sitemap and monitor crawl errors. You don’t need a domain-change notification when the domain itself stays the same, but you should verify that important old URLs return a 301 and that their destinations return a normal 200 response. If any articles have DOIs, check those separately: DNS changes do not update DOI registrations, so the DOI landing pages must still resolve through your redirects or be updated with the DOI provider.
Do as much preparation as possible before changing DNS. Finish and test the new site on its temporary address, configure the plugins, and prepare your complete old-URL-to-new-URL redirect spreadsheet. You can write and test the redirect rules ahead of time; they don’t depend on the domain being live yet.
Take a full database backup before running Better Search Replace, especially because WordPress may contain serialized data. Update the WordPress Address and Site Address only when the real domain is ready to resolve to the new server. Then check internal links, images, PDFs, forms, mixed content, and 404s.
A practical sequence is: finish the new site, complete the domain transfer, lower the DNS TTL if possible, freeze changes on the old site, make a final backup or content sync, point DNS to the new host, issue SSL once DNS resolves, activate the redirects, and then take the site out of maintenance mode. Keep the old hosting account active for at least a month so you have a rollback option.
Nameservers and redirects are really two separate tracks. You should create and test the redirects before the cutover, but they cannot actually serve visitors until DNS sends traffic to the new host. During DNS propagation, many visitors will continue reaching the old server, so the old site should remain online and functional until the switch is confirmed.
Lower the DNS TTL to around 300 seconds a day or two before the change if your DNS provider allows it. That makes rollback much quicker. Don’t change the WordPress URLs while the domain still points exclusively to the old server, because that can lock you out or create broken links. Once the domain resolves to the new hosting account, finish the HTTPS setup, set both WordPress URLs to the HTTPS domain, and test the admin area.
SSL should normally be issued after DNS points to the new host. Let’s Encrypt needs to verify the real domain against that server, so it generally cannot complete validation while the domain still resolves elsewhere.
That helps clarify the process. I’ll take a break and work through the preparation first instead of trying to change everything at once. The site is fairly simple now, but I’m dealing with a lot of old PDFs and URLs created by the previous maintainer.