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

# Migration Overview

> Move an existing server, site, or database to Arct Cloud.

Migrating means copying your data and configuration onto a new Arct Cloud server, verifying it works, then pointing DNS at it. Your current server keeps running the whole time, so you control the switch.

## Choose Your Approach

Deploy a clean Arct Cloud image, install your software stack, and move your data and configuration onto it. That is the approach every guide here follows.

The alternative, cloning your old server's disk image onto the new one, carries the old kernel, storage drivers, and network configuration with it. Those are matched to the hardware and virtualization of the provider you are leaving, so a cloned system often fails to boot or comes up without networking. Diagnosing that means working inside a system neither you nor our engineers have a clean reference for.

<Note>If you need the old machine's exact partition layout, take a full backup and keep the source server running until the new one is verified. A clean image plus your data is faster to recover than a broken clone.</Note>

## Pick Your Guide

| You are moving                                     | Guide                                                 |
| -------------------------------------------------- | ----------------------------------------------------- |
| A Linux server: apps, databases, services          | [Linux Server Migration](/migration/linux-server)     |
| A Windows Server: IIS, SQL Server, scheduled tasks | [Windows Server Migration](/migration/windows-server) |
| A website and its DNS records                      | [Website and DNS Migration](/migration/website-dns)   |
| A WordPress site                                   | [WordPress Migration](/migration/wordpress)           |

## Before You Start

<Steps>
  <Step title="Inventory the Source Server">
    List what actually has to move: application directories, databases, service configs, cron jobs, firewall rules, TLS certificates, and any credentials stored on disk.
  </Step>

  <Step title="Check Disk and Memory">
    Run `df -h` and `free -m` on the source server. Pick an Arct Cloud [plan](/compute/virtual-machines/overview) that matches or exceeds current usage.
  </Step>

  <Step title="Pick a Location by Latency">
    Measure the round trip from where your users and upstream services actually are, then choose the closest available location. The deployment flow shows which locations are currently available.
  </Step>

  <Step title="Lower Your DNS TTL">
    At least 24 hours before cutover, set the TTL on the records you will change to 300 seconds. Traffic then moves within minutes instead of hours.
  </Step>

  <Step title="Add an SSH Key">
    Go to **Settings** > **SSH Keys** and add your public key. See [SSH Keys](/compute/virtual-machines/ssh-keys).
  </Step>

  <Step title="Take a Backup">
    Back up the source server before you touch anything, and keep the backup off both machines.
  </Step>
</Steps>

## Cutover Order

1. Deploy the Arct Cloud server and install the same software stack.
2. Copy data and configuration.
3. Verify the new server using a local hosts file entry, before any DNS change.
4. Stop writes on the source, run a final sync, then update DNS.
5. Keep the source server running for a few days, then decommission it.

<Warning>Do not change DNS before step 3 passes. A verified server behind a stale record is recoverable; an unverified one is downtime.</Warning>

## Before You Delete the Old Server

Time alone is not the signal. Check that nothing still depends on it:

* Watch its access and application logs. Requests still arriving mean a record, a hardcoded IP, or a cron job somewhere still points at it.
* Run `ss -tnp` on it to see which connections are still open and what is holding them.
* Confirm your own services reference the new host. Application configs, API callbacks, monitoring checks, and backup jobs often carry the old IP.
* Check that scheduled jobs run on the new server and not on both.

When the logs are quiet and nothing references the old IP, take a final backup and shut it down.

## Getting Help

Open a [support ticket](/account/support-tickets) if you get stuck. Tickets are handled by infrastructure engineers, and the same engineer stays on the thread until it is closed. They can read your server logs to help with migration and setup.