How to Migrate from AWS to VPS: Step-by-Step Guide (2026)

AWS is the dominant cloud provider, but for many UK businesses it's overkill. The complexity of VPCs, IAM roles, 150+ service types, and unpredictable billing creates a tax on engineering time. Worse, your data ends up subject to US jurisdiction under the CLOUD Act, even when using London-based data centres.

Migrating from AWS to a UK VPS can cut your infrastructure costs by 40-60% while giving you simpler operations and genuine UK data residency. Here's exactly how to do it.

Why Migrate from AWS to a VPS?

Before we dive into the how, let's be honest about the why:

Factor	AWS EC2	UK VPS (e.g. Hostingowy)
Monthly cost (4 vCPU, 8 GB)	$60-100/mo (depends on reserved vs on-demand)	$25-35/mo
Data transfer	$0.09/GB egress (first 100 TB)	Included — no egress fees
Data residency	US parent company (CLOUD Act applies)	UK jurisdiction only
Management overhead	VPC, subnets, security groups, IAM, NACLs	SSH in, configure, done
Billing predictability	Low — 150+ services, each metered separately	High — flat monthly rate
Provisioning speed	Minutes (sometimes seconds)	Under 60 seconds

The simplicity advantage is real. A VPS gives you a clean Linux environment with a public IP, and you decide what runs on it. No hidden services, no surprise bills, no vendor lock-in.

Step 1: Pre-Migration Assessment

Before touching any infrastructure, audit what you're running on AWS:

1. Inventory EC2 instances — note instance types, attached volumes, AMIs, security groups
2. Map your RDS databases — engine type, size, connections, backup policies
3. List S3 buckets — sizes, lifecycle rules, access patterns
4. Document networking — VPC CIDR, subnets, route tables, VPN connections
5. Review IAM roles and policies — who has access to what
6. Check CloudWatch alarms and logs — what monitoring do you rely on?
7. Identify dependencies — Lambda triggers, SQS queues, SNS topics

Most applications don't need the full AWS ecosystem. If your app is a web service with a PostgreSQL database and an S3-compatible object store, you can replicate that on a VPS with PostgreSQL and MinIO — often with significantly better performance.

Step 2: Provision Your Target VPS

Choose a VPS provider that meets your requirements. For UK businesses, key considerations are:

• Data centre location — London-based for lowest latency to UK users
• Storage — NVMe for database workloads (4-6x faster than SATA SSD)
• Bandwidth — included, no metered egress
• Snapshots — free, instant snapshots for pre-migration safety nets
• Migration support — some providers offer free assisted migration

Provision your VPS with your chosen OS (Ubuntu 22.04 LTS or Debian 12 are good choices for most workloads). Take a snapshot immediately — this is your rollback point.

Quick provisioning: With Hostingowy, your server is deployed in under 60 seconds. You get root SSH access, a public IP, and NVMe storage — no VPCs, no subnets, no security group wizard.

Step 3: DNS Planning

Plan your DNS strategy before you move any data. The goal is zero downtime, which means:

• Keep your existing DNS records pointing to AWS during the data migration phase
• Set low TTL (60-300 seconds) on the records you'll be switching — do this 24-48 hours before cutover
• Spin up your VPS with all services configured but not yet serving production traffic
• Run both environments in parallel during validation
• Switch DNS at cutover and monitor

If you're using Route53, you can export the zone file and import it into a new DNS provider. Most UK VPS providers include DNS management or you can use a dedicated DNS service like Cloudflare.

Step 4: Migrate Application Data (EC2 → VPS)

4.1 File and Application Migration with rsync

rsync is the gold standard for efficient file transfer. It's incremental, supports resumable transfers, and preserves permissions:

# From your AWS EC2 instance (as root):
# First, do a dry run to see what would be transferred
rsync -avz --dry-run --progress /var/www/ user@your-vps-ip:/var/www/

# Then the real sync (this can run while the app is still live)
rsync -avz --progress -e 'ssh -p 22' /var/www/ user@your-vps-ip:/var/www/

# For large datasets, run in a screen/tmux session
# Final sync with delete (after app is in read-only mode):
rsync -avz --delete --progress -e 'ssh -p 22' /var/www/ user@your-vps-ip:/var/www/

4.2 Database Migration (RDS → PostgreSQL/MySQL on VPS)

For PostgreSQL databases on RDS:

# Dump the database (compressed)
pg_dump -h your-rds-endpoint.rds.amazonaws.com -U your_user your_db | gzip > db_dump.sql.gz

# Transfer to VPS
scp db_dump.sql.gz user@your-vps-ip:~/

# On the VPS, restore
gunzip -c db_dump.sql.gz | psql -U new_user your_new_db

