Start with the workload profile
Record users, requests per second, background jobs, database size, working set, storage growth and the busiest hour. A web server, database, VPN gateway and mail relay can need very different resource ratios.
CPU: look for sustained saturation
Short CPU bursts are normal. Size up when the application remains CPU-bound, queueing grows or latency rises under known load. Also inspect steal time and hypervisor ready time when available; adding vCPU can make scheduling worse on an overloaded host.
RAM: protect the working set
Memory should cover the operating system, application and useful cache without sustained swapping. Database buffer pools and Java heaps must leave room for the rest of the system.
Storage: capacity is only one dimension
Track free space, IOPS, throughput and latency. Databases are usually sensitive to random-write latency, while backups and media transfers can be throughput-heavy. Thin provisioning and snapshot chains also affect risk.
Network: measure from real users
Use the browser latency test from each important office or VPN exit. Then test the actual application because TLS, queries and payload size matter beyond raw round-trip time.
Reserve recovery headroom
Growth, restore operations and failover all need spare capacity. Define backup destination, retention, maximum acceptable data loss and recovery time before selecting the final plan.