ERP Server Sizing Calculator for On-Premise and Private Cloud
Sizing an ERP server is an exercise in ratios: how many people use it at once, how much CPU and memory each session needs, how large the database will become and how much headroom you want. This calculator makes those assumptions explicit so you can discuss them with the ERP vendor and your infrastructure team.
Your numbers
Total licensed or active ERP users.
Share of named users active at the busiest hour. Office ERP is often 30 to 50%, shop floor terminals can be higher.
Take this from your ERP vendor sizing guide or from measured load. Heavy reporting lowers it.
Database CPU demand depends on queries and batch jobs. Use vendor guidance or measurement.
Session and process memory per active user.
Operating system, agents and ERP services that run regardless of load.
How much of the database you want cached in RAM. 10 to 30% is a common range for transactional ERP.
Covers transaction logs, tempdb, indexes and local backup staging on top of data size.
Your results
This is a planning estimate based on ratios you supply. Always validate against the ERP vendor's sizing guide and a load test before buying hardware or committing to licenses.
Cores needed vs named users
Sweeps Named users from 50 to 2000, holding your other inputs fixed.
Optional sizing sanity check
Send your exported assumptions and we will comment on whether they look realistic for your ERP and workload.
Optional. The tool and every export work without this. No spam.
How to use the calculator
Start with named users and your realistic peak concurrency. Replace the default users-per-core figures with numbers from your ERP vendor's sizing guide or from monitoring on the current system. If you are migrating, use the current peak CPU and memory, not the average. Then set database size, annual growth and a planning horizon of three to five years. Headroom covers month-end close, payroll runs and MRP. Export the result as the first page of an infrastructure request.
- Use measured peaks from the existing system when you have them
- Size month-end, not a quiet Tuesday
- Keep the assumptions with the result so they can be challenged
The method behind the numbers
Application cores equal peak concurrent users divided by users per core, multiplied by one plus headroom. Memory is concurrent users times memory per session plus a fixed base. Database size grows compound: current size times one plus the growth rate, raised to the number of years. Database memory is a fraction of data size to keep hot pages cached, with a floor of 32 GB. Storage multiplies data size to allow for logs, temporary space, indexes and local backup staging. These are rules of thumb, not vendor formulas.
Reading the result
The application figure is a total for the tier. Split it across at least two servers or virtual machines if you need resilience, and remember that a single failed node must not push the survivors past their limit. The database figures usually go to a primary and a standby. If the calculator shows a very large database core count, check licensing first, since database cores often drive software cost more than hardware. The chart shows how quickly cores grow with users, which helps when you plan for acquisitions or new plants.
Common mistakes
Sizing on named users instead of concurrency inflates cost. Sizing on average load misses month-end spikes. Forgetting reporting, BI extracts and integration jobs, which often compete with users, is another trap. Teams also size storage on data only and forget transaction logs and backups. Finally, a cloud or virtualised ERP still needs CPU and memory reservations: overcommitted hosts can make a correctly sized virtual machine perform badly.
Frequently Asked Questions
How many users per core is typical for an ERP?
There is no universal figure. Vendor guides vary by product, version and workload, and reporting or batch jobs change the picture. The defaults here are placeholders to replace with your vendor's guidance or measured data.
Should I size for named users or concurrent users?
Use concurrent users for CPU and memory, because idle sessions cost little. Use named users for licensing and for estimating how many concurrent users to expect. Observe the real peak ratio on your current system if one exists.
How much headroom is reasonable?
Many teams plan 30 to 50% above measured peak at purchase time, then expect to grow into it. The right figure depends on how predictable your load is and how easy it is to add capacity later, for example in a virtual environment.
Does this work for cloud ERP?
Only partly. SaaS ERP is sized by the vendor. It applies to on-premise, private cloud and IaaS deployments, for example SyteLine, Epicor, Infor LN, SAP or Oracle systems that you host yourself.
If you are planning an ERP move or want AI reporting to run next to your ERP without hurting performance, Netray can help size read replicas and on-premise AI servers.
Related Tools
Backup Retention (GFS) Capacity Calculator
Estimate how much backup storage a daily, weekly, monthly and yearly retention policy needs for an ERP or file server, including compression and offsite copies.
ERP OperationsERP Uptime SLA and Downtime Budget Calculator
Convert an uptime target into allowed downtime per year and month, then test your planned maintenance and incident history against it.
ERP OperationsPlant IT and OT Asset Inventory Worksheet
An editable asset register for servers, network gear, PLCs, HMIs and workstations, with Purdue zone, support dates and replacement budget.
ERP OperationsManufacturing IT Disaster Recovery Plan Template
A fill-in IT disaster recovery plan for a manufacturing site covering ERP, MES, network and plant systems, with roles, priorities and test schedule.