Moving Off AWS: Complete Migration Guide to Dedicated Servers

Moving production workloads from Amazon Web Services to an AtoZNode dedicated server can reduce costs, give you full control over the hardware, and simplify compliance. The key to a smooth transition is careful planning to avoid downtime or data loss. This guide walks you through the five essential phases—assessment, preparation, migration, validation, and cut-over—so you can move confidently.

1. Assess Your Current Environment

Begin by creating a comprehensive picture of what runs on AWS. This inventory will guide sizing and help prevent surprises.

• Inventory services: List all EC2 instances, RDS databases, ELBs, S3 buckets, and any serverless functions.
• Identify dependencies: Map network links, IAM roles, security groups, and external APIs.
• Measure usage: Record CPU, memory, disk I/O, and network throughput over a typical week. Use the data to size the new server.
• Document configuration: Capture OS versions, installed packages, and custom scripts. Tools such as aws ec2 describe-instances and aws rds describe-db-instances can export JSON for later reference.

Export the inventory to CSV or JSON; it is easy to share with your team and to compare against the AtoZNode server specifications you plan to order.

2. Choose the Right Dedicated Server

Match the server’s specifications to the peak metrics you collected. Consider these factors:

1. CPU: Select a processor that can handle your highest load spikes.
2. Memory: Allocate at least 20% more RAM than your current peak usage to accommodate growth.
3. Storage: Use SSDs for databases and high-I/O workloads; HDDs can serve archival data.
4. Bandwidth: AtoZNode offers 1 Gbps uplink on most dedicated servers, which is usually sufficient for web workloads.
5. Redundancy: If high availability is required, consider a dual-node setup with a load balancer in front.

After selecting the hardware, order the server from AtoZNode and note the IP address, root credentials, and pre-installed OS (typically Ubuntu 22.04 LTS or AlmaLinux 9).

3. Prepare the Destination Server

Set up the base OS, security, and networking before moving any data. Commands differ between Debian-based and RHEL-based distributions; both sets are shown.

3.1 Update Packages and Install Essential Tools

Debian / Ubuntu (apt)

# Refresh package lists
sudo apt update

# Apply all pending updates
sudo apt upgrade -y

# Install utilities used during migration
sudo apt install -y curl wget gnupg2 rsync net-tools

Explanation: apt update refreshes the package index. apt upgrade -y applies updates automatically. rsync will be used for file synchronization; curl and wget fetch scripts or keys.

AlmaLinux / Rocky Linux / RHEL (dnf)

# Refresh metadata and apply updates
sudo dnf -y update

# Install the same utilities
sudo dnf -y install curl wget gnupg2 rsync net-tools

Explanation: dnf -y update updates the system and automatically answers "yes" to prompts.

3.2 Harden the Server

• Create a non-root user with sudo privileges.
• Configure the firewall to allow only required ports (22 for SSH, 80/443 for web traffic, 3306 for MySQL if needed).
• Disable password authentication and enable key-based SSH login.

Debian / Ubuntu (ufw)

# Create an admin user
sudo adduser adminuser
sudo usermod -aG sudo adminuser

# Configure UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

AlmaLinux / Rocky Linux / RHEL (firewalld)

# Create an admin user
sudo adduser adminuser
sudo passwd adminuser
sudo usermod -aG wheel adminuser

# Enable firewalld and open ports
sudo systemctl enable firewalld
sudo systemctl start firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

3.3 Install the Same Software Stack

Replicate the versions of web servers, databases, and runtimes you run on AWS. For example, if you use Nginx 1.22 and PHP 8.2, install those exact versions from the official repositories or vendor packages.

4. Migrate Data and Applications

Data migration is the most critical step. Choose a method that matches the type of data you have.

4.1 File System Migration with rsync

Rsync transfers only changed blocks and preserves permissions.

From an EC2 instance (Debian/Ubuntu) to the dedicated server

# On a bastion host or your local machine
rsync -avz -e "ssh -i /path/to/key.pem" \
  ubuntu@ec2-xx-xx-xx-xx.compute-1.amazonaws.com:/var/www/html/ \
  adminuser@YOUR_DEDICATED_IP:/var/www/html/

Explanation: -a preserves attributes, -v shows progress, -z compresses data, and -e specifies the SSH key.

4.2 Database Migration

Use logical dumps for MySQL/MariaDB or PostgreSQL, then import them on the new server. For large databases, consider native backup tools such as pg_basebackup or Percona XtraBackup.

MySQL/MariaDB (Debian/Ubuntu)

# Export from AWS RDS
mysqldump -h your-rds-endpoint.amazonaws.com -u admin -p --single-transaction \
  --quick your_database > /tmp/your_database.sql

# Transfer the dump
scp -i /path/to/key.pem /tmp/your_database.sql adminuser@YOUR_DEDICATED_IP:/tmp/

# Import on the dedicated server
mysql -u root -p
CREATE DATABASE your_database;
EXIT
mysql -u root -p your_database < /tmp/your_database.sql

PostgreSQL (AlmaLinux/Rocky/RHEL)

# Export from AWS RDS
pg_dump -h your-rds-endpoint.amazonaws.com -U admin -Fc your_database > /tmp/your_database.dump

# Transfer the dump
scp -i /path/to/key.pem /tmp/your_database.dump adminuser@YOUR_DEDICATED_IP:/tmp/

# Restore on the dedicated server
sudo -iu postgres
createdb your_database
pg_restore -d your_database /tmp/your_database.dump

4.3 Application Configuration

Copy environment files (.env, config.yaml, etc.) and replace any hard-coded AWS endpoints with the new server’s IP or DNS name. Update DNS records only after you have confirmed the application works locally.

5. Validate the New Environment

Testing before cut-over prevents surprises in production.

1. Functional tests: Run automated tests or manually exercise key user flows.
2. Performance checks: Use ab or wrk to generate load and compare response times with the AWS baseline.
3. Security scan: Run nmap and lynis to ensure only intended ports are open and no default credentials remain.
4. Failover rehearsal: Edit your local /etc/hosts file to point the domain to the dedicated server’s IP and verify everything works.

Document any discrepancies and resolve them before proceeding to the final cut-over.

6. Cut Over and Decommission

When the new environment is stable, perform the final switch.

1. Update DNS: Change the A record to point to the dedicated server’s IP. Reduce the TTL a day before the move to speed propagation.
2. Monitor traffic: Watch logs, error rates, and latency for at least an hour after the DNS change.
3. Graceful shutdown of AWS resources: Stop EC2 instances and RDS databases only after traffic has fully migrated.
4. Backup retention: Keep snapshots of the AWS resources for a week in case rollback is needed.
5. Update documentation: Record the new IP addresses, credentials, and any changes made during migration.

After a few days of smooth operation, you can safely terminate the AWS services and stop incurring those costs.

Conclusion

Moving production workloads from AWS to an AtoZNode dedicated server requires meticulous inventory, careful sizing, systematic preparation, and thorough testing. By following this step-by-step approach, you can achieve a low-risk migration while retaining full control over your hardware and configuration. The same methodology applies to future migrations or scaling projects.