██FR█████ █INTELL███████████

Before You Migrate: Basic Steps to Take Before Moving a Server


This content originally appeared on DEV Community and was authored by Athreya aka Maneshwar

Hello, I’m Maneshwar. I’m building LiveReview, a private AI code review tool that runs on your LLM key (OpenAI, Gemini, etc.) with highly competitive pricing — built for small teams. Do check it out and give it a try!

Moving a server — whether it’s to a new VM, a different provider, or fresh hardware — feels simple until something goes wrong.

A missing backup, an overlooked DNS TTL, or an untested restore can turn a routine migration into an outage.

Here are the essential steps you should always take before moving a server.

1. Take Verified Backups

  • Full system backup: Image or snapshot the disk (provider snapshots, rsync, dd, or tools like Velero if Kubernetes).
  • Service-level backups: Dump databases (pg_dump, mysqldump), export configs (tar /etc/), and archive important app data.
  • Verify: Try restoring a database dump or untar an archive on a test VM. A backup isn’t real until you can restore it.

2. Inventory What’s Running

  • List services: systemctl list-unit-files --type=service | grep enabled
  • Installed packages: dpkg --get-selections > packages.list (Debian/Ubuntu) or rpm -qa > packages.list (RHEL).
  • Custom configs: Identify changes in /etc/, crontabs, and application config files.
  • Dependencies: Make note of external services (SMTP, S3, APIs, OAuth providers).

3. Prepare DNS & Networking

  • Lower DNS TTLs (e.g., 300 seconds) at least 24–48h before migration, so you can flip traffic quickly.
  • Check firewall rules on the new server (ports, UFW, security groups).
  • Plan rollback: Know how to switch DNS or proxy settings back if needed.

4. Secure Credentials & Access

  • Collect SSH keys, tokens, passwords stored safely (preferably in a password manager or secret store).
  • Test that you can log in to the new server with proper user permissions.
  • Disable root logins via password on the new host before making it public.

5. Dry Run on the New Host

  • Clone the environment: Create the same users, packages, configs, and mount points.
  • Migrate data: rsync -avz --progress to copy over, ideally using snapshots or with minimal downtime.
  • Smoke test: Start the main services (e.g., database, web server, API) and confirm they respond.

6. Document Everything

  • Write down the old → new mapping (hostnames, IPs, services).
  • Note the migration steps and commands used.
  • Keep track of any workarounds or fixes you applied during the move — you’ll thank yourself later.

7. Rollback Plan

  • If something fails, you should be able to:

    • Point DNS back to the old server.
    • Re-enable the old VM/service.
    • Restore backups in minutes, not hours.

Checklist Before Hitting “Switch”

  • [ ] Verified backups exist and are restorable
  • [ ] DNS TTL lowered
  • [ ] All configs/services inventoried
  • [ ] New server tested and secure
  • [ ] Rollback plan ready

🔑 Takeaway: A smooth migration is about preparation, not speed. Backups + documentation + rollback = confidence.

LiveReview helps you get great feedback on your PR/MR in a few minutes.

Saves hours on every PR by giving fast, automated first-pass reviews.

If you’re tired of waiting for your peer to review your code or are not confident that they’ll provide valid feedback, here’s LiveReview for you.


This content originally appeared on DEV Community and was authored by Athreya aka Maneshwar