Acumatica Azure VM Sizing — A Practical Guide

Acumatica is a .NET application running on IIS in front of SQL Server, so sizing it on Azure is really two sizing exercises: the application (web) tier, which is CPU- and memory-bound per concurrent request, and the database tier, which lives or dies by how much of the working set fits in the SQL buffer pool. Get the split right and a mid-size deployment runs comfortably on a handful of vCPUs; get it wrong and you either overpay for idle cores or watch response times climb every quarter-end.

Size by concurrent users, not named users

Acumatica's own sizing guidance is expressed in concurrent users — people actively hitting the server in the same window — not the number of accounts you licensed. A useful planning ratio is that concurrent users land somewhere around 25–35% of named users for a typical office-hours ERP workload, higher if you run shift work or heavy self-service portals. Count the concurrent number honestly, because every tier below is driven by it. A 200-named-user tenant that peaks at 50 concurrent is a very different machine from one where all 200 log in for month-end close.

The application tier

The IIS/application server is the front line. Each concurrent request consumes CPU and a slice of the worker-process memory, and Acumatica keeps a lot of metadata and per-graph cache in memory. General-purpose D-series VMs (Dsv5/Dds_v5) are the right family here — balanced vCPU-to-RAM, premium-SSD capable. A D4s_v5 (4 vCPU, 16 GB) is a sane starting point for up to roughly 50 concurrent users; step to D8s_v5 (8 vCPU, 32 GB) as you cross that. Add app servers behind a load balancer before you add a single giant one — Acumatica supports web farm deployments, and two mid-size nodes survive a reboot better than one large node.

The database tier

SQL Server is almost always the tier that decides how the whole system feels. The single most important number is RAM: you want enough that the active working set — the data and index pages the day-to-day screens touch — stays resident in the buffer pool instead of being read from disk on every query. That points at the memory-optimised E-series (Esv5/Eds_v5), which give you roughly 8 GB of RAM per vCPU. An E4s_v5 (4 vCPU, 32 GB) is a reasonable database starting point; move to E8s_v5 (8 vCPU, 64 GB) as the database grows past what 32 GB can cache.

Storage layout and disks

Disk is where a lot of Azure ERP deployments quietly underperform. Use Premium SSD (P-series managed disks) at minimum, and split SQL across separate disks so their I/O patterns do not fight each other: one disk for data files, one for the transaction log, and one for tempdb. Enable read-only host caching on the data disk, and set host caching to None on the log disk — the log is write-heavy and sequential, and caching it buys nothing while risking write-ordering surprises. If a specific workload is genuinely IOPS-starved (large imports, heavy reporting), Ultra Disk lets you dial IOPS and throughput independently, but confirm you actually need it before paying for it.

# Application (IIS) node: general-purpose D-series, Premium SSD OS disk
az vm create \
  --resource-group acumatica-prod \
  --name acu-app-01 \
  --image MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:latest \
  --size Standard_D4s_v5 \
  --storage-sku Premium_LRS \
  --admin-username acuadmin

# Database node: memory-optimised E-series + dedicated Premium data/log/tempdb disks
az vm create \
  --resource-group acumatica-prod \
  --name acu-sql-01 \
  --image MicrosoftSQLServer:sql2022-ws2022:standard:latest \
  --size Standard_E4s_v5 \
  --storage-sku Premium_LRS \
  --admin-username acuadmin
az vm disk attach --resource-group acumatica-prod --vm-name acu-sql-01 \
  --name sql-data --new --size-gb 256 --sku Premium_LRS --caching ReadOnly
az vm disk attach --resource-group acumatica-prod --vm-name acu-sql-01 \
  --name sql-log  --new --size-gb 128 --sku Premium_LRS --caching None

A sizing starting point by deployment size

These are starting points to validate against your own telemetry, not guarantees — a report-heavy tenant or a chatty integration can push you up a tier regardless of user count.

Managed SQL vs SQL on a VM

Running SQL Server on its own VM gives you full control and the familiar operational model, at the cost of patching, backups, and HA being your problem. Azure SQL Managed Instance takes most of that off your plate and keeps near-full SQL Server compatibility, which matters because Acumatica uses SQL Server features and expects a real instance. Verify the specific Acumatica version's supported configurations before committing to Managed Instance — support has broadened over releases, and you want it confirmed for your build rather than assumed. The trade-off is straightforward: a VM is cheaper and more flexible if you already run SQL well; Managed Instance is worth the premium if patching and failover are chores you would rather not own.

Controlling the monthly bill

ERP load is predictable — office hours, known close cycles — which makes it an ideal candidate for Azure Reserved Instances or a savings plan. Committing to one or three years on the VMs you know you will run cuts compute cost substantially versus pay-as-you-go, and you can still burst on-demand for anything seasonal. Two more levers: shut down or downscale non-production (dev, test, training) VMs outside working hours with an automation schedule, and use Azure Hybrid Benefit to bring existing Windows Server and SQL Server licences to the VM instead of paying for them again in the hourly rate. Right-size from real metrics after a month in production — CPU, buffer-pool hit ratio, disk queue length — rather than leaving the launch-day guess in place forever.

The short version

Split the tiers, size the app server for concurrent CPU and the database server for RAM, put SQL data, log, and tempdb on separate Premium disks, and keep burstable VMs out of production. Start from the table above, run for a month, then true it up against actual telemetry and lock in the cost with a reservation. If you want a second opinion on a specific deployment, reach out or keep reading through the rest of the Acumatica blog.