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 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 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 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. 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. 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.