DevOps Services for Acumatica ERP
I apply software-development discipline to Acumatica ERP configuration.
Every Acumatica change, tested automatically — not clicked through by hand.
the problems I solve
For implementing partners
The prospect is outgrowing QuickBooks or Xero and wants to see their business in Acumatica before they commit. A throwaway demo does not close the deal — and a one-shot go-live is too late to learn.
Source books → populated Acumatica test tenant the prospect can click through, then a path to go-live.
For service leaders and ERP owners
Acumatica ships two major releases a year. Every tenant with customizations, integrations, or non-trivial workflow carries regression risk into each one — and the answer today is manual click-through UAT, or nothing. When it breaks, someone eats the fire drill as non-billable work.
Business scenarios run on an upgraded copy before each major — pass/fail per tenant for your release gate or install base.
For practice leads and ERP owners
What is actually in this Acumatica tenant after years of change — an inherited client or your own production company? Which settings are custom, which drifted from standard, and which nobody can explain?
Full tenant config extracted into Git, plus a findings report — custom, drifted, undocumented.
For project managers and controllers
Go-lives and reimplementations get one dress rehearsal — or none — because every rehearsal costs a week of manual tenant setup. The controller ends up signing off on spreadsheets nobody fully trusts.
Cutover rehearsed until boring: rebuild, load opening balances, controller-signable reconciliation.
the obvious question
“Why not just restore an Acumatica tenant snapshot?”
Often you should restore a snapshot. An Acumatica tenant snapshot copies the database rows, so the restored tenant matches the source tenant’s transactions. Restoring a snapshot is faster than reloading the same data through the API, and it includes objects that have no REST endpoint. To move one tenant to one place, once, restoring a snapshot is the right tool. Three limits show up the moment you need that restore to work again next week.
- Tied to one Acumatica version. The snapshot’s Acumatica version must match the destination instance exactly — earlier or later is rejected. After every Acumatica release, every snapshot has to be recreated by hand.
- No drift detection. Acumatica has no native diff between a snapshot and a live tenant: no report, no exit code, nothing a release gate can read. A snapshot can move a tenant; it cannot report whether two tenants have drifted apart.
- All-or-nothing, and destructive. A restore overwrites the target tenant. On 2025 Acumatica versions, creating or copying a snapshot also locks users out of the system. You cannot push a few configuration changes into a tenant people are already using.
A snapshot freezes one tenant state. Versioned configuration in a repository is what you review, merge, and apply into a tenant that already exists — without wiping that tenant.
about me
System integrator → DevOps → Acumatica DevOps
Twenty years up the stack: data-center hardware first, then cloud infrastructure, then the software that runs on both — now applied to Acumatica configuration, hosts, and cutovers.
Toronto-based. Work ships in the client repository and runs in the client environment, documented in plain language.