How to move a server to the cloud, step by step

To move a server to the cloud, build a matching cloud server, copy your files and database to it while the old one keeps serving, and test it on its own IP. Then switch your DNS record to it, with the TTL lowered a day ahead. Keep the old server running for a day or two. That's your way back if anything breaks.

You don't need a migration framework for one box. Many guides on cloud migration are written for companies moving hundreds of apps at once. With one server, the hard parts are small and specific: the rsync flags a plain copy misses, a consistent database dump, and a DNS switch you can undo.

What does migrating a server to the cloud involve?

Google calls the simplest kind of move a rehost: you move a workload "with minor or no modifications or refactoring" (Google Cloud). For one server, that doesn't mean copying the whole disk. Disk images don't move between clouds, so the reliable path is what our docs call provision and sync: a fresh VM with the same OS, your software installed on it, and your data copied across. You get a clean, current server, not a clone of an old image with years of drift in it.

Two cases don't fit. A Windows server goes to our private cloud, which runs Windows Server. And a box that has to stay physical can go into our Santa Clara data center as colocation.

What should you check before you move?

Write these down from the old server itself:

The OS and its version
Every service that runs, and the ports it listens on
Where the data lives: the app folder, uploads, anything outside it
Databases, with their engine and version
Cron jobs and anything else on a schedule
SSL certificates, and how they renew
Who hosts your DNS today, and the TTL on the records you'll change

Then look at what the box actually uses over a normal week: CPU, memory and disk. Size the new server from that, not from the old spec sheet.

How big should the cloud server be, and what will it cost?

On American Cloud, a VM is priced by its parts: $10 a month per vCPU, $5 per GB of memory and $1 per 16 GB of disk. Say the old box is an office server with 4 vCPU, 8 GB of memory and a 200 GB disk:

Line	Monthly
4 vCPU	$40.00
8 GB memory	$40.00
200 GB disk	$12.50
Network and its NAT public IP	$0
Data out	$0
Total, monthly term	$92.50

[ Where the $92.50 goes ]

Compute and memory are most of the bill. Data out adds nothing.

Billed by the hour, the same server comes to $94.35 for a full month. That makes a test week about $22, enough to rehearse the whole move before you commit. Keeping the data on the VM's own disk is cheaper: the same 200 GB as a separate block storage volume is $20 a month. We don't charge for data out, so pulling a copy back off the server later costs nothing extra. The pricing page prices any other size.

How do you copy the files without a long outage?

Copy the files in two rsync passes. The first copies everything while the old server keeps serving. It can take hours, and nobody notices. The second runs at cutover, after you pause writes, and sends only what changed since the first, so it takes seconds to minutes.

The rsync manual says plain -a skips hard links, ACLs and extended attributes, so add -HAX. --numeric-ids keeps owner and group IDs as numbers instead of matching them by name:

bash

# Pass 1: the old server keeps serving
rsync -aHAX --numeric-ids --info=progress2 -e ssh /srv/app/ user@NEW_IP:/srv/app/
 
# Dry run of the final pass: lists what would change, changes nothing
rsync -aHAXn --delete --numeric-ids -e ssh /srv/app/ user@NEW_IP:/srv/app/
 
# Pass 2, at cutover, with writes paused
rsync -aHAX --delete --numeric-ids -e ssh /srv/app/ user@NEW_IP:/srv/app/

The trailing slash on /srv/app/ copies the folder's contents. --delete removes files from the new server that you deleted on the old one, so run the dry run first.

How do you move the database?

Move it with a dump and a restore. PostgreSQL's pg_dump "makes consistent exports even if the database is being used concurrently" (PostgreSQL 18 docs):

bash

pg_dump -Fc mydb > db.dump
pg_restore -d newdb db.dump

Run pg_dump from a version at least as new as the old server's. An older one refuses to try. For MySQL with InnoDB tables, --single-transaction gives a consistent dump without locking anyone out (MySQL 8.4 manual):

bash

mysqldump --single-transaction mydb > db.sql
mysql newdb < db.sql

Do one dump early to rehearse. Do the real one after you pause writes. On the new server, keep the database listening on localhost only.

How do you switch traffic to the new server?

[ Cutover order ]

Which server takes traffic at each step of the switch.

Lower the TTL a day ahead. Do it at whoever hosts your DNS today, then wait for the old TTL to run out. A long TTL "means that updates to your records take longer to go into effect" (Cloudflare). Our own migration guides use 300 seconds.
Run the first rsync pass. The old server keeps serving while it copies.
Test the new server before DNS changes. First open its ports. On American Cloud that takes a firewall rule plus a port forwarding rule, or static NAT, which maps a public IP straight to the VM. If you want an address that won't change, reserve a public IP for $1 a month and map it with static NAT. Then run curl -H "Host: example.com" http://NEW_IP/ against it. For HTTPS, copy your certificates over with everything else, point your own computer's hosts file at the new IP, and load the site in a browser.
Pause writes on the old server.
Run the final rsync and the database dump.
Change the A record to the new IP. Check what the rest of the world sees with our DNS lookup tool.
Keep the old server running. It's your rollback, below.

Change one thing at a time. If you also want to move your DNS hosting to us (it's free), do it as its own step, well before or after the server move. A name server change takes its own time to spread.

What if something breaks after the switch?

Point the record back at the old server. That's the whole rollback, as long as the old server is still running. If you have a database, keep writes to the old one paused until you shut it down. Some visitors still reach the old IP for a while, and a write there would be lost. After a day or two of clean running, turn the old server off.

Once the new server is right, take a snapshot of it. It's a copy you know works, taken before you change anything else, and it costs $10 per 100 GB a month. For nightly protection, see our backup guide.

Can an AI assistant do the move for you?

Yes, if you'd rather not type the commands yourself. With the American Cloud MCP server, an assistant like Claude prices the new VM first, builds it when you say go, copies the data, tests it on the new IP and walks you through the DNS switch, with your old server still running. Hundreds of customers have moved to us from AWS and DigitalOcean. Our step-by-step guides for leaving DigitalOcean and Linode follow the same plan as this page. Leaving AWS? Read how to move your workloads off AWS.

And if a step goes sideways halfway through, open a ticket. Support replies in under 2 minutes, and a person answers it.