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.
Connect and export QuickBooks or Xero books → populated Acumatica test tenant, then a path to go-live.
For service leaders and ERP owners
Acumatica ships two major releases each year. Every tenant with customizations, integrations, or non-trivial workflow carries regression risk into each one — and the usual answer is manual click-through user acceptance testing, or no automated proof at all. When something breaks after go-live, the cost lands as unplanned support work.
Same GitOps Code certified on each Acumatica major release — automated pass/fail and GL books proof per tenant.
For practice leads and ERP owners
Your hand-configured live Acumatica company is the only complete UAT surface — and nobody can rebuild it on demand. Which settings are custom, which drifted from standard, and which nobody can explain?
Live Acumatica company → rebuildable UAT: config in Git, findings report, rebuild on demand.
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 — and any answer that starts by dismissing snapshots is not worth reading. 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. It also includes objects that have no REST endpoint. To move one tenant to one place, once, restore the snapshot. The trouble starts when you need that restore again.
- No supported automation path for restore. There is no supported REST path to create, export, import, or restore a snapshot. The vendor’s extended-endpoint command returns 204 and creates nothing; their answer was “use the Test SDK,” and the request was still open as of September 2025.
- Single fixed transaction history. A snapshot freezes one transaction history. You cannot vary the industry flavour, extend the history, or replay it against a newer Acumatica version — you create another snapshot, by hand, and the cycle starts again.
- No auditable change history. A snapshot can be exported as XML, but that file is thousands of database tables of row state — not a format for pre-release review, for merging two people’s work, or for answering who changed what.
- Exact Acumatica version match required. The snapshot’s Acumatica version must match the destination instance exactly — earlier or later is rejected. After every Acumatica release, every partner recreates every demo snapshot by hand.
- No native 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. Nobody can tell you what last week’s pitch changed in the live demo tenant.
- Destructive full-tenant overwrite only. A restore overwrites the target tenant. You cannot push three new item classes into a tenant a prospect is already sitting in — it is the whole snapshot or nothing.
- System lockout during snapshot operations. On 2025 Acumatica versions, copying a company or creating a snapshot forces a system lockout with no bypass. Refreshing a demo now means booking downtime for that instance.
- Web import limited to 1 GB. Import through the web UI stops at 1 GB. Past that limit you are in the Configuration Wizard, moving raw XML by hand.
A snapshot freezes one tenant state. What this offer delivers is rebuild-from-source: a repository that produces a new demo tenant. Restore a snapshot and you get last quarter’s demo; rebuild from source and you get a demo shaped for the pitch you are walking into, on the Acumatica release your prospect is buying.
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.