Migrate from DigitalOcean

If you run droplets on DigitalOcean, moving to American Cloud is the most mechanical migration there is. The mental model is the same — a Linux server with a public IP, a block volume, a firewall, a DNS record — and almost everything maps one-to-one. So this recipe hands the labor to your AI assistant: with the American Cloud MCP server connected, it inventories what you have, prices the American Cloud equivalent, provisions it, syncs your data, and cuts DNS over — from prompts you paste in.

How the migration actually works

Disk images don't transfer between clouds. There's no "import this droplet" button, on any provider, because a droplet's image is tied to DigitalOcean's hypervisor and metadata. Trying to lift a raw image across is the slow, fragile path.

The reliable path is provision and sync, and it's exactly what your assistant is good at:

1. It looks at the source droplet — over SSH, read-only — to see what's installed and how it's configured.
2. It creates a matching American Cloud VM (same CPU/RAM class, same OS).
3. It replicates the software setup on the new VM.
4. It rsyncs your application data and files across.
5. It replicates your firewall rules.
6. It cuts DNS over to the new IP.

You end up with a clean, current server running your software on your data — not a copy of an aging disk image with years of drift baked in.

What maps to what

Every DigitalOcean primitive has a direct American Cloud equivalent:

Both object storage services are S3-compatible, which is why Spaces is the easiest piece of all — rclone copies straight from one to the other with no intermediate download. And a managed database becomes a database your assistant installs and runs on a VM, migrated with a standard dump and restore.

Before you start

• SSH access to each droplet you want to move (the assistant inspects them read-only).
• A domain you control, with the ability to change its DNS or nameservers.
• The MCP server connected with a read-write key and --allow-writes.
• Optional: doctl (DigitalOcean's CLI) authenticated locally, so the assistant can read your DigitalOcean inventory directly. If you'd rather not install it, just describe what you have and the assistant works from that plus what it finds over SSH.

Claude Code is the ideal client here, because migrating a droplet means running commands on both servers — SSH in, install packages, rsync files. Claude Code combines the American Cloud tools with your terminal in one session. Other MCP clients handle the provisioning fine; you'll just run the SSH and rsync steps yourself when the assistant tells you to.

Phase 1: inventory and plan

Start read-only. The goal is a complete picture of what's on DigitalOcean and a priced American Cloud plan for each piece — before you create anything.

I'm migrating from DigitalOcean to American Cloud. Help me inventory and plan
it. Don't create anything yet — this is a read-only planning pass.
 
1. Take stock of what I have on DigitalOcean. If doctl is available, list my
   droplets, volumes, Spaces, reserved IPs, cloud firewalls, and DNS domains.
   Otherwise, ask me for the list. For each droplet, note its region,
   vCPU/RAM, OS, and attached storage.
2. For each droplet I can SSH into, connect read-only and tell me what's
   actually installed and running: the OS version, the web server, the
   runtime (Node, Python, PHP, etc.), any database engine, and where the
   application data lives on disk.
3. Map each DigitalOcean resource to its American Cloud equivalent. For the
   VMs, list American Cloud regions and VM packages and pick the closest
   like-for-like CPU/RAM match for each droplet.
4. Price the American Cloud side: a per-droplet cost estimate for each VM,
   plus block storage and object storage. Give me a total monthly estimate.
5. Produce a migration plan: which droplet to move first (smallest/lowest
   risk), the order of the rest, and where a managed database needs to become
   a database on a VM.

What your assistant will do

1. Read your DigitalOcean inventory. If doctl is authenticated, it runs read-only doctl commands to enumerate droplets, volumes, Spaces, reserved IPs, firewalls, and domains. Otherwise it works from your description.
2. Inspect each droplet over SSH. It connects read-only and checks the OS, the running services, the installed runtimes and database engines, and where your data lives — so the new server is built to match, not guessed at.
3. Map to American Cloud equivalents. It calls list_regions, list_vm_packages, and list_images to find a nearby region, the closest CPU/RAM tier for each droplet, and a matching OS image.
4. Price every piece. It calls get_cost_estimate_vm per droplet, get_cost_estimate_block_storage for volumes, and get_cost_estimate_object_storage for Spaces replacements — and totals them. Nothing is billed during planning.
5. Sequence the move. It recommends starting with the smallest, lowest-risk droplet so you build confidence on something easy, and flags any managed database that needs to become a database on a VM.

Phase 2: migrate one droplet

This is the repeatable unit. Run it once per droplet — start with the small one from your plan, then re-run for each remaining server. Fill in the placeholders.

Migrate the DigitalOcean droplet "\{droplet-name\}" to American Cloud, using
the like-for-like size we picked in the plan. Walk through it step by step and
show me the cost estimate before creating anything.
 
1. Show me the monthly cost estimate for the matching VM and any block
   storage. Wait for me to confirm.
2. Create the American Cloud VM with that size and a matching Ubuntu image, on
   an isolated network, using my SSH key. If the droplet had a block volume,
   create and attach a matching one. Wait until the VM is fully running and
   has a public IP.
3. Replicate the firewall: read the inbound rules protecting the droplet and
   create the equivalent firewall rules on the new VM's public IP (same
   ports, same source ranges). Whitelist only what the droplet allowed.
