How to Migrate Your Docker Server to a New Host

Migrating a Docker server doesn’t have to be scary. With a short plan, clean backups, and a careful cutover, you can migrate docker to new host smoothly and predictably. This guide focuses on Linux hosts running Docker Engine and Compose, and keeps jargon to a minimum.

1) Plan the move

Decide what you’re moving: images, Compose files, environment files, secrets, and data in volumes or bind mounts. Note which containers can be recreated from images and which keep critical state. Define your acceptable downtime. If you must move docker containers to another host with minimal interruption, schedule a short maintenance window and prepare a rollback.

2) Back up data and configuration

Your data lives outside containers. Export database dumps (MySQL/MariaDB/Postgres), copy application configs, and back up docker volumes before touching anything. Stop write-heavy services briefly to avoid dirty snapshots. Keep a simple inventory: container name, image tag, data path, ports, and linked services. Store .env and Compose files in version control or at least alongside the backups.

3) Transfer images the safe way

You don’t need a registry if your network is locked down. To transfer docker images to another server, use a TAR stream over SSH. On the old host:

# Save one image
docker save myapp:1.4 | gzip > myapp_1.4.tar.gz

# Or save multiple images
docker save myapp:1.4 redis:7-alpine nginx:1.27 | gzip > bundle_images.tar.gz

Move the archive with scp/rsync, then load on the new host:

gzip -dc bundle_images.tar.gz | docker load

That’s the classic docker save and load path: reliable, simple, and fast over a LAN.

If you must capture a container’s current filesystem layer (not recommended for state), there’s also docker export and import — useful for ad-hoc recovery, not as a general migration strategy.

4) Move Compose and env files

Copy your docker-compose.yml files, override files, and .env exactly as they are. Keep directory structure identical so relative volume paths still resolve. Start with a dry run:

docker compose config

Use this section to incorporate docker compose migration practices: verify services, networks, and volumes resolve correctly before you bring containers up.

5) Migrate volumes cleanly

For named volumes, create a temporary container to tar the data, or sync host paths if you use bind mounts. Example with tar:

# On old host
docker run --rm -v mydata:/data -v $(pwd):/backup alpine \
  sh -c "cd /data && tar -czf /backup/mydata.tar.gz ."

Copy the archive to the new host, create the volume, then restore:

docker volume create mydata
docker run --rm -v mydata:/data -v $(pwd):/backup alpine \
  sh -c "cd /data && tar -xzf /backup/mydata.tar.gz"

Prefer rsync when the dataset is large and you want incremental copy. Do one quiet final sync with containers stopped to catch deltas. If you need a search phrase for your checklist, rsync docker volumes sums it up neatly.

6) An alternative many ask about

Some teams copy docker’s internal store between machines. Only consider this when the OS, Docker version, CPU architecture, and storage driver match. If you go down that road, understand the risks and test on a throwaway VM first. If you must, the phrase to remember is transfer /var/lib/docker — but again, this is advanced and fragile compared to restoring from images and volume backups.

Also Read: How to Check The .NET Framework Version

7) Networking, DNS, and TLS

Recreate any custom networks and open the same ports. If you reverse proxy traffic, bring the proxy up first so backends register cleanly. After the new stack is healthy, update DNS A record to the new host’s IP. If your edge is Nginx, keep the same server_name and cert paths so reverse proxy with Nginx works without surprises. For HTTPS, issue or copy Let’s Encrypt SSL certificates carefully; many setups re-request certificates automatically once DNS points to the new host.

If you prefer remote control, you can manage the target using docker context over SSH and run compose commands from your laptop.

8) Cutover without pain

Bring up dependencies first (databases, caches), then apps, then the proxy. Validate health endpoints and logs. For teams that need zero downtime migration, run both stacks in parallel behind the proxy and drain traffic container by container with short TTLs in DNS or weighted rules in your load balancer.

9) Validate and clean up

Run smoke tests: can you log in, write to the database, upload a file, and see it persist after a container restart? If anything fails, you already know how to restore docker from backup. When satisfied, decommission the old host: stop containers, revoke credentials, and archive the final backups.

Quick command recap

• Images: docker save → move file → docker load
• Volumes: tar via a helper container, or rsync with a quiet final sync
• Compose: copy yaml + .env → docker compose up -d
• DNS: lower TTL, cut over, raise TTL later

Conclusion

You don’t migrate containers; you recreate them from images and move the data they depend on. Back up volumes, move images, copy your Compose and env files, rehearse once, and your cutover will be boring — which is exactly what you want when production is on the line. If you need to copy docker containers to new server in a hurry, follow the same principle: images first, data second, verify, then switch.

Note: commands and behaviors align with Docker’s docs for image save/load, container export/import, volumes backup/restore, and contexts.

FAQs

1) What’s the difference between save/load and export/import?
Save/load handles images exactly (layers, metadata, tags). Export/import flattens a container’s current filesystem into a tar, losing history and some metadata. Use save/load for normal migrations; use export/import only for one-off recovery.

2) Can I move a running container?
No. Stop it or recreate it elsewhere from the image. Copy or restore the data volume, then start fresh on the new host.

3) Is copying /var/lib/docker a good idea?
Usually not. It’s brittle across different storage drivers or versions. Restoring images and volumes is safer and more portable; if you attempt it, make sure the environments match perfectly and test first.