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

#webdev #programming #devops #beginners

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.