Migrate from Linode

A Linode instance is a Linux server with a public IP, a block volume, a firewall, and a DNS record pointed at it — which is exactly what makes moving off it to American Cloud so mechanical. Almost every piece maps one-to-one, so this recipe hands the work to your AI assistant. With the American Cloud MCP server connected, it takes inventory of what you run on Linode, prices the American Cloud equivalent, provisions it, syncs your data, and cuts DNS over — all from prompts you paste in. (Linode is now part of Akamai; if that change is part of why you're looking around, this is the path across.)

How the migration actually works

Disk images don't move between clouds. There's no "import this Linode" button, because an instance's image is tied to Linode's hypervisor and metadata — and trying to drag a raw image across is the slow, brittle option even when it's possible.

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

1. It inspects the source instance — over SSH, read-only — to learn what's installed and how it's set up.
2. It creates a matching American Cloud VM (same vCPU/RAM class, same OS).
3. It rebuilds the software stack on the new VM.
4. It rsyncs your application data and files across.
5. It recreates your firewall and any inbound port rules.
6. It cuts DNS over to the new IP.

What you get is a clean, current server running your software on your data — not a clone of an aging image with years of configuration drift baked in.

What maps to what

Every Linode primitive has a direct American Cloud equivalent:

Both object storage services are S3-compatible, which makes Object Storage the easiest piece of all — rclone copies straight from one to the other with no download in between. Object storage on American Cloud is for uploads, assets, backups, and artifacts. A Managed Database becomes a database engine your assistant installs and runs on a VM, migrated with a standard dump and restore.

Before you start

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

Claude Code is the ideal client here, because migrating an instance 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 full picture of what's on Linode and a priced American Cloud plan for each piece — before you create anything.

I'm migrating from Linode 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 run on Linode. If linode-cli is available, list my
   instances, Block Storage Volumes, Object Storage buckets, NodeBalancers,
   Cloud Firewalls, and DNS domains. Otherwise, ask me for the list. For each
   instance, note its region, vCPU/RAM, OS, and attached storage.
2. For each instance 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 Linode resource to its American Cloud equivalent. For the VMs,
   list American Cloud regions and VM packages and pick the closest
   like-for-like vCPU/RAM match for each instance.
4. Price the American Cloud side: a per-instance cost estimate for each VM,
   plus block storage and object storage. Give me a total monthly estimate so
   I can set it next to my current Linode bill.
5. Produce a migration plan: which instance 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 Linode inventory. If linode-cli is authenticated, it runs read-only commands to enumerate instances, volumes, Object Storage buckets, NodeBalancers, firewalls, and domains. Otherwise it works from your description.
2. Inspect each instance 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 vCPU/RAM tier for each instance, and a matching OS image.
4. Price every piece. It calls get_cost_estimate_vm per instance, get_cost_estimate_block_storage for volumes, and get_cost_estimate_object_storage for the Object Storage replacement — and totals them so you can compare against your own Linode bill. Nothing is billed during planning.
5. Sequence the move. It recommends starting with the smallest, lowest-risk instance 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 instance

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

Migrate the Linode instance "{instance-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. Open port 22 plus ONLY the ports the
   app actually serves (e.g. 80 and 443), restricted to the right sources. If
   the instance had a Block Storage Volume, create and attach a matching one.
   Wait until the VM is fully running and has a public IP.
3. Rebuild the software setup over SSH: install the same web server, runtime,
   and packages the instance runs, matching versions where it matters, and lay
   down my config.
4. If the instance uses a Managed Database, install the same engine
   (PostgreSQL / MySQL) 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.
5. Do an INITIAL data sync now, while the instance keeps serving traffic:
   rsync the application files and any volume data from the instance to the new
   VM.
6. 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. Port 22 (so it can SSH in for the rebuild) and the ports your app serves are opened through networkAccess.inboundPorts, which sets up the firewall rule and the port forwarding together so each port is actually reachable — a firewall rule on its own wouldn't be. It polls get_vm until the status reaches STARTED and a public IP is assigned.
2. Match the storage. If the instance had a Block Storage 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. Rebuild the software. Over SSH it installs the same stack it found during inventory — web server, runtime, packages — and applies your config.
4. 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. Your app's connection string points at localhost, and nothing new is opened on the firewall.
5. Sync the data. It rsyncs your application files and volume data from the instance to the new VM while the source stays live.
6. 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 instance, or batch the DNS changes once all instances are tested.

The new VM for "{instance-name}" tested clean. Cut DNS over to it.
 
1. First, lower the TTL on the affected DNS records at whichever host serves
   the domain today (Linode DNS, or my registrar), and wait for the old TTL to
   expire — so the cutover propagates fast. Tell me exactly what to change
   there.
2. If the database is involved, put the source app into maintenance / freeze
   writes now and keep it frozen until I decommission — do NOT bring it back up
   during propagation.
3. Do a final delta rsync from the instance so the new VM has the latest data.
4. 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.
5. Tell me how to confirm the domain now resolves to the new VM, and keep the
   old instance 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. TTLs have to drop at the host that currently answers for your domain. If that's Linode DNS or your registrar, the assistant tells you exactly which records to shorten there; it can't shorten a TTL on a host it doesn't manage. If the zone already lives on American Cloud DNS, it shortens the records with update_dns_record. And if you're 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 propagates on its own clock, so do it well ahead of cutover and create the new records with short TTLs.
2. Hold the source still. If a database is in play, the source app goes into maintenance / write-freeze at the final dump and stays frozen until you decommission. It is not brought back up during propagation, so no writes are stranded on the old server while DNS is still pointing some clients at it.
3. Final delta sync. With writes paused on the source, it runs the second rsync — only the changes since the initial pass — so the cutover loses no data.
4. 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 and map it to the VM with enable_static_nat, then point DNS at that.
5. Run both briefly, then retire. It leaves the instance running so you can roll back instantly if anything's off. After a day or two of clean operation, you delete the source on the Linode side and stop paying for it.

Migrating Object Storage

Because both services are S3-compatible, your Object Storage 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 Linode Object Storage 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 Linode Object Storage 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.

Migrating NodeBalancers

If a NodeBalancer fronts a pool of instances, the equivalent is a load balancer rule with your migrated VMs assigned as backends. Your assistant reserves a public IP, creates the rule with create_load_balancer_rule (same public/backend ports and algorithm), and assigns the new VMs with assign_vms_to_load_balancer. The full walkthrough — algorithms, health, and assigning backends — is in Load balancing with your AI assistant.

Migrating LKE (managed Kubernetes)

If you run Linode Kubernetes Engine, 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.

Backups parity

Linode Backups were tied to your instances; on American Cloud the equivalent is a snapshot of the VM volume plus a periodic dump pushed to object storage. Your assistant can take a snapshot with create_snapshot after the migration settles, and set up a scheduled database/file dump that uploads to a bucket — so you keep the same "I can roll back" safety net without the source instance. See Backups with your AI assistant for the full pattern.

Tips for a smooth move

• Start small. Move the lowest-risk instance first — a clean rehearsal on something unimportant teaches you and the assistant the rhythm before anything critical moves.
• Keep the source until you're sure. A few extra days of Linode billing buys an instant rollback path. Delete the instance only after the new VM has proven itself under real traffic.
• Always price before you build. Make "show me the cost estimate first" part of every prompt, and set the assistant's estimate next to your real Linode bill. 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

• Load balancing with your AI assistant — for your NodeBalancer pools
• Run on Kubernetes — for your LKE workloads
• Object storage with your AI assistant — the S3-compatible details for your Object Storage move
• Backups with your AI assistant — snapshots plus object-storage dumps for backup parity
• Write an AGENTS.md for your project — teach your assistant your deploy conventions so future moves are one prompt