Acumatica major-release regression

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.

You get. A regression matrix across Acumatica major releases: the same GitOps Code (desired configuration and recorded business scenarios in git) is applied as a full tenant rebuild on each release version you support — one automated pass/fail and general-ledger books proof per major release — delivered as a pass/fail report per tenant. Use the report for your own release certification, or package it under your brand across an install base when the format is ready. Prefers an existing business scenario suite expanded across locked Acumatica major releases.

Scenario pass/fail complements your clients’ certified UAT; it does not replace it.

I certify GitOps Code across Acumatica major releases in the lab — one locked major release per host, one full tenant rebuild and regression per major release, general-ledger books as proof. Complements certified UAT; does not replace it.

“Why not just run click-through UAT on the free Acumatica upgrade sandbox?”

The free upgrade sandbox is the right place for human UAT, training, and judgment calls. Always Current expects partners to use it before production upgrade — and that walkthrough still matters.

• →Manual UAT does not scale across an install base. Two Acumatica major releases a year times dozens of tenants is not a click-through project a services team can productize. Failures become unplanned support after go-live.
• →No books-level pass/fail per major release. Sandbox UAT does not deliver the same GitOps Code rebuilt on each locked major release with general-ledger books as the proof surface — a report a VP Services can put under their brand.
• →Not reusable for the next release version. A green UAT day on one sandbox does not re-run itself on the next product line. Without recorded scenarios and a matrix of hosts, the work restarts every cycle.

Keep certified UAT on the upgrade sandbox for judgment and training. Use major-release regression when you need an automated pass/fail matrix and GL books proof per tenant across the Acumatica major releases you support.

Lock one Acumatica major release per lab host → full rebuild and automated regression on the same GitOps Code → GL books as pass/fail.

Nothing installs inside Acumatica. A matrix of major releases on lab hosts you control — a paid regression engagement, not a product license you operate alone. Complements certified UAT; does not replace it.

→One locked Acumatica major release per lab host

Each lab host is a separate Windows machine with one locked Acumatica major release installed — product line and build number are locked before any automated run starts. Three or more major releases side by side when the matrix needs them.

→Full rebuild and automated regression on the same GitOps Code

On each major release: delete prior tenant state, create the company, apply the same GitOps Code (desired configuration and recorded business scenarios in git), exercise buy–build–sell history, and require a successful exit. Failures identify the release version and the step — not a post go-live support ticket.

→General-ledger books as the pass/fail surface

GL books proof per Acumatica major release: checking, receivables, inventory, and capital land where the GitOps Code expects them. Posted results from linked transaction history — not a spreadsheet entered once by hand. Delivered as a pass/fail report per tenant for release certification or install-base packaging.