Skip to main content
This guide covers the DNS side of a migration: what to change, what to leave alone, and the order that keeps the site reachable throughout. Move the files and database first with the Linux or Windows guide.

​
Inventory Your Records

Before you change anything, export the current zone from your DNS provider or read it back:
Changing MX or SPF records while only the website moves will break mail delivery. Leave mail records alone unless mail is part of the migration.

​
Lower the TTL First

At least 24 hours before cutover, set the TTL on the records you plan to change to 300 seconds. Resolvers cache the old value for the length of the old TTL, so this step has to happen before, not during, the switch.
The number in the second column is the remaining cache lifetime. Wait for it to drop to the new value before you continue.

​
Configure the Web Server

Recreate the site config on the Arct Cloud server.

​
Handle TLS Certificates

Issue the certificate before the DNS change so there is no gap where the site answers on HTTP only. Copy the existing Let’s Encrypt state from the source server:
Install certbot on the new server and let it wire up the web server config:
After DNS points at the new server, force a renewal so the certificate is issued and validated from here:
HTTP-01 validation requires DNS to already resolve to the server being validated. To issue a fresh certificate before cutover, use DNS-01 validation instead.

​
Verify Before You Switch

Point your own machine at the new server with a local hosts file entry, /etc/hosts on Linux and macOS or C:\Windows\System32\drivers\etc\hosts on Windows:
Then check:
  • The homepage and two or three deep pages load
  • Sign-in works and sessions persist
  • A form submission writes to the database
  • Uploads and media resolve
  • HTTPS shows a valid certificate
  • Redirects, including apex to www or the reverse, still fire
Remove the hosts entry afterward.

​
Cut Over

1

Freeze the Source

Put the site into maintenance mode so no new orders, posts, or uploads land on the old server.
2

Run a Final Sync

Copy files and re-import the database one last time.
3

Update the A and AAAA Records

Change them to the new server IP at your DNS provider. With a 300 second TTL, most resolvers pick up the change within five minutes.
4

Confirm Propagation

Both should return the new IP.
5

Restore the TTL

Set the TTL back to 3600 seconds or your usual value once traffic has moved.
6

Keep the Source Running

Leave the old server up for a few days. Stragglers on cached DNS will still reach it, and you keep a rollback path. Before deleting it, run the checks before you delete it.

​
Troubleshooting

Their resolver cached the record before you lowered the TTL. It clears on its own. Leaving the source server running in maintenance mode avoids errors during the tail.
The certificate covers a name the request did not use, or certbot wrote its config after the last reload. Check with sudo certbot certificates, then reload the web server.
An MX or SPF record was changed along with the site records. Restore them to their previous values, then confirm with dig example.com MX +short and dig example.com TXT +short.
Absolute URLs in the database or config still reference the old host or an old path. Search the database for the old domain and update it.
The site config still generates http:// URLs. Update the site URL setting and add a redirect from HTTP to HTTPS in the web server config.