Acumatica major-release regression matrix: certify one versioned GitOps tenant seed across three major releases

TLDR

Acumatica ships two major releases each year. Customizations and integrations introduce regression risk on every line, and manual click-through user acceptance testing does not scale. A multi-major regression matrix assigns a separate lab host to each major (one pinned MSI build per matrix cell), runs one cold lifecycle gate per major against the same versioned GitOps tenant seed, and uses General Ledger Account Summary as books proof on every cell. That multi-host matrix is distinct from the single-tenant GitOps regression gate. Neither is a standalone product license; both are the method delivered under a paid major-release regression engagement.

Manual UAT does not scale across Acumatica major releases

Two major releases a year, an install base with customizations and integrations, and acceptance proof that is still manual click-through — or no automated proof at all.

When the next major arrives, the organization either commits client or internal staff to click-through user acceptance testing, or ships without a recorded business-path gate. Failures then appear as post go-live support tickets. The single-tenant regression gate post describes the GitOps loop on one host: apply the versioned tenant seed, run scenarios, and diff configuration. That gate is necessary for configuration change risk and not sufficient for major-release risk: the same seed must also pass on the next product line and the line after that, without re-keying demonstration data by hand between versions.

Lab hosts pin each Acumatica major release to a named Windows VM

Multi-major proof requires rebuildable hosts under your control — Ubuntu KVM with one Windows guest per Acumatica major, each installed from a pinned MSI — not a shared SaaS tenant that cannot be broken for rehearsal.

Production on Acumatica Cloud is not the place to rehearse upgrades. The DEV/TEST environments post describes the lab substrate: one Ubuntu Linux KVM host, Windows Server guests cloned from a golden image, and unattended installation of SQL Server and Acumatica. Inventory names follow acu-<yy>r<n>-dev1 — for example acu-26r1-dev1, acu-25r2-dev1, acu-25r1-dev1 — each carrying a pinned product build (for example 26.101.0225, 25.201.0213, 25.101.0153). That naming is lab host identity, not a marketing SKU.

Host automation lives in the ERP DevOps stack (kborovik/acumatica-devops). The commercial offer is major-release regression, not a hypervisor product.

Matrix cells map each Acumatica major release to its build pin and host

A committed matrix.yaml is the non-secret registry of cells: cell id, ERP build pin, Default API half, and REST base URL, so every clone can resolve which host maps to which major.

Cell id	Example ERP pin	Example host
`26r1`	26.101.0225	`acu-26r1-dev1`
`25r2`	25.201.0213	`acu-25r2-dev1`
`25r1`	25.101.0153	`acu-25r1-dev1`

Secrets remain in local .env (tenant, user, password). The build pin and host location remain in the data repository beside the seed so matrix evidence is reviewable. Selecting a cell directs the CLI to that host’s API version and base URL without manual edits to connection strings between major releases.

One trunk seed plus optional Default-half overlays is the multi-version model — not long-running release branches maintained as parallel product trees.

Cold lifecycle is one gate per Acumatica major release

For each matrix cell, a cold lifecycle deletes prior tenant state, creates the company, applies the GitOps tenant seed, runs linked scenarios, diffs configuration, and requires a successful exit — the same process on every major.

On a data repository that already holds company, chart of accounts, masters, and buy–build–sell–collect history (configuration-as-code substrate), the multi-host command shape is:

# one cell
acu --cell 26r1 check --yes --tenant GITOPS

# every cell in matrix.yaml
acu check --all --yes --tenant GITOPS

As a lifecycle (method, not product packaging): clean slate → create → apply → run scenarios → configuration diff → leave tenant for inspection or tear down. An exit code of zero means that cell’s gate passed. A non-zero exit identifies the failing step so the fix lands in the seed or overlay, not in an unreproducible UI path.

The automated regression testing post is the single-tenant gate (apply / run / diff on one host). This post is the multi-major matrix around that gate: the same seed tree, N hosts, N cold runs, N exit codes.

Host pin and Account Summary close each matrix cell

Before the gate, the login footer is the host pin (product line and build). After a successful gate, Account Summary (GL401000) is the financial books proof — checking, AR, inventory, and capital balances where the seed expects them.

Demonstration and operator practice use the same three steps per matrix cell:

Host pin — login screen shows the Acumatica Cloud ERP line and build (for example 2026 R1 / 26.101.0225). That identifies the matrix cell.
Cold gate — one automated lifecycle against that cell.
Books proof — General Ledger Account Summary with company, branch, and ledger filters set so posted balances are visible; highlight the accounts the seed funds (for example Checking).

Those steps are how a major-release regression service is demonstrated (service page): a multi-cell demonstration switches hosts mid-session so each host pin and each GL proof originates from the host it claims. Pass/fail still complements certified client UAT; it does not replace sign-off liability language.

Multi-major matrix is not the single-tenant gate alone

The automated regression testing post is the GitOps exercise loop on one tenant. This matrix post is N major releases times that loop, with lab hosts and books proof per matrix cell — a different question, the same seed.

Concern	Single-tenant gate	Multi-major matrix (this post)
Question	Does this change leave config clean after scenarios?	Does the same versioned GitOps tenant seed pass on each pinned major?
Hosts	One target	One cell per major (`matrix.yaml`)
Commands	`apply` → `run` → `diff`	`acu --cell <id> check` (or `check --all`)
Proof	Exit codes + config identity	Exit codes + host pin + GL401000 books
Engagement	Every config change / CI	Release-timed major-release regression

Per-tenant scenario libraries for real client processes remain engagement work. The lab matrix proves the method and the seed shape; packaging for an install base follows a trusted report format.

What this engagement includes and what it does not claim

In scope: a multi-major regression matrix under a paid major-release engagement. Out of scope: a licensed CLI product, production as the test surface, or a substitute for certified UAT.

Typical inclusions:

Pinned lab hosts (or agreed hosted upgrade sandboxes) per major in scope
Versioned seed and scenarios for the named tenant shortlist
Cold lifecycle gates and pass/fail report per tenant × major
Books proof on Account Summary (and config identity via diff)

Explicit non-claims:

Not a product SKU installed inside Acumatica and operated independently
Not a replacement for the client’s certified UAT or release sign-off
Not production write as the regression surface
Not unlimited major releases or unlimited tenants without a dated shortlist and SOW

Access remains constrained: read on source tenants where extract is required; write only on upgraded copies or dedicated upgrade sandboxes; Acumatica major releases pinned for the engagement.