Skip to main content
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.
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.

​
Pick Your Guide

​
Before You Start

1

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

Check Disk and Memory

Run df -h and free -m on the source server. Pick an Arct Cloud plan that matches or exceeds current usage.
3

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

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

Add an SSH Key

Go to Settings > SSH Keys and add your public key. See SSH Keys.
6

Take a Backup

Back up the source server before you touch anything, and keep the backup off both machines.

​
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.
Do not change DNS before step 3 passes. A verified server behind a stale record is recoverable; an unverified one is downtime.

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