Moving Off AWS: Migrate Production Workloads to Dedicated Servers

Moving production workloads from Amazon Web Services (AWS) to a dedicated server can reduce costs, give you full control over hardware, and simplify compliance. This guide walks you through the necessary steps—assessment, preparation, data migration, cut‑over, and post‑migration validation—so you can transition smoothly to a dedicated server hosted by AtoZNode.

1. Assess Your Current AWS Environment

Begin by documenting everything that runs on AWS. The inventory you create will drive sizing, networking, and security decisions for the new server.

• Compute: List EC2 instance types, attached EBS volumes, and any auto‑scaling groups.
• Storage: Identify S3 buckets, RDS databases, ElastiCache clusters, and EFS mounts.
• Networking: Record VPC CIDR blocks, security groups, load balancers, and Route 53 DNS records.
• Dependencies: Note external services such as SNS, SQS, or third‑party APIs.

You can export the information with the AWS CLI. For example, to list EC2 instances:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,State:State.Name}' \
  --output table

Save the output to a file; you will refer to it during planning.

2. Size and Provision Your Dedicated Server

Use the inventory to choose a configuration that matches or exceeds current usage. AtoZNode offers a variety of CPU, RAM, storage, and bandwidth options. Consider the following guidelines:

• Allocate at least 20% more CPU cores than the total EC2 vCPUs.
• Match total RAM, then add a 2–4 GB buffer for the OS.
• Prefer SSD storage for databases and high‑I/O workloads; use RAID 1 for redundancy if needed.
• Ensure the network interface supports the bandwidth you consume (e.g., 1 Gbps or 10 Gbps).

Order the server via the AtoZNode portal and record the IP address, root credentials, and any KVM or console access information.

3. Prepare the Destination Server

Once the hardware is ready, install the operating system and required software. The steps below cover both Debian/Ubuntu (apt) and AlmaLinux/Rocky/RHEL (dnf) families. Adjust the version numbers if you use a different release.

3.1. Install Base Packages

Debian / Ubuntu (apt)

# Update package index and upgrade existing packages
apt update && apt upgrade -y

# Install common tools
apt install -y curl wget git vim htop ufw

AlmaLinux / Rocky / RHEL (dnf)

# Update the system
dnf update -y

# Install common tools
dnf install -y curl wget git vim htop firewalld

3.2. Configure Firewall

Open only the ports required by your applications. Example configurations for ufw (Debian/Ubuntu) and firewalld (RHEL‑family):

# Debian/Ubuntu (ufw)
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

# AlmaLinux/Rocky/RHEL (firewalld)
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

3.3. Set Up Time Synchronization

Accurate time is essential for logs and SSL certificates.

# Both families
timedatectl set-timezone Asia/Kolkata
timedatectl enable-ntp

3.4. Create Application Users

Run each service under its own non‑root user for security.

# Example for a web app user
adduser --system --home /var/www/myapp --shell /bin/bash myapp

4. Transfer Data and Applications

Data migration is the most critical part of the move. Choose a method that matches the type of data you’re moving.

4.1. File‑Based Data (S3, EFS, Static Assets)

Use aws s3 sync to copy objects to the new server, then serve them locally or from a CDN.

# Install AWS CLI
apt install -y awscli          # Debian/Ubuntu
dnf install -y awscli          # AlmaLinux/RHEL

# Sync an S3 bucket to /var/www/assets
aws s3 sync s3://my-bucket/assets /var/www/assets --delete

For EFS, mount the file system on the source instance, copy the files with rsync, and then unmount.

# Example rsync command (run on the source EC2)
rsync -avz -e "ssh -i /path/to/key.pem" /mnt/efs/ user@DEST_IP:/var/www/efs-data/

4.2. Database Migration (RDS → Local MySQL/PostgreSQL)

Export the database to a dump file, transfer it securely, then import it on the dedicated server.

# On the AWS side (MySQL example)
mysqldump -h $RDS_ENDPOINT -u $RDS_USER -p$RDS_PASSWORD \
  --single-transaction --quick mydb > mydb.sql

# Secure copy to the destination server
scp -i /path/to/key.pem mydb.sql root@DEST_IP:/tmp/

# On the destination server (install MySQL first)
apt install -y mysql-server          # Debian/Ubuntu
dnf install -y mysql-server          # AlmaLinux/RHEL

# Import the dump
mysql -u root -p < mydb.sql

For PostgreSQL, replace mysqldump with pg_dump and use psql to restore.

4.3. Application Code

Clone repositories directly on the new server or copy archives. Ensure the same runtime (Node.js, PHP, Python, etc.) versions are installed.

# Example for a Node.js app
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -          # Debian/Ubuntu
dnf module install -y nodejs:20                                 # AlmaLinux/RHEL

git clone https://github.com/yourorg/yourapp.git /var/www/yourapp
cd /var/www/yourapp
npm ci
npm run build   # if applicable

5. Cut Over Traffic to the Dedicated Server

Once data and code are in place, switch production traffic. Follow these steps to minimize disruption.

1. Test locally. Verify the application works by accessing the server’s IP or a temporary hostname in /etc/hosts.
2. Update DNS. Change the A record in your DNS provider (or Route 53) to point to the new IP. Reduce the TTL to 300 seconds a day before the move so the change propagates quickly.
3. Monitor. Keep the old EC2 instances running for at least one monitoring window (e.g., 30 minutes) and watch logs, error rates, and response times.
4. Rollback plan. If critical issues appear, revert the DNS record to the old IP and investigate before trying again.

6. Post‑Migration Validation and Optimization

After traffic is flowing to the dedicated server, perform a thorough check to confirm everything is healthy.

• Log aggregation. Forward syslog or application logs to a central system (e.g., Graylog, ELK) for visibility.
• Performance tuning. Adjust MySQL innodb_buffer_pool_size, PHP‑FPM workers, or JVM heap based on observed load.
• Backup strategy. Set up regular snapshots (e.g., using rsnapshot or borg) and test restore procedures.
• Security hardening. Disable password authentication for SSH, enable key‑based login only, and run fail2ban or equivalent.

Finally, decommission the AWS resources you no longer need. Double‑check that no lingering services (e.g., unused Elastic IPs, orphaned EBS volumes) remain, as they can incur charges.

Conclusion

Migrating production workloads from AWS to a dedicated server requires disciplined planning, accurate inventory, and careful execution of data transfer steps. By following the six sections above—assessment, provisioning, preparation, data migration, cut‑over, and post‑migration validation—you can achieve a smooth transition while maintaining service continuity for your users. AtoZNode’s dedicated infrastructure provides the control and predictability many Indian businesses need, and with the procedures outlined here, you’ll be ready to make the move confidently.