4. Replicate the software setup over SSH: install the same web server,
   runtime, and packages the droplet runs, matching versions where it matters.
5. If the droplet uses a managed database, install the same engine
   (PostgreSQL / MySQL / Redis) on the new VM, keep it listening on localhost
   only, and migrate the data with a dump from the source and a restore on the
   target.
6. Do an INITIAL data sync now, while the droplet keeps serving traffic: rsync
   the application files and any volume data from the droplet to the new VM.
7. Bring the app up on the new VM and test it against its public IP directly
   (curl with a Host header, or by editing my local hosts file) — do NOT
   touch DNS yet. Confirm it works end to end.
 
Stop after the test and tell me what to verify before we cut over.

What your assistant will do

1. Price, then provision. It shows you get_cost_estimate_vm (and get_cost_estimate_block_storage if there's a volume) and waits. On your go-ahead, create_vm provisions the VM on an isolated network with your SSH key installed via keypairs, and networkAccess opens the ports the app needs. It polls get_vm until the status reaches STARTED and a public IP is assigned.
2. Match the storage. If the droplet had a block volume, create_block_storage_volume makes a matching one and attach_block_storage_volume attaches it to the new VM in the same region.
3. Replicate the firewall. It reads the droplet's inbound rules and recreates them on the new VM's public IP with create_firewall_rule — same protocols, same ports, same source CIDRs. It whitelists only the sources the droplet allowed; nothing is opened to the whole internet unless the droplet already was.
4. Rebuild the software. Over SSH it installs the same stack it found during inventory — web server, runtime, packages — and lays down your config.
5. Move the database, if any. For a managed database, it installs the matching engine on the VM, binds it to localhost so it isn't exposed, and migrates the data with a dump/restore. The connection string in your app points at localhost, and nothing new is opened on the firewall.
6. Sync the data. It rsyncs your application files and volume data from the droplet to the new VM while the droplet stays live.
7. Test against the new IP. It brings the app up and verifies it against the new VM's public IP directly — without changing any DNS — so you confirm the new server works before a single user is routed to it.

Phase 3: cut over and decommission

Once the new VM passes its direct-IP test, the switch itself is small. Do it per droplet, or batch the DNS changes once all droplets are tested.

The new VM for "\{droplet-name\}" tested clean. Cut DNS over to it.
 
1. First, lower the TTL on the affected DNS records to something short (e.g.
   300 seconds) and wait for the old TTL to expire, so the cutover propagates
   fast.
2. Do a final delta rsync from the droplet, with writes briefly paused, so the
   new VM has the latest data.
3. Update the DNS records to point at the new VM's public IP. If I want a
   stable address, reserve a public IP on American Cloud and map it to the VM
   first, then point DNS at that.
4. Tell me how to confirm the domain now resolves to the new VM, and keep the
   old droplet running until I've verified everything for a day or two.

What your assistant will do

1. Pre-lower the TTL — wherever DNS is served today. If the domain already lives on American Cloud DNS, the assistant shortens the relevant records with update_dns_record. If it's still on DigitalOcean DNS or elsewhere, that's where the TTL must drop (the assistant tells you exactly what to change), and if you're also moving the zone here, create_dns_zone adds it and the assistant shows you the nameservers to set at your registrar — a delegation change that takes time on its own, so do it well before cutover.
2. Final delta sync. With writes briefly paused on the source, it runs the second rsync — only the changes since the initial pass — so the cutover loses no data.
3. Flip the records. It points the A records at the new VM's public IP with update_dns_record. For a stable address it can reserve_public_ip on the new network (the equivalent of a DigitalOcean reserved IP) and map it to the VM with enable_static_nat, then point DNS at that.
4. Run both briefly, then retire. It leaves the droplet running so a rollback is just pointing the record back — minutes, thanks to the lowered TTL. After a day or two of clean operation, you destroy the source on the DigitalOcean side and stop paying for it.

Migrating Spaces (object storage)

Because both services are S3-compatible, your Spaces buckets are the simplest piece to move — rclone copies directly from one to the other without downloading anything to your machine in between.

Migrate my DigitalOcean Spaces to American Cloud object storage.
 
1. Create an American Cloud object storage unit and the buckets I need, and
   give me the S3 access keys and endpoint.
2. Set up rclone with two remotes — my DigitalOcean Spaces and the new
   American Cloud unit — and copy each bucket across, server to server.
3. Update my app's S3 endpoint and credentials to point at American Cloud.

Your assistant calls create_object_storage_unit and create_object_storage_bucket, then get_object_storage_keys to retrieve the S3 access key, secret, and endpoint. It configures rclone with both providers as S3-compatible remotes and runs rclone copy directly between them. American Cloud object storage has no egress fees, so accessing your migrated data costs nothing per gigabyte (see why egress fees matter). For the full S3 toolkit — the AWS CLI, s3cmd, framework upload libraries — see Object storage with your AI assistant and the s3cmd guide.

Migrating DOKS (managed Kubernetes)

If you run DigitalOcean Kubernetes, your assistant can stand up a managed cluster on American Cloud and you re-apply your workloads onto it. The full walkthrough — sizing, creating the cluster, fetching the kubeconfig, and deploying — is in Run on Kubernetes. The migration shape is the same provision-and-sync idea: create the cluster, point kubectl at it, apply your manifests, migrate any persistent data, then move DNS.

Tips for a smooth move

• Start small. Move the lowest-risk droplet first. By the time you reach the important ones, the playbook is muscle memory and your assistant has the pattern down.
• Keep the source until you're sure. Running both for a day or two is cheap insurance and makes rollback a non-event. Destroy the droplet only after the new VM has proven itself.
• Always price before you build. Make "show me the cost estimate first" part of every prompt. The assistant has cost-estimate tools for VMs, block storage, and object storage — there's no reason to create blind.
• Let the assistant read, not guess. The SSH inspection step is what makes the new server match the old one. Don't skip it; an accurate inventory is the difference between a clean rebuild and a debugging session.

Next steps

• Things to try with the MCP server — more prompt ideas across compute, networking, storage, and DNS
• Use American Cloud with Claude Code — the provision-and-deploy client setup
• Deploy a Next.js app with your AI assistant — the full single-server build, end to end
• Object storage with your AI assistant — the S3-compatible details for your Spaces move
• Run on Kubernetes — for your DOKS workloads
• Write an AGENTS.md for your project — teach your assistant your deploy conventions so future moves are one prompt