Every prospective client who's already decided to self-host asks me the same question in the first call: AWS, Azure, or keep it on our own servers? I've deployed Acumatica on all three at this point, and the honest answer is that the choice matters less than people expect for raw performance, and matters a great deal for who on the client's team can actually operate the thing after I'm off the project.
The baseline: Acumatica doesn't care which cloud it's on
Acumatica's deployment requirements are IIS, .NET, and SQL Server (or a supported alternative), running on Windows. Nothing about the platform is cloud-native in the sense of requiring a specific vendor's managed services. Both AWS and Azure run this shape fine on plain VMs, and on-prem runs it fine on your own hardware or hypervisor. If someone tells you Acumatica performs meaningfully better on one specific cloud because of some platform-level integration, be skeptical - I have not seen that borne out in practice once VM sizing and SQL Server configuration are equivalent across providers, which is covered in more depth in the Azure VM sizing material on this site and applies with the names swapped on AWS.
Azure's real advantage: first-party affinity, not raw performance
Acumatica itself is developed and demoed heavily on Azure, and Acumatica's own SaaS offering runs on Azure infrastructure, which shows up in smaller but real ways: documentation and community troubleshooting skew toward Azure-specific gotchas, Azure AD / Entra ID SSO integration (covered separately on this site) is a well-worn path with fewer surprises than wiring SSO against other identity providers, and Azure Blob Storage as an attachment backend has first-party support in Acumatica's file provider configuration without custom code. None of this is Acumatica running "better" on Azure technically - SQL Server on an equivalently-sized AWS EC2 instance performs comparably - it's that the tooling and community knowledge around Azure-specific integration points is deeper, which reduces the number of things I have to build custom versus configure.
Clients already standardized on AWS for everything else - other line-of-business apps, their own product's infrastructure, existing IAM and networking - do not need to introduce Azure just for Acumatica. RDS for SQL Server (or EC2-hosted SQL Server, which I more often recommend for the licensing and configuration control it gives you) runs Acumatica fine, S3 works as an attachment backend through a custom file provider implementation rather than an out-of-the-box option, and SSO against AWS-adjacent identity providers works through standard SAML/OIDC configuration rather than a first-party Acumatica integration path. Budget a bit more integration time; don't expect a technical performance gap that isn't really there.
On-prem: still the right call more often than cloud advocates admit
On-prem gets dismissed reflexively in a lot of architecture conversations, but for a specific, common client profile it remains the right choice: manufacturing or distribution businesses with an existing, well-maintained server room, IT staff who already manage Windows Server and SQL Server competently, regulatory or contractual requirements around data residency that a cloud region doesn't cleanly satisfy, or simply a client who has done the total-cost-of-ownership math honestly and found that a five-year-old depreciated server farm is genuinely cheaper than five years of cloud VM billing for a stable, non-elastic workload. Acumatica's licensing doesn't penalize on-prem deployment, and the platform runs identically. The trade-off is entirely operational: you own patching, backup infrastructure, DR failover capacity, and hardware refresh cycles yourself, rather than renting that discipline from a cloud provider.
The question that should actually drive the decision
After enough of these conversations, I've stopped leading with cost comparisons or feature checklists and started asking one question first: who operates this after go-live, and what do they already know how to operate? A client whose IT team lives in the Azure portal daily for their M365 and Entra ID estate will operate an Azure-hosted Acumatica instance competently from day one. A client with strong AWS operational muscle from their own product will do the same on AWS. A client with a capable, established on-prem team and no cloud experience at all will operate on-prem better than they'd operate any cloud deployment for the first year, regardless of which cloud's marketing material promises the smoothest onboarding. Choosing the platform your client's team already knows beats choosing the platform that scores best on a generic comparison chart, almost every time.
Whichever option you choose, disaster recovery capability should factor into the choice up front, not get bolted on later. Cloud-hosted deployments have a meaningfully easier path to multi-region DR through native VM replication and automated failover tooling; on-prem DR requires either a second physical site or a hybrid cloud DR target, which is a bigger conversation and often a bigger budget line than clients initially expect. See the RTO/RPO and multi-region DR posts on this site for what that actually costs to build properly.
Wrapping up
Acumatica performs comparably across AWS, Azure, and on-prem once VM sizing and SQL Server configuration are equivalent - there's no meaningful technical performance gap to chase. Azure's advantage is deeper first-party integration tooling and community familiarity, not raw speed. AWS is entirely viable with modestly more custom integration work. On-prem remains genuinely competitive for clients with existing infrastructure and capable IT staff, especially where data residency or long-term TCO favor it. Choose based on what your client's team already knows how to operate, and factor disaster recovery into that decision from the start rather than as a follow-up project.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.