> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arct.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Website and DNS Migration

> Move a website and switch its DNS records with minimal downtime.

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](/migration/linux-server) or [Windows](/migration/windows-server) guide.

## Inventory Your Records

Before you change anything, export the current zone from your DNS provider or read it back:

```bash theme={null}
dig example.com ANY +noall +answer
dig www.example.com A +short
dig example.com MX +short
dig example.com TXT +short
```

| Record                     | Change it?                                    |
| -------------------------- | --------------------------------------------- |
| `A`, `AAAA` for the site   | Yes. Point to the new server IP.              |
| `CNAME` for `www`          | Usually no, if it already points at the apex. |
| `MX`                       | Only if mail moves too.                       |
| `TXT` for SPF, DKIM, DMARC | Only if mail moves too.                       |
| `CAA`                      | Only if your certificate issuer changes.      |

<Warning>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.</Warning>

## 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.

```bash theme={null}
dig example.com A +noall +answer
```

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.

<AccordionGroup>
  <Accordion title="nginx">
    ```nginx theme={null}
    server {
        listen 80;
        listen [::]:80;
        server_name example.com www.example.com;
        root /var/www/example.com;
        index index.php index.html;
    }
    ```

    ```bash theme={null}
    sudo nginx -t && sudo systemctl reload nginx
    ```
  </Accordion>

  <Accordion title="Apache">
    ```apache theme={null}
    <VirtualHost *:80>
        ServerName example.com
        ServerAlias www.example.com
        DocumentRoot /var/www/example.com
    </VirtualHost>
    ```

    ```bash theme={null}
    sudo apachectl configtest && sudo systemctl reload apache2
    ```
  </Accordion>
</AccordionGroup>

## 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:

```bash theme={null}
sudo rsync -aAX -e "ssh -i /root/.ssh/migration" \
  root@SOURCE_IP:/etc/letsencrypt/ /etc/letsencrypt/
```

Install certbot on the new server and let it wire up the web server config:

```bash theme={null}
sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
```

After DNS points at the new server, force a renewal so the certificate is issued and validated from here:

```bash theme={null}
sudo certbot renew --force-renewal
sudo systemctl status certbot.timer
```

<Note>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.</Note>

## 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:

```
NEW_SERVER_IP example.com www.example.com
```

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

<Steps>
  <Step title="Freeze the Source">
    Put the site into maintenance mode so no new orders, posts, or uploads land on the old server.
  </Step>

  <Step title="Run a Final Sync">
    Copy files and re-import the database one last time.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Confirm Propagation">
    ```bash theme={null}
    dig example.com A +short @8.8.8.8
    dig example.com A +short @1.1.1.1
    ```

    Both should return the new IP.
  </Step>

  <Step title="Restore the TTL">
    Set the TTL back to 3600 seconds or your usual value once traffic has moved.
  </Step>

  <Step title="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](/migration/overview#before-you-delete-the-old-server).
  </Step>
</Steps>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Some visitors still land on the old server">
    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.
  </Accordion>

  <Accordion title="The browser shows a certificate warning">
    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.
  </Accordion>

  <Accordion title="Mail stopped after the move">
    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`.
  </Accordion>

  <Accordion title="The site loads but images and CSS are missing">
    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.
  </Accordion>

  <Accordion title="Mixed content warnings on HTTPS">
    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.
  </Accordion>
</AccordionGroup>