Most projects start on a VPS, and many should stay there. It is cheap, quick to resize and good enough for a surprising amount of traffic. But there comes a point when the shared host starts to show. Builds slow down at odd hours, databases stall under load, and you spend more time tuning around the limits than working on the product. This checklist covers how to tell when that moment has arrived and how to make the move without a painful weekend.
Check that the hardware is really the problem
Before paying for a bigger machine, measure the one you have. Look at CPU steal time with top or vmstat: a steady non-zero value means other tenants are taking cycles from you. Use iostat -x to see disk latency. Use your application’s slow query log to find out whether one missing index is responsible for the whole problem.
A dedicated server won’t fix an N+1 query. It will fix noisy neighbours, inconsistent disk performance and memory ceilings.
Size the server from real numbers
Take peak CPU, memory and disk figures from the last few weeks, then add room for growth. Think about each resource separately:
- CPU: high clock speeds suit single-threaded workloads, while many cores suit containers and parallel builds.
- Memory: databases benefit the most, because data served from RAM avoids the disk.
- Storage: NVMe or SSD for databases, large HDDs for archives and backups.
- Network: check both the port speed and the monthly traffic included. A 1 Gbps port with 30 TB of traffic is a continuous average of about 92 Mbps.
Decide where the server should live
Latency is the obvious factor, so measure it from where your users are. Jurisdiction matters as well, and developers often leave it too late. If you process personal data of EU residents, talk to whoever handles compliance before choosing a location, since the rules follow the data and the company as well as the server. Some teams want a server inside the EU. Others have a reason to host outside it, closer to users in Eastern Europe or under a different legal framework. Either way, read the provider’s acceptable use policy, because it applies wherever the server is located.
As an example of what to look for, IPHOST publishes these details for its dedicated servers in Chișinău, Moldova, which is outside the EU: its own ISO/IEC 27001:2022-certified data center, Intel Xeon and AMD EPYC machines with 6 to 128 cores and 32–512 GB of RAM, SSD, NVMe or HDD storage, a 1 Gbps port with 30 TB of monthly traffic, and DDoS protection. Whichever host you compare, these are the numbers to ask for.
Prepare the new machine before moving anything
A bare server has no defaults that you should trust. Before any data arrives:
- Update the operating system and enable automatic security updates.
- Create a non-root user, use SSH keys and disable password login.
- Configure a firewall that opens only the ports you need.
- Check the RAID status and the health of the disks with smartctl.
- Set up monitoring and alerts for disk space, memory and failed services.
- Configure off-server backups, then restore one to prove that it works.
Point 6 is the one people skip. On a VPS the provider may have offered snapshots with one click. On physical hardware, a failed disk is your problem unless you planned for it.
Migrate with a rollback plan
Lower the DNS TTL a day or two in advance. Copy files with rsync, repeat the sync to shrink the final difference, and use replication for the database if you can’t afford much downtime. Test the new server through your local hosts file before changing public DNS. Keep the old VPS running for at least a week after the switch, since it is the cheapest insurance you will ever buy.
After the move
Run the same measurements you took at the start. If latency and throughput haven’t improved, find out why while the old server is still available. Review the new monthly costs too. A dedicated server pays off when it replaces several VPS instances or removes a limit that was costing you real time, and it is an expensive habit when it doesn’t.
