DevOps Services for Acumatica ERP
I bring software-development discipline to the Acumatica configuration work your team already does.
Every Acumatica change gets tested automatically — so no one on your team spends another evening clicking through it by hand.
where I usually come in
For practice leads and ERP owners
Your hand-configured live Acumatica company is the only complete UAT surface — and there's no way to rebuild it on demand. Which settings are custom, which drifted from standard, and which no one has documented?
Live Acumatica company → rebuildable UAT: config in Git, findings report, rebuild on demand.
For practice leads and ERP owners
Config looks complete until someone tries the real path — order, receipt, invoice, payment — and a missing preference, tax zone, or workflow stops the post. Nobody has an automated answer for “does this company still run the process?”
Scenario suite on current config — pass/fail that critical business paths still post.
For support and ERP admins
Sandbox and production diverge between releases. “It worked in test” is still the most common post-change surprise.
Weekly read-only sandbox vs production diff — material drift ranked above noise.
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.
the question you are already asking
“Why not just restore an Acumatica tenant snapshot?”
A lot of the time you should, and I am not going to pretend otherwise. An Acumatica tenant snapshot copies the database rows, so the restored tenant matches the source tenant’s transactions — faster than reloading the same data through the API, and it carries objects that have no REST endpoint. To move one tenant to one place, once, restore the snapshot. The trouble only starts when you need that restore again.
- No supported automation path for restore. Snapshot create, export, import, and restore are operator workflows — not operations the public REST contract exposes for a pipeline. You can restore a tenant by hand; you cannot put that restore on a schedule or in a release job.
- Single frozen 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. There’s no way to tell 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 you get here is rebuild-from-source: a repository that produces a new demo tenant whenever you need one. Restore a snapshot and you walk in with last quarter’s demo; rebuild from source and you walk in with a demo shaped for the pitch in front of you, 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 running on both. These days I point all of it at Acumatica configuration, hosts, and cutovers.
I work from Toronto. Everything I build ships in your repository and runs in your environment, written up in plain language so your team can pick it up without me.