# For zero-downtime with replication:
# Set up PostgreSQL logical replication between RDS and VPS
# This is more complex but avoids any cutover window

For MySQL/MariaDB on RDS:

# Dump
mysqldump -h your-rds-endpoint.rds.amazonaws.com -u your_user -p your_db | gzip > db_dump.sql.gz

# Transfer and restore on VPS
scp db_dump.sql.gz user@your-vps-ip:~/
gunzip -c db_dump.sql.gz | mysql -u new_user -p your_new_db

4.3 Object Storage (S3 → MinIO or S3-compatible)

If you have S3 buckets with application data (uploads, assets, backups):

# Using aws-cli to sync to MinIO on your VPS
# First install MinIO on your VPS (docker or native)
docker run -d -p 9000:9000 -p 9001:9001 \
  -v /data/minio:/data \
  -e MINIO_ROOT_USER=admin \
  -e MINIO_ROOT_PASSWORD=your-secure-password \
  minio/minio server /data --console-address ":9001"

# Sync from S3 to MinIO using aws-cli (configure both endpoints)
aws s3 sync s3://your-bucket/ http://your-vps-ip:9000/your-bucket/ --endpoint-url https://s3.eu-west-2.amazonaws.com

Alternatively, if you want to keep using AWS S3 from your VPS, that works too — S3 is accessible over the public internet. Just update your SDK configurations.

Step 5: Configure Web Server and SSL

Install Nginx or Apache on your VPS and configure your virtual hosts:

# Install Nginx on Ubuntu/Debian
apt update && apt install -y nginx certbot python3-certbot-nginx

# Create your site configuration
cat > /etc/nginx/sites-available/your-site.com << 'EOF'
server {
    listen 80;
    server_name your-site.com www.your-site.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name your-site.com www.your-site.com;

    root /var/www/your-site/public;
    index index.php index.html;

    ssl_certificate /etc/letsencrypt/live/your-site.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-site.com/privkey.pem;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}
EOF

# Enable the site and get SSL
ln -s /etc/nginx/sites-available/your-site.com /etc/nginx/sites-enabled/
certbot --nginx -d your-site.com -d www.your-site.com
nginx -t && systemctl reload nginx

Step 6: DNS Cutover

With your VPS fully configured, applications running, and SSL certificates in place, it's time for the cutover:

1. Lower TTLs on your DNS records to 60 seconds (do this 24-48 hours before)
2. Put the old server in read-only mode — this prevents data divergence
3. Run a final rsync to catch any data written during the migration
4. Update DNS A records to point to your VPS IP
5. Wait for propagation (typically 5-15 minutes with low TTL)
6. Verify everything works — test from multiple networks
7. Keep old server running for at least 24 hours as a rollback option

Step 7: Post-Migration Checklist

After the cutover, run through this checklist before decommissioning your AWS infrastructure:

Item	Check
All HTTP/HTTPS responses 200	✅
Database connections working	✅
File uploads writing correctly	✅
Email delivery functioning	✅
Cron jobs executing	✅
SSL certificates valid	✅
DNS propagated globally	✅
Monitoring and alerting active	✅
Backups configured and tested	✅
Firewall rules applied (UFW/iptables)	✅
Keep old server for 48h rollback	✅

Cost Comparison: AWS vs UK VPS

Here's a real-world comparison for a typical UK SaaS application serving 100K monthly visitors:

Service	AWS EC2 Equivalent	UK VPS (Hostingowy)
Compute (4 vCPU, 8 GB)	$69.12/mo (t3.xlarge, reserved)	$35/mo (VPS-4)
Storage (100 GB SSD vs NVMe)	$10/mo (gp3, 3000 IOPS)	$0 (included + NVMe)
Data transfer (1 TB/mo)	$90/mo (first TB egress at $0.09/GB)	$0 (included)
Database (50 GB PostgreSQL)	$45/mo (db.t3.medium)	Runs on same VPS ($0 extra)
Snapshots/backups	$12/mo (automated snapshots)	$0 (ZFS snapshots included)
NAT gateway	$32.40/mo (if using private subnets)	$0 (public IP direct)
Total (monthly)	$258.52/mo	$35/mo

Annual savings: over $2,600 — and that's before accounting for the engineering time saved by not managing AWS complexity.

When to NOT Migrate from AWS

AWS remains the right choice in certain scenarios:

• You need global multi-region deployment with CDN integration (CloudFront)
• You heavily use managed services like Lambda, DynamoDB, SQS, or ElastiCache
• You need auto-scaling across multiple regions with complex load balancing
• Your compliance framework specifically requires AWS (e.g., GovCloud)

But for most UK SaaS companies, e-commerce stores, and agencies running standard web applications, a VPS provides better value and simpler operations.