Acumatica ships two major releases a year — historically labelled things like 2024 R1 and 2024 R2 — and each one carries platform updates, UI changes, and the occasional deprecated API alongside the feature work. Upgrading is routine if you treat it as routine: a checklist run every six months rather than a scramble triggered by an ISV or a client asking why they're three versions behind.
What actually changes between releases
Beyond the headline features, every R1/R2 release tends to touch three things that affect existing customizations: the underlying platform (.NET framework version, database engine support), the API surface (contract-based API endpoints occasionally get new required fields or deprecated ones get removed a release or two after warning), and the UI layer, where screens continue migrating to the modern Fluent-based UI framework — which can change how custom fields and buttons added via customization projects render, even when the underlying DAC and graph logic is untouched. None of this is usually breaking on its own, but a customization built two years ago against an older screen layout is the most common thing that quietly stops working after an upgrade.
Pre-upgrade checklist
The work before the upgrade window matters more than the upgrade itself. Compile every Customization Project against the target release in a sandbox first — the Customization Project publish/compile step will surface broken references to removed or renamed API members immediately, long before a user finds them. Check every installed ISV solution against the vendor's published compatibility matrix for the target version; ISV packages that haven't been updated for the new release are the single most common upgrade blocker. Take a full snapshot/backup of the site and database immediately before starting, even though the upgrade process itself is usually non-destructive — the backup is your rollback path, not a formality. And run the whole thing once in a staging or sandbox tenant that mirrors production data volume before touching the live tenant; upgrade timing on a large database can differ meaningfully from a small sandbox.
It's common to have a "clean" test tenant that upgrades without issue and a production tenant loaded with years of customizations and ISV add-ons that behaves completely differently. Test in a copy of production, not in a bare sandbox — a clean upgrade in staging tells you the platform works, not that your specific customizations survive.
The upgrade window itself
Acumatica upgrades (whether self-hosted or on Acumatica Cloud) typically run through the standard update mechanism against a maintained instance, applying database schema changes and platform binaries in sequence. For self-hosted or partner-hosted environments, this means scheduling a maintenance window, disabling scheduled processing (import scenarios, automation schedules, business events that fire on a timer) beforehand so nothing runs mid-upgrade against a half-migrated schema, and confirming the application pool or service account has the permissions the installer expects. For Acumatica Cloud tenants, the update is largely handled by Acumatica, but the pre- and post-upgrade validation responsibility stays with you.
Post-upgrade validation
Once the upgrade completes, re-publish every Customization Project explicitly rather than assuming it survived the migration silently — a project that compiled fine pre-upgrade can still need republishing against the new platform assemblies. Walk through the integrations: confirm outbound webhooks and business events still fire (a screen ID rename or field deprecation can silently break a business event's source query), and re-test any scheduled REST/SOAP API integrations against a real transaction, not just a login check. Custom reports (Report Designer or SSRS-based) should be spot-checked too, since report data sources built against DACs that changed shape between releases can fail or silently return wrong columns. Finally, have a small group of real users exercise their daily screens before declaring the upgrade done — automated smoke tests catch schema breaks, not "this button moved and confused everyone."
| Phase | Checklist item |
|---|---|
| Pre-upgrade | Compile all Customization Projects against target release in sandbox |
| Verify ISV solution compatibility with target version | |
| Full site/database snapshot before starting | |
| Full dry-run in staging tenant with production-like data volume | |
| During | Disable scheduled processing and timed business events |
| Confirm service account permissions for the installer | |
| Post-upgrade | Re-publish all Customization Projects |
| Verify webhooks and business events still fire correctly | |
| Spot-check custom reports against changed DACs | |
| User walkthrough of daily-use screens |
Rollback planning
Have the rollback path decided before you start, not improvised after something breaks. For most deployments that means restoring the pre-upgrade snapshot/backup and reverting to the prior application binaries — which is exactly why the pre-upgrade backup step isn't optional. Set a go/no-go checkpoint after the upgrade completes but before you re-enable scheduled processing and open access to end users: if the core smoke tests (login, a Sales Order save, a Bill entry, one business event firing) fail at that checkpoint, roll back rather than trying to hotfix a customization live against a partially-validated new release.
Wrapping up
An Acumatica upgrade is low-risk almost entirely because of the work done before the maintenance window — compiling customizations against the target release, confirming ISV compatibility, and rehearsing the whole thing in a staging tenant that actually resembles production. Skip that rehearsal and the upgrade itself becomes the incident.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.