How to Migrate Your Business to Bare Metal: A 5-Step Guide

Why Go Bare Metal?

Cloud providers charge 2-5x premiums for virtualization overhead. For steady-state workloads, bare metal delivers:

40-60% cost savings vs AWS/EC2 equivalent configurations
Full hardware isolation — no noisy neighbours, no CPU steal time
Direct NVMe/GPU passthrough — maximum I/O performance
Custom BIOS/firmware control — tune the server to your workload
Predictable pricing — fixed monthly cost, no surprise bills

At Hostingowy, we help businesses migrate from cloud to bare metal every week. This guide covers the exact process we use to ensure zero-downtime migrations.

Step 1: Audit Your Current Workload

Before you migrate, you need to understand what you're running. Run a thorough inventory:

Compute Requirements

Average CPU utilisation (peak and baseline)
Memory usage patterns — is your application memory-bound or CPU-bound?
Disk I/O — random read/write vs sequential throughput needs
Network throughput — average and peak bandwidth consumption

Use tools like htop, vmstat, iostat, and nload to gather baseline metrics over a 14-day period. This data drives your bare metal server specification.

Cloud-Specific Dependencies

Identify services tied to your cloud provider's ecosystem:

Managed databases (RDS, Cloud SQL, etc.)
Load balancers (ALB, ELB, etc.)
Object storage (S3, GCS, etc.)
DNS and CDN configurations
IAM roles and service accounts
Monitoring and logging services
Auto-scaling groups and launch templates

Each of these needs a replacement strategy. Managed databases can run directly on the bare metal server or split to a dedicated DB server. Object storage can be replaced with MinIO or Wasabi. Monitoring can use Prometheus + Grafana.

Step 2: Design Your Bare Metal Architecture

With your audit complete, design the target architecture:

Single Server vs Cluster

	Single Bare Metal	Multi-Server Cluster
Best for	Monolithic apps, startups, <$3k/mo spend	Microservices, HA requirements, >$3k/mo spend
Complexity	Low — one server to manage	Higher — orchestration, networking, load balancing
HA	Limited — single point of failure	Full — N+1 redundancy
Cost	Lower — one server	Higher — 2+ servers

Storage Architecture

We recommend ZFS on bare metal for its built-in compression, snapshots, and data integrity features. For database workloads, dedicate NVMe drives for the database and separate HDDs or SSDs for bulk storage.

Networking

Plan for VLAN segmentation, firewall rules, and load balancing. HAProxy or Nginx handle L7 load balancing. For high availability, use BGP with keepalived for IP failover between two bare metal servers.

Step 3: Provision and Harden Your Bare Metal Server

With Hostingowy, provisioning takes under 15 minutes. Here's what we recommend for the initial setup:

Choose your OS — Ubuntu 24.04 LTS or Debian 12 for most workloads. Rocky Linux for RHEL compatibility.
Configure storage — Partition with ZFS pools. Separate datasets for OS, applications, databases, and logs.
Harden SSH — Key-only authentication, disable root login, use a non-standard port.
Set up a firewall — Allow only necessary ports (22, 80, 443, and your application ports).
Install monitoring — Node Exporter + Prometheus, or our built-in monitoring dashboard.
Configure backups — ZFS snapshots + off-server replication. We recommend 3-2-1 backup strategy.

Step 4: Migrate Data and Applications

With the server ready, it's migration time. We use a phased approach:

Phase 1: Database Migration (Low Risk)

Set up PostgreSQL or MySQL replication from your cloud provider to the new bare metal server. Let replication catch up, then cut over. For smaller databases (<100GB), a pg_dump followed by restore works well.

# PostgreSQL replication example
pg_dump -h source-db.example.com -U user -Fc dbname > db.dump
pg_restore -d dbname -j 4 db.dump

Phase 2: Application Migration (Zero Downtime)

Deploy your application to the bare metal server alongside the cloud instance. Use a load balancer in front that directs 10% of traffic to the new server. Monitor for errors, latency, and resource usage. Ramp up traffic by 10-20% increments every 15 minutes until 100% is on the new server.

Phase 3: Storage and Static Assets

Migrate static assets using rsync or rclone. If you're using S3, switch to MinIO with S3-compatible API — your application code doesn't need to change.

Step 5: Decommission and Optimise

After a 7-day burn-in period with all traffic on the new server:

Verify performance — Compare latency, throughput, and error rates against your baseline metrics.
Shut down cloud instances — Stop, then terminate. Verify no data remains.
Cancel managed services — RDS, load balancers, and other add-ons.
Optimise the new server — Tune kernel parameters, ZFS ARC size, and application configs.
Document the architecture — For the next team member or emergency recovery.

Cost Savings: Real Example

One of our customers was running a PostgreSQL-heavy SaaS on AWS with the following monthly bill:

Service	AWS (Before)	Hostingowy (After)
Compute (4 vCPU, 32GB)	$1,200	$799/mo total
Managed DB (2 vCPU, 16GB)	$850	$799/mo total
Storage (2TB NVMe)	$600 (EBS gp3)	Included
Data transfer (5TB)	$450	Included
Total	$3,100	$799

That's 74% cost reduction. Their performance actually improved — database queries ran 30% faster on bare metal NVMe vs EBS gp3.

Common Pitfalls to Avoid

Underestimating storage — Buy more NVMe than you think you need. Storage is cheap; downtime to add more is expensive.
Skipping the burn-in period — Run for at least 7 days with both environments live before cutting over completely.
Ignoring backup strategy — Bare metal doesn't have automatic snapshots like cloud. Set up ZFS snapshots + off-site replication before going live.
Forgetting monitoring — You lose CloudWatch. Set up Prometheus + Grafana before the migration.

How Hostingowy Helps

Every Hostingowy bare metal server comes with:

Free migration assistance — Our engineers help plan and execute your migration
3-day cancellation — Try bare metal risk-free. If it doesn't work, cancel within 3 days.
24/7 UK engineer support — Real people who understand infrastructure, not a chatbot
ZFS + NVMe standard — Enterprise storage on every server