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

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.